• December 7

❓ 𝐃𝐢𝐝 𝐲𝐨𝐮 𝐤𝐧𝐨𝐰 𝐭𝐡𝐚𝐭... t̲h̲e̲ ̲b̲l̲o̲c̲k̲’̲s̲ ̲s̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲M̲u̲l̲t̲i̲v̲e̲r̲s̲X̲ ̲b̲l̲o̲c̲k̲c̲h̲a̲i̲n̲ ̲i̲s̲ ̲r̲e̲p̲r̲e̲s̲e̲n̲t̲e̲d̲ ̲b̲y̲ ̲a̲ ̲b̲l̲o̲c̲k̲ ̲H̲e̲a̲d̲e̲r̲? 💡

The Header contains information about the block (block nonce, round, proposer, validators timestamp, etc.), and a list of miniblocks for each shard that contain the actual transactions inside. Every miniblock contains all transactions that have either the sender in the current shard and the receiver in another shard or the sender in a different shard and the destination in the current shard.

• December 14

❓ 𝐃𝐢𝐝 𝐲𝐨𝐮 𝐤𝐧𝐨𝐰 𝐭𝐡𝐚𝐭… c̲u̲r̲r̲e̲n̲t̲l̲y̲,̲ ̲t̲h̲e̲ ̲a̲t̲o̲m̲i̲c̲ ̲u̲n̲i̲t̲ ̲o̲f̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲n̲ ̲c̲r̲o̲s̲s̲-̲s̲h̲a̲r̲d̲ ̲e̲x̲e̲c̲u̲t̲i̲o̲n̲ ̲i̲s̲ ̲a̲ ̲m̲i̲n̲i̲b̲l̲o̲c̲k̲? 💡 

Either all the transactions of the miniblock are processed at once or none and the miniblock’s execution will be retried in the next round. 

The MultiversX cross-shard transaction strategy uses an asynchronous model. Validation and processing is done first in sender’s shard and then in receivers' shard. Transactions are first dispatched in the sender’s shard, as it can fully validate any transaction initiated from the account in this shard – mainly the current balance. Afterwards, in the receivers' shard, the nodes only need proof of execution offered by metachain, do signature verification and check for replay attack and finally update the balance for the receiver, adding the amount from the transaction. 

• December 21

❓𝐃𝐢𝐝 𝐲𝐨𝐮 𝐤𝐧𝐨𝐰 𝐭𝐡𝐚𝐭... E̲S̲D̲T̲ ̲s̲t̲a̲n̲d̲s̲ ̲f̲o̲r̲ ̲E̲l̲r̲o̲n̲d̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲D̲i̲g̲i̲t̲a̲l̲ ̲T̲o̲k̲e̲n̲,̲ ̲a̲ ̲c̲u̲s̲t̲o̲m̲ ̲t̲o̲k̲e̲n̲ ̲a̲t̲ ̲n̲a̲t̲i̲v̲e̲ ̲s̲p̲e̲e̲d̲ ̲a̲n̲d̲ ̲s̲c̲a̲l̲a̲b̲i̲l̲i̲t̲y̲,̲ ̲w̲i̲t̲h̲o̲u̲t̲ ̲E̲R̲C̲2̲0̲? 💡  

The MultiversX network natively supports the issuance of custom tokens, without the need for contracts such as ERC20, but addressing the same use-cases. And due to the native in-protocol support, transactions with custom tokens do not require the VM at all. In effect, this means that custom tokens are 𝐚𝐬 𝐟𝐚𝐬𝐭 𝐚𝐧𝐝 𝐚𝐬 𝐬𝐜𝐚𝐥𝐚𝐛𝐥𝐞 𝐚𝐬 𝐭𝐡𝐞 𝐧𝐚𝐭𝐢𝐯𝐞 𝐄𝐆𝐋𝐃 𝐭𝐨𝐤𝐞𝐧 𝐢𝐭𝐬𝐞𝐥𝐟.  

Users also do not need to worry about sharding when transacting custom tokens, because the protocol employs the same handling mechanisms for ESDT transactions across shards as the mechanisms used for the EGLD token. Sharding is therefore automatically handled and invisible to the user.  

Technically, the balances of ESDT tokens held by an Account are stored directly under the data trie of that Account. It also implies that an Account can hold balances of any number of custom tokens, in addition to the native EGLD balance. The protocol guarantees that no Account can modify the storage of ESDT tokens, neither its own nor of other Accounts. 

• December 28

❓ 𝐃𝐢𝐝 𝐲𝐨𝐮 𝐤𝐧𝐨𝐰 𝐭𝐡𝐚𝐭…̲ t̲h̲e̲ ̲E̲l̲r̲o̲n̲d̲ ̲p̲r̲o̲t̲o̲c̲o̲l̲ ̲i̲n̲t̲r̲o̲d̲u̲c̲e̲s̲ ̲n̲a̲t̲i̲v̲e̲ ̲N̲F̲T̲ ̲s̲u̲p̲p̲o̲r̲t̲ ̲b̲y̲ ̲a̲d̲d̲i̲n̲g̲ ̲m̲e̲t̲a̲d̲a̲t̲a̲ ̲a̲n̲d̲ ̲a̲t̲t̲r̲i̲b̲u̲t̲e̲s̲ ̲o̲n̲ ̲t̲o̲p̲ ̲o̲f̲ ̲t̲h̲e̲ ̲a̲l̲r̲e̲a̲d̲y̲ ̲e̲x̲i̲s̲t̲i̲n̲g̲ ̲E̲S̲D̲T̲? 💡 

This way, one can issue a semi-fungible token or a non-fungible token, which is quite similar to an ESDT, but has a few more attributes, as well as an assignable URI (Uniform Resource Identifier). Once owning a quantity of a NFT/SFT, users will have their data store directly under their account, inside the trie. 

In addition to NFTs and SFTs, Elrond introduced Meta ESDTs. Meta ESDTs are a special case of semi-fungible-tokens. They can be seen as regular ESDT fungible tokens that also have properties. In a particular example, XMEX is a Meta ESDT and its properties help implement the release schedule. 

ARC Staking

Twitter    Telegram     Website