Smart contracts & blockchain interaction
The architecture of smart contracts may differ depending on the technologies and tools available in each particular blockchain. This block describes the architecture for EVM and EVM-compatible blockchains.
In the minimum required version, Ylide uses 2 smart contracts to ensure communication between users:
The first smart contract is a register that stores the “wallet address” ⇒ “communication public key” link (or pair). Please see more details on how it works and why it’s required in the “Register of public keys” section.
The second is a broadcasting smart contract. It is responsible for uploading the encrypted content of letters to the blockchain and “notifications” of the message that contains the encrypted “content password”.
Both smart contracts do not require access to the information that is uploaded to them. In other words, the information does not become the “internal state” of smart contracts but rather stored in the event system. This saves space and greatly reduces the cost of a transaction since we don’t use any global arrays or mappings inside smart contracts to store data.
Each message has a unique msgId - message identifier that is used to quickly find its content on the blockchain.
There are 2 streams of events: the first is content, and the second is notifications to recipients with decryption keys.
Content stream - the encrypted content of the message stored in the events and each event has an indexed field msgId used to quickly find the content. The content itself can be divided into several parts, i.e. several events will be generated with the same indexed msgId but different content. Decrypting a message without access to all parts is impossible. All parts are connected by the Ylide SDK in the user application.
Notification stream - the generated events contain the indexed address of the recipient, msgId of the message, and the “content password” encrypted for the particular recipient.
The separation of these two streams has several goals at once:
No need to download the full content of emails from the blockchain to show the user a full list of messages or notify about new messages.
In the future, for large messages with media content, content events can be stored not on the blockchain but in external decentralized storages such as IPFS, Arweave, FileCoin and etc. This will allow to further reduce the cost of messages keeping the fact that the message was sent.
Allows sharing the content of the message with new recipients even after the message is sent.
Now let’s take a look at the detailed process of receiving messages from the Ylide SDK:
The application defines a list of blockchains from which it wants to display messages to the user.
For each of these blockchains, either a subscription to notification events with a filter by the recipient’s address (which is indexed) or a periodic request for these events (if the subscription is not available) is established.
When a new message appears - it is displayed in the user interface, with information about the date, sender, and other meta information. Inside the application, msgId is stored for this message.
If the user wants to read the message, Ylide SDK sends a request to the specific blockchain (where the message was sent) for content events with a filter by msgId (indexed). As a result, the Ylide SDK downloads all parts of the message in encrypted form and combines them into one.
Next, depending on the security level chosen by the user, Ylide SDK either immediately decrypts the content of the message using the user’s communication private key or asks him for the necessary passwords, after which the message is decrypted.
The decrypted content is displayed to the user on the screen.
Last updated