Layer 1
Layer 1 is implemented on an ETH-based virtual machine. L1 smart contracts are designed to govern the framework. For example, they run ledgers of attached users and Branes and execute utility token transactions. Layer 1 also governs validation of incoming rollups and stores the resultant data.
Governing
Layer 1 smart contracts contain ledgers of all the users and L2 nodes. When a user starts working with a Brane, L1 appoints an L2 node to process it. With this scheme, layer 1 distributes L2 nodes between Branes (IDApps).
Validation
As described in the Layer 2 section, L2 nodes submit the results from processing Branes to layer 2 via rollups. Layer 1 smart contracts govern the validation procedure. These smart contracts specify the validation scheme's conditions, such as the sequence of steps that need to be taken and their duration. They also check to see that all required conditions have been met, for example, that the stakes are available and sufficient data has been submitted. After a rollup is validated and approved, an L1 smart contract registers and stores updates of the user's state and token balance.
Just as on any blockchain, L1 validates rollups in a decentralized way. This means that transactions can be verified without central control or other third parties. Instead, each validator in the L1 blockchain has access to all the transactions made on the network.
Consequently, every participating validator can verify and confirm any transaction. If the validation result matches for most participating validators, the transaction is confirmed and goes through without an intermediary. If not, the transaction is rejected.
Commit Reveal Appeal
Avvyland's L1 uses a validation scheme called a 'commit reveal appeal'. It has the following purposes:
to validate L2 node performance
to provide the ability to return to the latest known point in the system's flow in the event that incorrect calculations are submitted
to unambiguously detect nodes that have submitted incorrect calculations
The validation scheme implies that:
any operation submitted in a smart contract has a unique signature that allows it to unambiguously determine the initiator’s network address
all operations in the system are fixed, so operations always yield the same results
all operations are executed progressively. The order in which operations are submitted is defined at the rollup creation stage to eliminate the possibility of race conditions.
The commit reveal appeal scheme has been modified with an additional step for appellation. Though a standard commit reveal scheme helps avoid collusion between validators, the validators can still perform malicious transactions by colluding off-chain. The additional step makes it possible to appeal for validation results each time a participant disagrees with them.
Meanwhile, the size of the stake required for validation and appellation in each round will be equal to the total sum of stakes made in the previous round. We assume that more than 50% of participants are fair actors, so most validators will be interested in a fair decision with this kind of commit reveal appeal scheme.
Every rollup is processed in several steps. The time period for each step is limited.
validation
disclosure of validation results
appellation
time for disclosure of appellation results, then step 3
If more than 50% of all validators detect incorrect data in a rollup, the system performs a rollback, and the nodes that validated the incorrect data are sanctioned in the amount of the stake.
Staking
An L2 node can serve as either as a Brane's validator or processor. To perform each function, the node has to make a deposit, or stake, when being registered in an L1 governing smart contract. This deposit helps avoid fraud and guarantees financial responsibility. The stake is made with a utility token.
At the beta stage, we presume that each L2 node is reliable, but its work is validated by other L2 nodes. L2 nodes transmit the results of their work to L1 at certain intervals in the form of a rollup.
Last updated
