jakiro
Author: TOLY, Solana Labs Joint Source: X,@AEYAKOVENKO Translation: Shan Ouba, Bit Chain Vision Realm
In Solana, the state organization is a flat key value storage, and the program executes the update value in this state, including key voting procedures for consensus.The main purpose of asynchronous execution is to allow voting procedures to operate independently of all other programs.In order to always achieve this goal, we need to ensure several key principles.
Execution domain
The execution domain is a set of procedures and its operation keys and values, which are independent of each other during execution.The execution domain can be run on different threads and cores, and is completed at different times on various machines.The important thing is that one execution domain (for example, domain A) cannot read or write any value in another domain (eg, domain B).However, domain can be shared in a consistent state during the execution of any domain.A protocol is required to synchronize the state between the field and promote the movement of the key and value.
The transaction fee payment person determines the domain of the transaction execution.
Key domain: VED and UED
In Solana, we mainly focus on two domains: voting execution domain (VED) and user execution domain (UED).The goal is to enable the verifications to vote before all user programs are performed.
VED component
-
System program: For transfer
-
Voting program system variable: Voting program system variable for voting
-
Voting: Core voting procedure.This program is static and consistent, and must be available in UED and VED.
-
Voting authority: Account with the right to vote
-
Voting fee payment: Accounts that pay related fees for voting
-
Cost Payer Fund: Can be used to move SOL to VED’s updated account
-
All other accounts are placed in UED
Calculate the VED state
In the Bye boundary between N-1 and N, calculate the VED status of the N+1 domain when runtime.This calculation must be completed before the epoch n.UED calculations must start after the Era N-1 is completed.
Standard in VED status
-
Voting account: Package of more than 5000 SOL and active state.
-
Cost payer and voting permissions, expense payer funds: Associated with the above voting account.
-
The newly created voting account was initially set up as active.Users must activate these accounts. Once activated, they will be included in the next VED status calculation.Users can stop the account, and the account will be removed from the VED state in N+1 Era.
Move funds in VED
The funds accounts declared in the voting account can be used to move funds in VED.After updating the cost of payment in the voting account, the current expense payer fund will remain active before the end of the next era.Once the re -calculated VED activation, the new cost payment fund will enter the VED state and can be used to add additional SOL to the cost payment.The old cost payment fund will enter the UED state, so the funds can be transferred back to the account in the UED.
Although it can be merged with the expense payer, in order to minimize the number of signatures used for each voting, the cost payment is usually set to the same value as the voting permissions. Therefore, a separate account is required to transfer SOL between VED and UED.
Universal execution domain
The above method is very targeted at voting procedures.This method can be further promoted to the execution domain of any number.Account tracking the execution domain they are mapped, just like the operating system management program tracks VMID in the physical page.For this specific project, a small part of the mapping is useful:
-
Rx-ued: Read and execute in UED
-
RX-Ued-VED: Read and execute in UED and VED
-
RW-VED: Read and write in VED
-
RW-UED: Read and write in UED
Since the account cannot read and write at the same time in multiple domains, other mapping is invalid.
-
program: It can only be mapped as RX-UED or RX-UED-VED, that is, readable and executable in users or two domains, but cannot be written.Any transaction that includes the program must fail.
-
Account: Only map or RW-UED can only be mapped.
System snapshot configure the voting program and system program to RX-Ued-VED.The system program provides a system account and voting program account to VED and mobile interfaces from VED.Actual update still requires a complete era to activate.
Only when the owner’s program is in the target domain can the account be re -mapped between the domains.Therefore, only voting program and system program accounts can move between VED and UED.
After using the general method, no explicit cost payment funds account is needed.Developers can re -map any system account between VED and UED to move funds between domains.
Calculate ved hash
After receiving the block, the node executes all transactions.The process is as follows:
-
Execution involves only transactions involving VED accounts.
-
The transaction of VED cost payment but a mixed account failed.
-
Skip all other transactions.
The generated VED status update is used to calculate the bank hash, that is, VED hash.Verifications can now vote with VED hash instead of the old bank hash.If there is a UED hash update since the last voting of the fork, the hash and slot will be included in the voting.
Calculate UED hash
After receiving the block, the node processs all transactions:
-
The accounts that are not in VED are considered part of UED.
-
Execution involves only transactions involving UED accounts.
-
The transaction containing UED expense payments but a mixed account failed.
-
Skip all other transactions.
The generated UED status update is used to calculate the bank hash, the UED hash.
Ultimate
Final sex remains unchanged.
Transaction execution status code
The side effects of asynchronous execution may not be detected immediately when voting.If 1/3 or more verificationers submit different UED hash, all nodes must stop confirmation and voting and warn operators.
To obtain status code, the RPC API request must allow users to specify the pledge observed by the same UED hash observation.The execution state can be expressed as ExecutionStatus (signature, pledge = x), where X can be 0 or a certain default value.In the settings of multiple nodes and clients, the X value is acceptable to 0, which brings users the confidence that is not confirmed and impossible.
Non -deterministic is the only failure that needs to be detected before returning the status code of confirmed transactions to the user. Therefore, the default value of x can usually be low to optimistic thresholds or about 5 %.
Leader and block generation
Leaders must be able to start creating blocks immediately after the VED is completed.This means that the leader will have part of the state and incomplete information of any UED cost payment.
-
Leaders execute the VED domain only for the blocks they created
-
UED loading must skip the invalid cost payment
Functional activation of voting procedures
The voting program must be designed when the VED voting may cross the Epoch boundary when the function is activated, and operates the time of other transactions that are in contact with the voting program in the UED.
award
Only in VED’s voting accounts should be rewarded.
punish
All voting accounts are risk of being punished whether they are active or VED.
Global clock update
The clock system variable is updated by voting.The alternative method should be used.On the contrary, each block leader can move the clock up to 1 second forward.At least 40%of the network requires maliciousness, and clocks can grow faster than actual time.The clock can also move forward for 400 milliseconds default.Assuming the drift of 50 milliseconds, only 12.5%of the leaders need to adjust the clock to keep synchronization.
