Blockchain -- arbitrum rollup (layer2)

Zeke Luo 2022-04-04 01:47:35 阅读数:516

blockchain arbitrum rollup layer2 layer

brief introduction

  • Arbitrum yes OffchainLabs Ethereum developed by the team Layer2 Layer expansion plan , Can achieve high throughput , Let developers deploy at low cost 、 Operating smart contracts , At the same time, it can keep the security without trust .
  • Rollup Technology strives to record all transaction data on the main chain , The core idea is to distribute a large amount of transaction data in the block , Aggregate into a deal , Publish to the main chain ; The actual calculation and storage of the contract are completed under the chain . In this way, the computing and storage pressure of the main chain will be reduced , So as to achieve high throughput of the network .
  • Transplant the contract from Ethereum to Arbitrum Fast and simple ; There is no need to change any code or download any new software . Just like Ethereum ,Arbitrum Fully support EVM. This means that all smart Contract languages applicable to Ethereum ( For example, all versions of Solidity、Vyper Yul) It can also be applied natively to Arbitrum. For detailed compatibility information , see also Solidity Support . Again , All standard Ethereum front end tools ( for example Truffle、Hardhat、The Graph、ethers.js) with Arbitrum Use with native . For more details , see also Front end Integration . And supports all Ethereum tools natively .
  • Although developers and users do not need to download any custom software to deploy the contract and communicate with Arbitrum Rollup Chain interaction , But some users may want to verify the chain themselves . Use Arbitrum Rollup when , Any honest user can guarantee the correct operation of the system , So as to ensure your safety . verification Arbitrum The chain is completely unlicensed ; All you need to do is download Arbitrum Validator Node software and point your nodes to the chain . To publish or challenge an assertion , You just need to place a bet , You will get back... After the claim is settled ( Suppose you act honestly ).
  • In short ,Arbitrum Enables you to interact and deploy smart contracts with you at a fraction of the cost of using Ethereum locally , And use all the same tools you use today to interact with Ethereum , Without affecting security or decentralization . Using this chain does not require custom tools , But anyone can choose to verify the chain .

Transaction invocation lifecycle

Before the user thinks the transaction is confirmed , Trading goes through many different stages , Start by ensuring the order of transactions , To ensure the completion of transaction execution . We submit the transaction from the user to a given sequencer ( It may be forwarded through another node ) From that point on .

  • A) sequencer The sequencer has placed an order and confirmed the transaction , But it hasn't been mass released to L1 On the chain . At this stage , If the user is willing to trust the sequencer , Then the transaction can be considered final , But malicious sequencers can undermine this finality . some time , We plan to add a layer of encryption economic security through binding and reduction , To punish the sequencer for ambiguity and violation of this trust .

  • B) The sorter is L1 Batches containing transactions are released on the chain . At this point ,sequencer No special power ( Suppose the batch is not from L1 In chain recombination ) And you don't need to be trusted at all . For users who don't want to rely on trust sorters , Their deal is now with the one that contains it L1 Confirmed as a batch transaction .

    Once the sorting is guaranteed , Suppose that any honest verifier will enforce the correct execution of the agreement , Then the result of the transaction is fully guaranteed .

  • C) The verifier creates assertions , Assert the result of the user transaction ; Please note that , The verifier has no right to review / Exclude your transaction ( namely , They are forced to include the next transaction in the queue ) And has no right to reorder . Other verifiers can also pledge the assertion . here , If the user trusts at least one verifier ( Or be a verifier ), Then it can be considered that the transaction is completely credible .

  • D) 7 The challenge period of days is over , The assertion is confirmed . At this time, the trading result is completely locked in L1 On the chain .

ArbGas / cost

  • ArbGas The principle of operation is similar to that of Ethereum gas similar , Used to measure Arbitrum Computing costs on the chain .
  • However ,Arbitrum The chain doesn't have a hard one ArbGas limit requirement , also ArbGas It costs more than Ethereum gas It's much faster .
  • ArbGas A key role of is to provide a predictable measure of the time required to verify the results of the calculation .
  • every last rollup Every block contains a link on the chain ArbGas Statement of total consumption , This means that the difference between the declaration of the current block and that of the previous block should be how much the current block consumes ArbGas Effective indicators of .
  • In this way , When checking the validity of a block , The verifier can put their gas limit Set to this value , If these ArbGas It runs out before the block completes execution , Then it can be determined that this is an invalid block , And successfully challenged the invalid block .
  • When a user submits a transaction to the chain , Will be charged .
  • If users send their transactions to an aggregator , Then part of the cost will be automatically paid to the aggregator .
  • The remaining fees will be sent to the network fee pool , It is used to pay for the service fee to ensure the safe operation of the whole chain .
  • The cost also includes L2 transaction 、L1 The data call 、 Computing and storage costs .
  • The cost is ETH Form of payment .

throughput

  • Because of all Arbitrum All transaction data are released to Ethereum , So the cost of each transaction and Arbitrum The number of transactions that can be supported per second is limited by the amount of data that can be published to Ethereum during this period . For this reason , Optimizing transaction compression to minimize content that needs to be published on the chain is critical to reducing costs and improving throughput .
  • For simple transfer transactions that do not carry their own call data , Our benchmark shows that ,Arbitrum Will allow up to... Per second 4,500 A transfer transaction

Cross contract communication

  • Distinguish between Ethereum and Arbitrum Call and from Arbitrum The call to Ethereum is very important . Ethereum contracts can send transactions to fast arriving Arbitrum. However , from Arbitrum Generally, the transaction speed to Ethereum is slow , Because they need to wait for the challenge period to expire before they can be confirmed . Fortunately, , There are some elegant solutions that allow users to quickly move alternative assets from Arbitrum Extracted to Ethereum

Arbitrum virtual machine

  • Even though Arbitrum Support EVM, But what it runs at the bottom is Arbitrum virtual machine (AVM).AVM Never exposed to developers or users , So if you just know how to use Arbitrum Interested in , You can safely ignore it . however , If you are right about Arbitrum I'm curious about the internal working principle of and how it can be scalable , Please continue to read the following AVN Design principle

    AVM Design principle :

  1. AVM The starting point of the design is Ethereum virtual machine (EVM). because Arbitrum Designed to perform efficiently for EVM A program written or compiled , therefore Arbitrum Use EVM Many aspects of have not changed . for example ,AVM use EVM The basic integer data type (256 Bit large unsigned integer ), And right EVM An instruction that operates on an integer .
  2. AVM and EVM The difference between is caused by Arbitrum Of the 2 Requirements and requirements of layer protocol Arbitrum Use multi round challenge agreements to resolve disputes
  3. View details :AVM design rationale · Offchain Labs Dev Center

ArbOS

ArbOS yes Arbitrum operating system , be located AVM above , Responsible for isolating untrusted contracts from each other , Use ArbGas Track and limit their resource use , And manage economic model validators that charge users to fund the operation of the chain .ArbOS Will be passed in L1 The work done in the smart contract is unloaded to a cheaper L2 In the code , by Arbitrum Provides great flexibility . To learn more , see also ArbOS part .

L1 and L2 Differences in use process :

  • L1-L2 Deposit Probably 10 minute

  • L2-L1 withdraw need 8 God   

  • L2-L2 tranfer Second level

Why 8 God , Because for the basic requirements of safety ; It ensures that the verifier has enough time to synchronize with the chain to issue disputes when needed . let me put it another way , Because we are not in L1 Validate transactions , We need to give L2 Time to detect and prove fraud ( Is to use this 8 It's time to check the flow of all your transactions , Make sure your ledger is OK , Then publish to L1 Synchronize data on the chain )  

How to make L1 In exchange for L2

  • The first is Arbitrum official bridge Conduct Deposit    
  1.   Specific address :Arbitrum Bridge ( Support test network , And formal networks )    
  • The second is in other cross chain Bridge Exchange                                                                                               
  1. cbridge : The Best Crypto & Binance Bridge | cBridge ( The test network is not supported temporarily )                               
  2.  multichain: https://app.multichain.org/#/router ( The test network is not supported temporarily )  


Development Safety precautions and traps ( Development must see )

Hope that in Arbitrum Ethereum built on dApp Developers often find experience 、 Very familiar with tools and protocol principles ; in other words , Developers should pay attention to some important considerations and “ trap ”. For many smart contract applications , None of the following applies , But it is recommended that developers investigate

  • Different EVM/Soldity Behavior :Arbitrum Support each EVM opcode , This means that whatever you write Solidity( or Vyper、Yuul etc. ) Will be in Arbitrum Compile and run on . however , Some operations are in Arbitrum On the behavior and in Ethereum Different behavior on ; For a complete list , see also Solidity Support . Besides ,Arbitrum Support most ( But not all ) The etheric fang precompile .
  • With block number and timestamp Timing assumptions : People may be in the first 1 The timing assumptions made by the layer block.timestampblock.number On average 15 Seconds will produce a new block ) Not in Arbitrum On the establishment of . new “L2 block ” The birth of / The rate depicted is not reliably predicted ;block.timestamp Is in Arbitrum A better way to measure time on , But even so , Dependencies should only be completed within a large time frame L2block.timestamp or L2 To measure time .block.number For more information , see also Block number and time
  • L1-to-L2 Transactions' Address Aliases :“ Retryable ticket ” Is a special type of transaction , For from L1 towards L2 Send a message ; If you plan to use them , It is strongly recommended that you read their... Before deploying to the main web file And carefully test the behavior of your contract . Particular attention : On the receiving side L2 In the news ,msg.sender Not return L1 contract , It's going back to Address alias
  • L1-to-L2 Failed to create ticket for transaction : If you underpaid the basic submission fee when trying to create a retrieable ticket , Well, just confirm L1 transaction , But not in L2 Create ticket on ; This may be possible. —— It depends on what your cross chain application is doing —— Very bad. . The current basic submission fee can be queried directly from the arbitration node , Every time 24 Update every hour ; For a given update , It can increase its previous value up to 50%. Any amount you overpay will not be lost ; It will be in the... You specify L2 Address collection . For safety's sake , We strongly recommend that you pay more .( In future versions , The basic submission cost will be directly in L1 On collection , Completely avoid the above failure modes .)
  • Hard coded gas value ArbGas And Ethereum L1 Gases are different ; therefore , If you deploy to without modification L2, It's in L1 Contracts with hard coded values that work on may break ; The hard coded gas value should be adjusted ( Or better yet , If possible , Completely delete ( This may be possible ; Really? , Why do you hard code the gas value ?))
  • ETH Special deposit behavior : Retryable tickets are used in a special way to process from L1 To Arbitrum Of ETH deposit ; If your application will directly use Ether deposit , It is worth knowing Its design details . Besides , No need to L2 Publish a signed transaction on the website to Ether Credited L2 The ability of the account will produce some L1 The impossible behavior , That is, there is no need to trigger its Receive fallback function Can be Ether Ability to enter into the contract .
  • Randomness Block hash of : Should not rely on Arbitrum Of L2 Block hash as a safe source of randomness .

If you don't understand or have questions, please contact me for communication

WC:luo425116243

版权声明:本文为[Zeke Luo]所创,转载请带上原文链接,感谢。 https://netfreeman.com/2022/04/202204040141584483.html