Human “on-chain” Communication Dedicated Protocol & SDK
Let’s open with a thought;
“Electronic communication is too valuable to be entrusted to an intermediary. The future lies in permissionless, immutable, “on-chain” communication protocols.”
Blockchain technology has the potential to change the narrative and the core concept of traditional digital human communication and data management (i.e. email, messaging, data file transfers, data file management, etc.); from custodial to non-custodial; from centralized to decentralized; from permissioned to permissionless, and; from free but mined to payable but yours. Enters 4thTech with L1/L2 secured “on-chain” communication infrastructure framework powered by a dedicated SDK (i.e. software development kit).
The goal of this article extends beyond just detailing 4thTech’s unique development. The article aims to provide a comprehensive understanding of 4thTech’s role within the Ethereum ecosystem of human “on-chain” communication, the challenges it faced, and the strategic rationale behind its design.
4thTech is a Block Labs project built as a Web3 infrastructure technology occupying the protocol, encryption, and SDK layers, enabling the existence of “on-chain” communication applications and various use cases. With the goal of becoming a go-to framework for developers, 4thTech developed and deployed integrator-focused core building blocks;
(1) OCC (i.e. on-chain communication) Protocol v.1;
(2) infrastructure-dedicated OCC SDK;
(3) UI (i.e. user interface) white-label stack, and
(4) multi-level integration licensing with build-in economics.
Core Primitives
While various integration use cases are possible, let’s use dMail (i.e. decentralized email) and dChat (i.e. decentralized messaging) as examples. Encrypted W2W (i.e. wallet-to-wallet) message exchange happens “on-chain” as one short message represents one L1 or L2 blockchain transaction. As dMail is data heavier, lite encrypted JSON objects are created to hold dMail metadata. The link to this metadata and checksum is recorded on the chain as a blockchain transaction. The same goes for the W2W data file transfers use case where; 1 data file package transfer = 1 L1/L2-TX. So again, the core primitive described by the formula below applies.
💡1 email/message/data-exch = 1 L1/L2-TX
Every wallet becomes an “on-chain” identity, and the message or data vault can be accessible (i.e. decrypted) only with users’ private keys! There are three encryption options available within the SDK; (1) custom encryption; (2) AES-randomly generated secret key (i.e. Advanced Encryption Standard), and; (3) AES secret key produced by ECDH (i.e. Elliptic-Curve Diffie-Hellman).
💡not your keys = not your email/message/data
(1) OCC Protocol v.1
While the Genesis Protocol emerged in 2018, the final iteration just saw the light of day. Developing the infrastructure protocol proves to be quite demanding as one needs to concept it from a multi-level standpoint. As seen from the smart contract methods within 4thTech Protocol v.1, we had to consider various integration use cases and use case-specific features, while not compromising core decentralization principles.
With many iterations behind, the six EVM (i.e. Ethereum virtual machine) smart contracts crystalized and are forming the core protocol layer, enabling “on-chain” communication at scale; (1) Mails; (2) Chat; (3) Users; (4) AppFeeManager; (5) Lock, and (6) TierManager.
Two main smart contracts are enabling the main use cases. While [Mails] smart contract is used for data exchange over the blockchain, the [Chat] is a smart contract used for decentralized, encrypted short message exchange over the blockchain.
[Mails] smart contract is implementing the following methods;
- (1) sendMail: self-explanatory
- (2) setOpenedAt: recipient can mark read mail timestamp
- (3) deleteMail: self-explanatory
- (4) deleteMails: self-explanatory
- (5) getMail: self-explanatory
- (6) getMails: self-explanatory
- (7) getMailsCount: returns the number of received mails
- (8) getMailsPaginated: self-explanatory
- (9) getAppIds: self-explanatory
[Chat] smart contract is implementing the following methods;
- (1) sendMessage: self-explanatory
- (2) deleteMessage: self-explanatory
- (3) addMessageToConversation: self-explanatory
- (4) createGroupConversation: self-explanatory
- (5) deleteGroupConversation: self-explanatory
- (6) addMembersToGroupConversation: self-explanatory
- (7) removeMembersToGroupConversation: self-explanatory
- (8) getConversationHashes: each conversation has its own hash, this method returns an array of user-participation-conversation hashes
- (9) getConversations: self-explanatory
- (10) getConversation: self-explanatory
- (11) getConversationMessagesPaginated: self-explanatory
As 4thTech is represented as a technology framework, the Protocol TestNet and MainNet deployment is in the domain of the Level-1 integrators. The first ecosystem Level-1 integrator is Immu3. Please check the Immu3 deployment table for Protocol v.1 multi-chain availability.
*More Protocol-related information: https://github.com/4thtech/smart-contracts
(1.1) Fees within the OCC Protocol v.1
Parallel to the underlying L1/L2 transaction gas cost, the PROTOCOL-FEE is determined by the Protocol v.1 Level-1 integrator and also settled on the smart contract level (i.e. applicable for every “on-chain” communication transaction). Total user cost equals the sum of the L1/L2 transaction gas, the PROTOCOL-FEE, and the cost of storage if any. GAS usage is defined in wei & gwei and multiplied by GAS price, which results in true L1/L2 GAS cost.
Cost & Fee structure;
- (1) L1/L2 transaction GAS cost;
- (2) PROTOCOL FEEs (i.e. equals the sum of BASE-FEE and DAPP OWNER-FEE);
- (2.1) PROTOCOL BASE-FEE;
The BASE-FEE is set generally by the Level-1 integrator as a constant within [Mails] and [Chat] smart contracts and can be adjusted based on the specific dApp. The PROTOCOL-FEE is defined with $ value approximation (e.g. ~0.0025$ ETH, Matic… ≡).
- (2.2) PROTOCOL DAPP OWNER-FEE;
DAPP OWNER-FEE is set by the dApp owner (i.e. Lever 2 integrator) independently based on the dApp economic model. It is defined by the $ value approximation (e.g. ~0.0975$ ETH, Matic… ≡).
(2) The OCC SDK
Built on top of the protocol stack, the TypeScript/JavaScript plug-and-play OCC SDK stands ready for security-enabled social communication scaling in the multi-chain universe.
The OCC SDK consists of five packages;
- (1) @4thtech-sdk/Ethereum; This package handles Ethereum blockchain transactions, smart contracts, and other blockchain-related functions.
- (2) @4thtech-sdk/encryption; This package allows for easy data encryption and decryption using various encryption methods, ensuring secure data handling within the 4thTech protocol.
- (3) @4thtech-sdk/encryptor; This package handles the connection with Encryptor Extension.
- (4) @4thtech-sdk/storage; This package is designed to optimize storing and retrieving procedures, enhancing data management within the 4thTech protocol system.
- (5) @4thtech-sdk/types; This package contains the type declarations used across all the other packages.
To enable seamless integration, there are tests available within the OCC SDK framework. Tests basically enable the testing of the correct functioning of methods, but on the other hand, provide insight into how a certain method is used (e.g. Chat). SDK documentation offers detailed instructions and all needed integration support, while SDK repos are open and available for further study.
(2.1) Communication Encryption options available within the OCC SDK
To enable various use cases there are several communication encryption options available within the OCC SDK;
- (1) no encryption; plain unencrypted content is shared between wallet client A (i.e. sender) and wallet client B (i.e. receiver);
- (2) custom encryption; integrators have the option to develop their specific encryption implementations, and;
- (3) AES (i. e. symmetric, secret key encryption);
- (3.1) randomly generated secret key; a random secret key is generated to encrypt content, which is shared between wallet client A (i.e. sender) and wallet client B (i.e. receiver). Content is encrypted with AES encryption. The receiver obtains the secret key from a sender using external communication (i.e. email, chat…) to decrypt the content, and;
- (3.2) secret key produced by ECDH secret key exchange using Encryptor extension; secret key produced by ECDH secret key exchange using Encryptor extension, where the secret key is produced with ECDH secret key exchange. The sender needs the wallet client B (i.e. receiver) “Encryptor Extension” public key to be recorded on the blockchain. “Encryptor Extension” is used to calculate the shared secret key.
*Note: Natively AES-256-GCM is used for the encryption algorithm.
Developing the framework for on-chain E2EE group messaging was a challenge in itself. It is solved by the random generation of the secret key, that is used to encrypt/decrypt messages. The secret key is distributed to all group members and separately encrypted with AES over the ECDH key agreement protocol.
(2.2) Storage options available within the OCC SDK
There are three storage databases forming within the framework; (1) blockchain; (2) decentralized or centralized storage, and; (3) user local storage.
If we take a look at dMail and dChat as an example, blockchain is used to store;
- (1) A link to the dMail JSON metadata, timestamp, checksum & sender address, and;
- (2) dChat encrypted message, timestamp & sender address.
The concept of decentralized storage is used for the temporary or permanent storage of encrypted communication, data files, and JSON files (i.e. dMail, subject & content attachment location). Integrators can also opt for more centralized storage such as cloud storage.
User local storage is used for storing:
- (1) wallet private keys;
- (2) dMail & dChat content hash, and;
- (3) user-initiated backup of conversations, data files, and reports.
(3) UI White-label stack
Decentralized email and messaging represent the main use cases of “on-chain” communication. A white-label framework was built to enable quick and easy dMail & dChat application deployments. This framework uses a modern, minimalist design style that emphasizes simplicity. It comes with an intuitive and effective navigation and setup system. To ensure the best possible user experience, we have developed a user interface that provides step-by-step setup instructions. To use and build on top of 4thTech white-label you can fork our GitHub repository and start experimenting.
(4) Multi-level integration licencing
There are two integrator licenses available within the ecosystem;
- (1) Level-1 integrator license and;
- (2) Level-2 integrator license.
Level-1 integrator license or so-called “Enterprise” integrator license is available via Block Labs [4thTech] and is meant for traditional businesses or offices, L1s, wallets, and existing applications. A permissionless Level-2 integrator license is available via Immu3 (i.e. Level-1 integrator) and is perfect for teams wanting to build their own “on-chain” communication dApps.
Conclusion
Access to secure, self-custodial P2P digital communication should be accessible and available as people need alternatives. Despite the fact, that the 4thTech OCC Protocol v.1 enables E2EE communication to be transmitted via blockchain, the metadata created between the user’s wallet and the dApp is still vulnerable, but with the development of “mixnets”, such as HOPR this issue can also be resolved in the future. Performance-wise, the weak point remaining is the underlying L1/L2 infrastructure with potential congestion or dawn-time issues. The same goes for data availability via decentralized storage providers.
Out-of-the-box, the OCC Protocol v.1 enables PAYGO transaction models, where users need to settle and confirm every message. While this approach can cause a barrier to entry for Crypto non-native users it is still very native to the Web3 ecosystem as it provides much-needed transaction transparency and platform clarity lacking in legacy systems.
We are still very early and block space subscription is still evolving. There are numerous Ethereum improvement proposals (i.e. eip-758, eip-1337, eip-4885, eip-5643) being written that could enable subscriptions on the blockchain. According to the eip-1337 summary, monthly subscriptions are a key monetization channel for legacy web, and arguably they are the most healthy monetization channel for businesses on the legacy web (especially when compared to ad/surveillance) based models. As the blockchain space will evolve to enable subscription-based transaction access, so will 4thTech OCC Protocol v.1.
To support Web2’s familiar onboarding practices, integrators can already develop subscription-based models based on Fiat/Crypto bulk transaction pre-payments.
The social aspect and technological advancement of “on-chain” human communication open new possibilities. Imagine seamless multi-platform “any chain to any wallet communication”. The technology is practically here. What’s important now, is to offer a reliable protocol infrastructure and let the developer community innovate the key genesis dApps with fundamental “on-chain” communication use cases.
Finally, let’s not forget that we are utilizing blockchain to enable self-custody and data ownership in digital communication, which is practically non-existent in traditional Web2 applications.
Disclaimer
All content provided herein, including but not limited to text, graphics, logos, and images (the “Content”), is the property of Block Labs Luxembourg S.a r.l., a legal entity established under the laws of the Grand Duchy of Luxembourg, registered with R.C.S. Luxembourg under N B263508 at the following address: 41, rue du Puits Romain, z.a. Bourmicht (Atrium Business Park), L-8070 Bertrange, Luxembourg (the “Company” or “we”). It is protected by copyright and other laws that protect intellectual property and proprietary rights. You are granted a non-exclusive, non-transferable, revocable license to access and use the Content for the sole purpose of obtaining information about the 4thTech technology and other educational purposes. We have done our best to ensure that the Content is accurate, updated, complete, and provides valuable information, but neither do we guarantee nor take any responsibility for its accuracy and/or completeness. The Content is not intended as, and shall not be understood or construed as legal, financial, tax, or any other professional advice, sale or offer for sale of any securities, and/or crypto-assets. The Company is not engaged in rending of and/or is not licensed to render any of the crypto-asset services and/or financial services, such as investment or brokerage services, capital raising, fund management, or investment advice.
