Elements

Elements of the Protocol

The State

Shards, briefly

TODO

Levels of Sharding

TODO

• ☐ Importance of Sharding Levels: State Sharding > Transaction Sharding > Network Sharding

State Sharding

TODO

Transaction Sharding

TODO

Network Sharding

TODO

Accounts

TODO

• ☐ Accounts are permanently bound to a Shard
• ☐ Some Accounts are SmartContract Accounts
• ☐ Stored on the State

Account ownership

TODO

The Nonce of an Account

TODO

• ☐ Initially 0
• ☐ Copied directly into a new Transaction, without incrementing; i.e. this is the Nonce of the next Transaction
• ☐ Incremented after the Transaction is executed
• ☐ Account Nonce is unique per Account, and the Account is unique per Network, which means the combination (Account, Nonce) is unique per Network

The Message

The Message is a string of X bytes, both encrypted and cryptographically signed, sent by a Node to one or more of its peers. Normally, a Node broadcasts a Message to all its peers. In effect, this means "I'm sending this into the Network" because Nodes normally re-broadcast a received Message to their own peers, who re-broadcast to their peers and so on, propagating the Message through the entire Network.

But a Node can also send a Message directly to a known, specific Node in the Network. When does this happen? Is it for replies to info requests?

What key is used for encrypting the Message? What key is used for signing the Message?

A valid Message

TODO

The Blockchain, briefly

TODO

• ☐ Stored on the State

Blocks

TODO

• ☐ Hashing and signing
• ☐ The bitmask of signers
• ☐ Stored on the State, as part of the Blockchain

Miniblocks

TODO

• ☐ Hashing and signing
• ☐ The Gas Limit of a Miniblock

Types of Miniblocks within a Block

TODO

• Miniblocks with value-transferring Intra-Shard Transactions

• Miniblocks with value-transferring Cross-Shard Transactions where current Shard is Source

• Miniblocks with value-transferring Cross-Shard Transactions where current Shard is Destination

• Miniblocks with rewarding Intra-Shard Transactions

• Miniblocks with rewarding Cross-Shard Transactions where current Shard is Source

• Miniblocks with rewarding Cross-Shard Transactions where current Shard is Destination

• Miniblocks containing SmartContract results from Intra-Shard Transactions

• Miniblocks containing SmartContract results from Cross-Shard Transactions where current Shard is Source

• Miniblocks containing SmartContract results from Cross-Shard Transactions where current Shard is Destination

Block finality

TODO

The Nonce of a Block

TODO

• ☐ Initially 0
• ☐ Block Nonces are unique per Shard, but not over the entire Network
• ☐ Also called the Block height

Transactions

Anatomy of a Transaction

• ☐ Clarify what the Challenge field does and whether it will be removed soon or not

type Transaction struct {
	Nonce     uint64
	Value     *big.Int
	RcvAddr   []byte
	SndAddr   []byte
	GasPrice  uint64
	GasLimit  uint64
	Data      string
	Signature []byte
	Challenge []byte
}

Creating a Transaction

• ☐ Transactions: the Wallet, when generating Transactions, must query the Network for Nonces
• ☐ Retrieving the Nonce for a Transaction
• ☐ Creating a Transaction that calls a SmartContract
• ☐ Creating a Transaction that deploys a SmartContract

A user can request the execution of a desired Transaction by submitting it to the REST API of any of the Nodes of the Network. The Node that receives the Transaction then propagates it through the Network, leading to its execution. See Receiving Transactions for an overview on how this happens. For more details on how Transactions are executed after being propagated through the Network, see Executing Transactions.

To request the execution of a Transaction, one must first create define it, sign it and then serialize it. This results in a JSON string which can then be submitted to the REST API of a Node. Note that during the first step, Defining a Transaction, the constructed Transaction object must have the Signature and Challenge fields empty / unset. This is because the value for the Signature field will be generated in the next step, Signing a Transaction, and only afterwards is the Signature field set to the newly generated value. These steps are described in the following subsections.

There are minor differences between creating Transactions that simply transfer ERD and creating Transactions that call a SmartContract. TODO add more overview here

Defining a Transaction

Defining a Transaction requires the following pieces of information:

• Value: The amount of ERD to be transferred by this Transaction. The Value is a very large integer, specifiying how many attoElrond to transfer. Note that 1 Elrond = 10^18 attoElrond.
• Sender Address: a byte array representing the address of the Sender Account which is initiating the Transaction and is sending an amount of ERD to the Destination Account, as specified by the Value field. If this Transaction involves the execution of a SmartContract, then the SmartContract will be executed on the behalf of the Sender Account.
• Receiver Address: a byte array representing the address of the Receiver Account, which will receive the amound of ERD specified by the Transaction. This address may belong to a SmartContract Account, thus executing this Transaction implies executing some code from the SmartContract.
• Nonce: the Nonce associated with the Sender Account. TODO expand? also explain how it must be acquired
• GasPrice: the amount of attoElronds that the Sender Account will pay for each unit of Gas consumed by Nodes for the execution of this Transaction. GasPrice will be used to compute the amount of ERD received by the Node which executes this Transaction and adds it to a proposed Block, as compensation for the expended computational effort.
• GasLimit: the limit of units of Gas that a Node may consume to execute this Transaction, limiting the maximum cost that the Sender Account will have to pay for this Transaction to be executed. When Nodes execute the Transaction and GasLimit is exceeded, they will abort its execution. See Gas for more details.
• Data: ?

Comparing the list above with the structure of a complete Transaction, shown in Anatomy of a Transaction, one can see that the Signature and Challenge fields are missing. These two fields will be added in the next step, Signing a Transaction.

Signing a Transaction

Transactions are signed in order to prove ownership over the Sender Account - it would obviously be undesirable to have someone define a Transaction where the Sender Account belongs to another user, but the Receiving Account belongs to themselves. Each Account address is, in fact, the Public Key of a cryptographic Key Pair (the other key in the Key Pair being the Secret Key). And whoever has the Secret Key corresponding to the Account is considered to own that Account.

Serializing a Transaction

TODO

Cryptography

Cryptographic signing

SmartContracts

TODO

The Metachain

TODO

Notarizing Blocks on the Metachain

TODO

Topics

TODO

Topics of interest for a Node

TODO

libp2p

TODO

Nonces

A Nonce is a number the value of which is used only once, then changed to a new value. The simplest Nonce is the incrementing Nonce - after each usage of the value, it is incremented. Incrementing Nonces also have the advantage of being ordered, thus they force a sort of arrow-of-time in a single direction across the entire Network. Because virtually all Nonces used by the Elrond Network are incrementing Nonces, the "incrementing" quality is usually left implied and the term "Nonce" is used without adjective.

As an example, each Transaction requires a Nonce. Specifically, this is the current Nonce of the Account that initiates the Transaction (briefly, each Account has its own Nonce, which is copied directly into a new Transaction, and incremented only after the Transaction is executed successfully).

Another example is the Nonce of a Block. TODO expand

Elrond tokens

TODO

Elrond token subdivisions

TODO

• ☐ Transaction Value and Transaction GasPrice are specified in attoElronds
• ☐ Do the prefixes for Elrond values follow the SI prefixes?