Ethereum EIPs A feed of all EIPs https://eips.ethereum.org Sat, 09 May 2026 22:45:35 +0000 / <style type="text/css" media="screen"> .container { margin: 10px auto; max-width: 600px; text-align: center; } h1 { margin: 30px 0; font-size: 4em; line-height: 1; letter-spacing: -1px; } </style> <div class="container"> <h1>404</h1> <p><strong>Page not found :(</strong></p> <p>The requested page could not be found.</p> </div> https://eips.ethereum.org/404 https://eips.ethereum.org/404 / <p>This set of interfaces and contracts are all related to the <a href="https://eips.ethereum.org/EIPS/eip-1155">ERC1155 Multi Token Standard</a>.</p> <p>The EIP consists of two interfaces which fulfill different roles, found here as <code class="language-plaintext highlighter-rouge">IERC1155</code> and <code class="language-plaintext highlighter-rouge">IERC1155TokenReceiver</code>. Only <code class="language-plaintext highlighter-rouge">IERC1155</code> is required for a contract to be ERC1155 compliant. The basic functionality is implemented in <code class="language-plaintext highlighter-rouge">ERC1155</code>.</p> https://eips.ethereum.org/assets/eip-3267/contracts/ERC1155/README https://eips.ethereum.org/assets/eip-3267/contracts/ERC1155/README All / <style type="text/css"> .eiptable .title { width: 67%; } .eiptable .author { width: 33%; } </style> <h2 id="living">Living</h2> <table class="eiptable"> <thead> <tr><th class="eipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr> </thead> <tr> <td class="eipnum"><a href="/EIPS/eip-1">1</a></td> <td class="title">EIP Purpose and Guidelines</td> <td class="author">Martin Becze&nbsp;&lt;<a href="mailto:mb@ethereum.org">mb@ethereum.org</a>&gt;, Hudson Jameson&nbsp;&lt;<a href="mailto:hudson@ethereum.org">hudson@ethereum.org</a>&gt;, et al.</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5069">5069</a></td> <td class="title">EIP Editor Handbook</td> <td class="author">Pooja Ranjan&nbsp;(<a href="https://github.com/poojaranjan">@poojaranjan</a>), Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>), et al.</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7870">7870</a></td> <td class="title">Hardware and Bandwidth Recommendations</td> <td class="author">Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithosh">@parithosh</a>), Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>), Josh Rudolf&nbsp;(<a href="https://github.com/jrudolf">@jrudolf</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Justin Traglia&nbsp;(<a href="https://github.com/jtraglia">@jtraglia</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), George Kadianakis&nbsp;(<a href="https://github.com/asn-d6">@asn-d6</a>), Fredrik Svantes&nbsp;(<a href="https://github.com/fredriksvantes">@fredriksvantes</a>), Carl Beekhuizen&nbsp;(<a href="https://github.com/carlbeek">@carlbeek</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> </table> <h2 id="final">Final</h2> <table class="eiptable"> <thead> <tr><th class="eipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr> </thead> <tr> <td class="eipnum"><a href="/EIPS/eip-2">2</a></td> <td class="title">Homestead Hard-fork Changes</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4">4</a></td> <td class="title">EIP Classification</td> <td class="author">Joseph Chow&nbsp;(<a href="https://github.com/ethers">@ethers</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5">5</a></td> <td class="title">Gas Usage for `RETURN` and `CALL*`</td> <td class="author">Christian Reitwiessner&nbsp;&lt;<a href="mailto:c@ethdev.com">c@ethdev.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6">6</a></td> <td class="title">Renaming SUICIDE opcode</td> <td class="author">Hudson Jameson&nbsp;&lt;<a href="mailto:hudson@hudsonjameson.com">hudson@hudsonjameson.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7">7</a></td> <td class="title">DELEGATECALL</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8">8</a></td> <td class="title">devp2p Forward Compatibility Requirements for Homestead</td> <td class="author">Felix Lange&nbsp;&lt;<a href="mailto:felix@ethdev.com">felix@ethdev.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-20">20</a></td> <td class="title">Token Standard</td> <td class="author">Fabian Vogelsteller&nbsp;&lt;<a href="mailto:fabian@ethereum.org">fabian@ethereum.org</a>&gt;, Vitalik Buterin&nbsp;&lt;<a href="mailto:vitalik.buterin@ethereum.org">vitalik.buterin@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-55">55</a></td> <td class="title">Mixed-case checksum address encoding</td> <td class="author">Vitalik Buterin&nbsp;&lt;<a href="mailto:vitalik.buterin@ethereum.org">vitalik.buterin@ethereum.org</a>&gt;, Alex Van de Sande&nbsp;&lt;<a href="mailto:avsa@ethereum.org">avsa@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-100">100</a></td> <td class="title">Change difficulty adjustment to target mean block time including uncles</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-137">137</a></td> <td class="title">Ethereum Domain Name Service - Specification</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:arachnid@notdot.net">arachnid@notdot.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-140">140</a></td> <td class="title">REVERT instruction</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Nikolai Mushegian&nbsp;&lt;<a href="mailto:nikolai@nexusdev.us">nikolai@nexusdev.us</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-141">141</a></td> <td class="title">Designated invalid EVM instruction</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-145">145</a></td> <td class="title">Bitwise shifting instructions in EVM</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-150">150</a></td> <td class="title">Gas cost changes for IO-heavy operations</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-152">152</a></td> <td class="title">Add BLAKE2 compression function `F` precompile</td> <td class="author">Tjaden Hess&nbsp;&lt;<a href="mailto:tah83@cornell.edu">tah83@cornell.edu</a>&gt;, Matt Luongo&nbsp;(<a href="https://github.com/mhluongo">@mhluongo</a>), Piotr Dyraga&nbsp;(<a href="https://github.com/pdyraga">@pdyraga</a>), James Hancock&nbsp;(<a href="https://github.com/MadeOfTin">@MadeOfTin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-155">155</a></td> <td class="title">Simple replay attack protection</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-158">158</a></td> <td class="title">State clearing</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-160">160</a></td> <td class="title">EXP cost increase</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-161">161</a></td> <td class="title">State trie clearing (invariant-preserving alternative)</td> <td class="author">Gavin Wood&nbsp;(<a href="https://github.com/gavofyork">@gavofyork</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-162">162</a></td> <td class="title">Initial ENS Hash Registrar</td> <td class="author">Maurelian, Nick Johnson&nbsp;&lt;<a href="mailto:nick@ethereum.org">nick@ethereum.org</a>&gt;, Alex Van de Sande&nbsp;&lt;<a href="mailto:avsa@ethereum.org">avsa@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-165">165</a></td> <td class="title">Standard Interface Detection</td> <td class="author">Christian Reitwießner&nbsp;&lt;<a href="mailto:chris@ethereum.org">chris@ethereum.org</a>&gt;, Nick Johnson&nbsp;&lt;<a href="mailto:nick@ethereum.org">nick@ethereum.org</a>&gt;, Fabian Vogelsteller&nbsp;&lt;<a href="mailto:fabian@lukso.network">fabian@lukso.network</a>&gt;, Jordi Baylina&nbsp;&lt;<a href="mailto:jordi@baylina.cat">jordi@baylina.cat</a>&gt;, Konrad Feldmeier&nbsp;&lt;<a href="mailto:konrad.feldmeier@brainbot.com">konrad.feldmeier@brainbot.com</a>&gt;, William Entriken&nbsp;&lt;<a href="mailto:github.com@phor.net">github.com@phor.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-170">170</a></td> <td class="title">Contract code size limit</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-173">173</a></td> <td class="title">Contract Ownership Standard</td> <td class="author">Nick Mudge&nbsp;(<a href="https://github.com/mudgen">@mudgen</a>), Dan Finlay&nbsp;&lt;<a href="mailto:dan@danfinlay.com">dan@danfinlay.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-181">181</a></td> <td class="title">ENS support for reverse resolution of Ethereum addresses</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:arachnid@notdot.net">arachnid@notdot.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-190">190</a></td> <td class="title">Ethereum Smart Contract Packaging Standard</td> <td class="author">Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>), Tim Coulter&nbsp;(<a href="https://github.com/tcoulter">@tcoulter</a>), Denis Erfurt&nbsp;(<a href="https://github.com/mhhf">@mhhf</a>), RJ Catalano&nbsp;(<a href="https://github.com/VoR0220">@VoR0220</a>), Iuri Matias&nbsp;(<a href="https://github.com/iurimatias">@iurimatias</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-191">191</a></td> <td class="title">Signed Data Standard</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), Nick Johnson&nbsp;&lt;<a href="mailto:arachnid@notdot.net">arachnid@notdot.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-196">196</a></td> <td class="title">Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128</td> <td class="author">Christian Reitwiessner&nbsp;&lt;<a href="mailto:chris@ethereum.org">chris@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-197">197</a></td> <td class="title">Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128</td> <td class="author">Vitalik Buterin&nbsp;&lt;<a href="mailto:vitalik@ethereum.org">vitalik@ethereum.org</a>&gt;, Christian Reitwiessner&nbsp;&lt;<a href="mailto:chris@ethereum.org">chris@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-198">198</a></td> <td class="title">Big integer modular exponentiation</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-211">211</a></td> <td class="title">New opcodes: RETURNDATASIZE and RETURNDATACOPY</td> <td class="author">Christian Reitwiessner&nbsp;&lt;<a href="mailto:chris@ethereum.org">chris@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-214">214</a></td> <td class="title">New opcode STATICCALL</td> <td class="author">Vitalik Buterin&nbsp;&lt;<a href="mailto:vitalik@ethereum.org">vitalik@ethereum.org</a>&gt;, Christian Reitwiessner&nbsp;&lt;<a href="mailto:chris@ethereum.org">chris@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-223">223</a></td> <td class="title">Token with transaction handling model</td> <td class="author">Dexaran (@Dexaran)&nbsp;&lt;<a href="mailto:dexaran@ethereumclassic.org">dexaran@ethereumclassic.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-225">225</a></td> <td class="title">Clique proof-of-authority consensus protocol</td> <td class="author">Péter Szilágyi&nbsp;&lt;<a href="mailto:peterke@gmail.com">peterke@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-234">234</a></td> <td class="title">Add `blockHash` to JSON-RPC filter options.</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-600">600</a></td> <td class="title">Ethereum purpose allocation for Deterministic Wallets</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>), Micah Zoltu&nbsp;(<a href="https://github.com/micahzoltu">@micahzoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-601">601</a></td> <td class="title">Ethereum hierarchy for deterministic wallets</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>), Micah Zoltu&nbsp;(<a href="https://github.com/micahzoltu">@micahzoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-606">606</a></td> <td class="title">Hardfork Meta: Homestead</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-607">607</a></td> <td class="title">Hardfork Meta: Spurious Dragon</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-608">608</a></td> <td class="title">Hardfork Meta: Tangerine Whistle</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-609">609</a></td> <td class="title">Hardfork Meta: Byzantium</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-627">627</a></td> <td class="title">Whisper Specification</td> <td class="author">Vlad Gluhovsky&nbsp;&lt;<a href="mailto:gluk256@gmail.com">gluk256@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-649">649</a></td> <td class="title">Metropolis Difficulty Bomb Delay and Block Reward Reduction</td> <td class="author">Afri Schoedon&nbsp;(<a href="https://github.com/5chdn">@5chdn</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-658">658</a></td> <td class="title">Embedding transaction status code in receipts</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:nick@ethereum.org">nick@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-681">681</a></td> <td class="title">URL Format for Transaction Requests</td> <td class="author">Daniel A. Nagy&nbsp;(<a href="https://github.com/nagydani">@nagydani</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-684">684</a></td> <td class="title">Revert creation in case of collision</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Renan Rodrigues de Souza&nbsp;(<a href="https://github.com/RenanSouza2">@RenanSouza2</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-695">695</a></td> <td class="title">Create `eth_chainId` method for JSON-RPC</td> <td class="author">Isaac Ardis&nbsp;&lt;<a href="mailto:isaac.ardis@gmail.com">isaac.ardis@gmail.com</a>&gt;, Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>), Fan Torchz&nbsp;(<a href="https://github.com/tcz001">@tcz001</a>), Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-706">706</a></td> <td class="title">DEVp2p snappy compression</td> <td class="author">Péter Szilágyi&nbsp;&lt;<a href="mailto:peter@ethereum.org">peter@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-712">712</a></td> <td class="title">Typed structured data hashing and signing</td> <td class="author">Remco Bloemen&nbsp;(<a href="https://github.com/Recmo">@Recmo</a>), Leonid Logvinov&nbsp;(<a href="https://github.com/LogvinovLeon">@LogvinovLeon</a>), Jacob Evans&nbsp;(<a href="https://github.com/dekz">@dekz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-721">721</a></td> <td class="title">Non-Fungible Token Standard</td> <td class="author">William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>), Dieter Shirley&nbsp;&lt;<a href="mailto:dete@axiomzen.co">dete@axiomzen.co</a>&gt;, Jacob Evans&nbsp;&lt;<a href="mailto:jacob@dekz.net">jacob@dekz.net</a>&gt;, Nastassia Sachs&nbsp;&lt;<a href="mailto:nastassia.sachs@protonmail.com">nastassia.sachs@protonmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-747">747</a></td> <td class="title">wallet_watchAsset RPC Method</td> <td class="author">Dan Finlay&nbsp;(<a href="https://github.com/danfinlay">@danfinlay</a>), Esteban Mino&nbsp;(<a href="https://github.com/estebanmino">@estebanmino</a>), Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-777">777</a></td> <td class="title">Token Standard</td> <td class="author">Jacques Dafflon&nbsp;&lt;<a href="mailto:mail@0xjac.com">mail@0xjac.com</a>&gt;, Jordi Baylina&nbsp;&lt;<a href="mailto:jordi@baylina.cat">jordi@baylina.cat</a>&gt;, Thomas Shababi&nbsp;&lt;<a href="mailto:tom@truelevel.io">tom@truelevel.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-778">778</a></td> <td class="title">Ethereum Node Records (ENR)</td> <td class="author">Felix Lange&nbsp;&lt;<a href="mailto:fjl@ethereum.org">fjl@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-779">779</a></td> <td class="title">Hardfork Meta: DAO Fork</td> <td class="author">Casey Detrio&nbsp;(<a href="https://github.com/cdetrio">@cdetrio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-820">820</a></td> <td class="title">Pseudo-introspection Registry Contract</td> <td class="author">Jordi Baylina&nbsp;&lt;<a href="mailto:jordi@baylina.cat">jordi@baylina.cat</a>&gt;, Jacques Dafflon&nbsp;&lt;<a href="mailto:jacques@dafflon.tech">jacques@dafflon.tech</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-868">868</a></td> <td class="title">Node Discovery v4 ENR Extension</td> <td class="author">Felix Lange&nbsp;&lt;<a href="mailto:fjl@ethereum.org">fjl@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1013">1013</a></td> <td class="title">Hardfork Meta: Constantinople</td> <td class="author">Nick Savers&nbsp;(<a href="https://github.com/nicksavers">@nicksavers</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1014">1014</a></td> <td class="title">Skinny CREATE2</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1046">1046</a></td> <td class="title">tokenURI Interoperability</td> <td class="author">Tommy Nicholas&nbsp;(<a href="https://github.com/tomasienrbc">@tomasienrbc</a>), Matt Russo&nbsp;(<a href="https://github.com/mateosu">@mateosu</a>), John Zettler&nbsp;(<a href="https://github.com/JohnZettler">@JohnZettler</a>), Matt Condon&nbsp;(<a href="https://github.com/shrugs">@shrugs</a>), Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1052">1052</a></td> <td class="title">EXTCODEHASH opcode</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:arachnid@notdot.net">arachnid@notdot.net</a>&gt;, Paweł Bylica&nbsp;&lt;<a href="mailto:pawel@ethereum.org">pawel@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1108">1108</a></td> <td class="title">Reduce alt_bn128 precompile gas costs</td> <td class="author">Antonio Salazar Cardozo&nbsp;(<a href="https://github.com/shadowfiend">@shadowfiend</a>), Zachary Williamson&nbsp;(<a href="https://github.com/zac-williamson">@zac-williamson</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1153">1153</a></td> <td class="title">Transient storage opcodes</td> <td class="author">Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>), Moody Salem&nbsp;(<a href="https://github.com/moodysalem">@moodysalem</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1155">1155</a></td> <td class="title">Multi Token Standard</td> <td class="author">Witek Radomski&nbsp;&lt;<a href="mailto:witek@enjin.io">witek@enjin.io</a>&gt;, Andrew Cooke&nbsp;&lt;<a href="mailto:ac0dem0nk3y@gmail.com">ac0dem0nk3y@gmail.com</a>&gt;, Philippe Castonguay (@phabc)&nbsp;&lt;<a href="mailto:pc@horizongames.net">pc@horizongames.net</a>&gt;, James Therien&nbsp;&lt;<a href="mailto:james@turing-complete.com">james@turing-complete.com</a>&gt;, Eric Binet&nbsp;&lt;<a href="mailto:eric@enjin.io">eric@enjin.io</a>&gt;, Ronan Sandford (@wighawag)&nbsp;&lt;<a href="mailto:wighawag@gmail.com">wighawag@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1167">1167</a></td> <td class="title">Minimal Proxy Contract</td> <td class="author">Peter Murray&nbsp;(<a href="https://github.com/yarrumretep">@yarrumretep</a>), Nate Welch&nbsp;(<a href="https://github.com/flygoing">@flygoing</a>), Joe Messerman&nbsp;(<a href="https://github.com/JAMesserman">@JAMesserman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1193">1193</a></td> <td class="title">Ethereum Provider JavaScript API</td> <td class="author">Fabian Vogelsteller&nbsp;(<a href="https://github.com/frozeman">@frozeman</a>), Ryan Ghods&nbsp;(<a href="https://github.com/ryanio">@ryanio</a>), Victor Maia&nbsp;(<a href="https://github.com/MaiaVictor">@MaiaVictor</a>), Marc Garreau&nbsp;(<a href="https://github.com/wolovim">@wolovim</a>), Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1234">1234</a></td> <td class="title">Constantinople Difficulty Bomb Delay and Block Reward Adjustment</td> <td class="author">Afri Schoedon&nbsp;(<a href="https://github.com/5chdn">@5chdn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1271">1271</a></td> <td class="title">Standard Signature Validation Method for Contracts</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Matt Condon&nbsp;(<a href="https://github.com/shrugs">@shrugs</a>), Philippe Castonguay&nbsp;(<a href="https://github.com/PhABC">@PhABC</a>), Amir Bandeali&nbsp;(<a href="https://github.com/abandeali1">@abandeali1</a>), Jorge Izquierdo&nbsp;(<a href="https://github.com/izqui">@izqui</a>), Bertrand Masius&nbsp;(<a href="https://github.com/catageek">@catageek</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1283">1283</a></td> <td class="title">Net gas metering for SSTORE without dirty maps</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1328">1328</a></td> <td class="title">WalletConnect URI Format</td> <td class="author">ligi&nbsp;(<a href="https://github.com/ligi">@ligi</a>), Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1344">1344</a></td> <td class="title">ChainID opcode</td> <td class="author">Richard Meissner&nbsp;(<a href="https://github.com/rmeissner">@rmeissner</a>), Bryant Eisenbach&nbsp;(<a href="https://github.com/fubuloubu">@fubuloubu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1363">1363</a></td> <td class="title">Payable Token</td> <td class="author">Vittorio Minacori&nbsp;(<a href="https://github.com/vittominacori">@vittominacori</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1559">1559</a></td> <td class="title">Fee market change for ETH 1.0 chain</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Eric Conner&nbsp;(<a href="https://github.com/econoar">@econoar</a>), Rick Dudley&nbsp;(<a href="https://github.com/AFDudley">@AFDudley</a>), Matthew Slipper&nbsp;(<a href="https://github.com/mslipper">@mslipper</a>), Ian Norden&nbsp;(<a href="https://github.com/i-norden">@i-norden</a>), Abdelhamid Bakhta&nbsp;(<a href="https://github.com/abdelhamidbakhta">@abdelhamidbakhta</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1679">1679</a></td> <td class="title">Hardfork Meta: Istanbul</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Afri Schoedon&nbsp;(<a href="https://github.com/5chdn">@5chdn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1716">1716</a></td> <td class="title">Hardfork Meta: Petersburg</td> <td class="author">Afri Schoedon&nbsp;(<a href="https://github.com/5chdn">@5chdn</a>), Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1820">1820</a></td> <td class="title">Pseudo-introspection Registry Contract</td> <td class="author">Jordi Baylina&nbsp;&lt;<a href="mailto:jordi@baylina.cat">jordi@baylina.cat</a>&gt;, Jacques Dafflon&nbsp;&lt;<a href="mailto:mail@0xjac.com">mail@0xjac.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1884">1884</a></td> <td class="title">Repricing for trie-size-dependent opcodes</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1898">1898</a></td> <td class="title">Add `blockHash` to defaultBlock methods</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1967">1967</a></td> <td class="title">Proxy Storage Slots</td> <td class="author">Santiago Palladino&nbsp;(<a href="https://github.com/spalladino">@spalladino</a>), Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2028">2028</a></td> <td class="title">Transaction data gas cost reduction</td> <td class="author">Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>), Eli Ben Sasson&nbsp;&lt;<a href="mailto:eli@starkware.co">eli@starkware.co</a>&gt;, Tom Brand&nbsp;&lt;<a href="mailto:tom@starkware.co">tom@starkware.co</a>&gt;, Louis Guthmann&nbsp;&lt;<a href="mailto:louis@starkware.co">louis@starkware.co</a>&gt;, Avihu Levy&nbsp;&lt;<a href="mailto:avihu@starkware.co">avihu@starkware.co</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2098">2098</a></td> <td class="title">Compact Signature Representation</td> <td class="author">Richard Moore&nbsp;(<a href="https://github.com/ricmoo">@ricmoo</a>), Nick Johnson&nbsp;&lt;<a href="mailto:nick@ethereum.org">nick@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2124">2124</a></td> <td class="title">Fork identifier for chain compatibility checks</td> <td class="author">Péter Szilágyi&nbsp;&lt;<a href="mailto:peterke@gmail.com">peterke@gmail.com</a>&gt;, Felix Lange&nbsp;&lt;<a href="mailto:fjl@ethereum.org">fjl@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2135">2135</a></td> <td class="title">Consumable Interface (Tickets, etc)</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2159">2159</a></td> <td class="title">Common Prometheus Metrics Names for Clients</td> <td class="author">Adrian Sutton&nbsp;(<a href="https://github.com/ajsutton">@ajsutton</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2200">2200</a></td> <td class="title">Structured Definitions for Net Gas Metering</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2228">2228</a></td> <td class="title">Canonicalize the name of network ID 1 and chain ID 1</td> <td class="author">William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2255">2255</a></td> <td class="title">Wallet Permissions System</td> <td class="author">Dan Finlay&nbsp;(<a href="https://github.com/danfinlay">@danfinlay</a>), Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>), Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2309">2309</a></td> <td class="title">ERC-721 Consecutive Transfer Extension</td> <td class="author">Sean Papanikolas&nbsp;(<a href="https://github.com/pizzarob">@pizzarob</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2364">2364</a></td> <td class="title">eth/64: forkid-extended protocol handshake</td> <td class="author">Péter Szilágyi&nbsp;&lt;<a href="mailto:peterke@gmail.com">peterke@gmail.com</a>&gt;, Péter Szilágyi&nbsp;(<a href="https://github.com/karalabe">@karalabe</a>), Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2384">2384</a></td> <td class="title">Muir Glacier Difficulty Bomb Delay</td> <td class="author">Eric Conner&nbsp;(<a href="https://github.com/econoar">@econoar</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2387">2387</a></td> <td class="title">Hardfork Meta: Muir Glacier</td> <td class="author">James Hancock&nbsp;(<a href="https://github.com/madeoftin">@madeoftin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2464">2464</a></td> <td class="title">eth/65: transaction announcements and retrievals</td> <td class="author">Péter Szilágyi&nbsp;&lt;<a href="mailto:peterke@gmail.com">peterke@gmail.com</a>&gt;, Péter Szilágyi&nbsp;(<a href="https://github.com/karalabe">@karalabe</a>), Gary Rong&nbsp;&lt;<a href="mailto:garyrong0905@gmail.com">garyrong0905@gmail.com</a>&gt;, Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2481">2481</a></td> <td class="title">eth/66 request identifier</td> <td class="author">Christoph Burgdorf&nbsp;(<a href="https://github.com/cburgdorf">@cburgdorf</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2535">2535</a></td> <td class="title">Diamonds, Multi-Facet Proxy</td> <td class="author">Nick Mudge&nbsp;(<a href="https://github.com/mudgen">@mudgen</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2537">2537</a></td> <td class="title">Precompile for BLS12-381 curve operations</td> <td class="author">Alex Vlasov&nbsp;(<a href="https://github.com/shamatar">@shamatar</a>), Kelly Olson&nbsp;(<a href="https://github.com/ineffectualproperty">@ineffectualproperty</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Antonio Sanso&nbsp;(<a href="https://github.com/asanso">@asanso</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2565">2565</a></td> <td class="title">ModExp Gas Cost</td> <td class="author">Kelly Olson&nbsp;(<a href="https://github.com/ineffectualproperty">@ineffectualproperty</a>), Sean Gulley&nbsp;(<a href="https://github.com/sean-sn">@sean-sn</a>), Simon Peffers&nbsp;(<a href="https://github.com/simonatsn">@simonatsn</a>), Justin Drake&nbsp;(<a href="https://github.com/justindrake">@justindrake</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2612">2612</a></td> <td class="title">Permit Extension for EIP-20 Signed Approvals</td> <td class="author">Martin Lundfall&nbsp;(<a href="https://github.com/Mrchico">@Mrchico</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2678">2678</a></td> <td class="title">Revised Ethereum Smart Contract Packaging Standard (EthPM v3)</td> <td class="author">g. nicholas d’andrea&nbsp;(<a href="https://github.com/gnidan">@gnidan</a>), Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>), Nick Gheorghita&nbsp;(<a href="https://github.com/njgheorghita">@njgheorghita</a>), Christian Reitwiessner&nbsp;(<a href="https://github.com/chriseth">@chriseth</a>), Ben Hauser&nbsp;(<a href="https://github.com/iamdefinitelyahuman">@iamdefinitelyahuman</a>), Bryant Eisenbach&nbsp;(<a href="https://github.com/fubuloubu">@fubuloubu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2681">2681</a></td> <td class="title">Limit account nonce to 2^64-1</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2696">2696</a></td> <td class="title">JavaScript `request` method RPC transport</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>), Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2700">2700</a></td> <td class="title">JavaScript Provider Event Emitter</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>), Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2718">2718</a></td> <td class="title">Typed Transaction Envelope</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2771">2771</a></td> <td class="title">Secure Protocol for Native Meta Transactions</td> <td class="author">Ronan Sandford&nbsp;(<a href="https://github.com/wighawag">@wighawag</a>), Liraz Siri&nbsp;(<a href="https://github.com/lirazsiri">@lirazsiri</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Sachin Tomar&nbsp;(<a href="https://github.com/tomarsachin2271">@tomarsachin2271</a>), Patrick McCorry&nbsp;(<a href="https://github.com/stonecoldpat">@stonecoldpat</a>), Nicolas Venturo&nbsp;(<a href="https://github.com/nventuro">@nventuro</a>), Fabian Vogelsteller&nbsp;(<a href="https://github.com/frozeman">@frozeman</a>), Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2929">2929</a></td> <td class="title">Gas cost increases for state access opcodes</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Martin Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2930">2930</a></td> <td class="title">Optional access lists</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Martin Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2935">2935</a></td> <td class="title">Serve historical block hashes from state</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Tomasz Stanczak&nbsp;(<a href="https://github.com/tkstanczak">@tkstanczak</a>), Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Tanishq Jasoria&nbsp;(<a href="https://github.com/tanishqjasoria">@tanishqjasoria</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Sina Mahmoodi&nbsp;(<a href="https://github.com/s1na">@s1na</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2976">2976</a></td> <td class="title">Typed Transactions over Gossip</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2981">2981</a></td> <td class="title">NFT Royalty Standard</td> <td class="author">Zach Burks&nbsp;(<a href="https://github.com/vexycats">@vexycats</a>), James Morgan&nbsp;(<a href="https://github.com/jamesmorgan">@jamesmorgan</a>), Blaine Malone&nbsp;(<a href="https://github.com/blmalone">@blmalone</a>), James Seibel&nbsp;(<a href="https://github.com/seibelj">@seibelj</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2982">2982</a></td> <td class="title">Serenity Phase 0</td> <td class="author">Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3156">3156</a></td> <td class="title">Flash Loans</td> <td class="author">Alberto Cuesta Cañada&nbsp;(<a href="https://github.com/alcueca">@alcueca</a>), Fiona Kobayashi&nbsp;(<a href="https://github.com/fifikobayashi">@fifikobayashi</a>), fubuloubu&nbsp;(<a href="https://github.com/fubuloubu">@fubuloubu</a>), Austin Williams&nbsp;(<a href="https://github.com/onewayfunction">@onewayfunction</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3198">3198</a></td> <td class="title">BASEFEE opcode</td> <td class="author">Abdelhamid Bakhta&nbsp;(<a href="https://github.com/abdelhamidbakhta">@abdelhamidbakhta</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3448">3448</a></td> <td class="title">MetaProxy Standard</td> <td class="author">pinkiebell&nbsp;(<a href="https://github.com/pinkiebell">@pinkiebell</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3475">3475</a></td> <td class="title">Abstract Storage Bonds</td> <td class="author">Yu Liu&nbsp;(<a href="https://github.com/yuliu-debond">@yuliu-debond</a>), Varun Deshpande&nbsp;(<a href="https://github.com/dr-chain">@dr-chain</a>), Cedric Ngakam&nbsp;(<a href="https://github.com/drikssy">@drikssy</a>), Dhruv Malik&nbsp;(<a href="https://github.com/dhruvmalik007">@dhruvmalik007</a>), Samuel Gwlanold Edoumou&nbsp;(<a href="https://github.com/Edoumou">@Edoumou</a>), Toufic Batrice&nbsp;(<a href="https://github.com/toufic0710">@toufic0710</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3525">3525</a></td> <td class="title">Semi-Fungible Token</td> <td class="author">Will Wang&nbsp;(<a href="https://github.com/will42w">@will42w</a>), Mike Meng&nbsp;&lt;<a href="mailto:myan@solv.finance">myan@solv.finance</a>&gt;, Yi Cai (@YeeTsai)&nbsp;&lt;<a href="mailto:yee.tsai@gmail.com">yee.tsai@gmail.com</a>&gt;, Ryan Chow&nbsp;&lt;<a href="mailto:ryanchow@solv.finance">ryanchow@solv.finance</a>&gt;, Zhongxin Wu&nbsp;(<a href="https://github.com/Nerverwind">@Nerverwind</a>), AlvisDu&nbsp;(<a href="https://github.com/AlvisDu">@AlvisDu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3529">3529</a></td> <td class="title">Reduction in refunds</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Martin Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3541">3541</a></td> <td class="title">Reject new contract code starting with the 0xEF byte</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>), Christian Reitwiessner&nbsp;(<a href="https://github.com/chriseth">@chriseth</a>), Martin Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3554">3554</a></td> <td class="title">Difficulty Bomb Delay to December 2021</td> <td class="author">James Hancock&nbsp;(<a href="https://github.com/madeoftin">@madeoftin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3607">3607</a></td> <td class="title">Reject transactions from senders with deployed code</td> <td class="author">Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Dmitry Khovratovich&nbsp;(<a href="https://github.com/khovratovich">@khovratovich</a>), Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3643">3643</a></td> <td class="title">T-REX - Token for Regulated EXchanges</td> <td class="author">Joachim Lebrun&nbsp;(<a href="https://github.com/Joachim-Lebrun">@Joachim-Lebrun</a>), Tony Malghem&nbsp;(<a href="https://github.com/TonyMalghem">@TonyMalghem</a>), Kevin Thizy&nbsp;(<a href="https://github.com/Nakasar">@Nakasar</a>), Luc Falempin&nbsp;(<a href="https://github.com/lfalempin">@lfalempin</a>), Adam Boudjemaa&nbsp;(<a href="https://github.com/Aboudjem">@Aboudjem</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3651">3651</a></td> <td class="title">Warm COINBASE</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3668">3668</a></td> <td class="title">CCIP Read—Secure offchain data retrieval</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3675">3675</a></td> <td class="title">Upgrade consensus to Proof-of-Stake</td> <td class="author">Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3855">3855</a></td> <td class="title">PUSH0 instruction</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Hugo De la cruz&nbsp;(<a href="https://github.com/hugo-dc">@hugo-dc</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3860">3860</a></td> <td class="title">Limit and meter initcode</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4345">4345</a></td> <td class="title">Difficulty Bomb Delay to June 2022</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>), James Hancock&nbsp;(<a href="https://github.com/MadeOfTin">@MadeOfTin</a>), Thomas Jay Rush&nbsp;(<a href="https://github.com/tjayrush">@tjayrush</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4361">4361</a></td> <td class="title">Sign-In with Ethereum</td> <td class="author">Wayne Chang&nbsp;(<a href="https://github.com/wyc">@wyc</a>), Gregory Rocco&nbsp;(<a href="https://github.com/obstropolos">@obstropolos</a>), Brantly Millegan&nbsp;(<a href="https://github.com/brantlymillegan">@brantlymillegan</a>), Nick Johnson&nbsp;(<a href="https://github.com/Arachnid">@Arachnid</a>), Oliver Terbu&nbsp;(<a href="https://github.com/awoie">@awoie</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4399">4399</a></td> <td class="title">Supplant DIFFICULTY opcode with PREVRANDAO</td> <td class="author">Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4400">4400</a></td> <td class="title">EIP-721 Consumable Extension</td> <td class="author">Daniel Ivanov&nbsp;(<a href="https://github.com/Daniel-K-Ivanov">@Daniel-K-Ivanov</a>), George Spasov&nbsp;(<a href="https://github.com/Perseverance">@Perseverance</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4519">4519</a></td> <td class="title">Non-Fungible Tokens Tied to Physical Assets</td> <td class="author">Javier Arcenegui&nbsp;(<a href="https://github.com/Hardblock-IMSE-CNM">@Hardblock-IMSE-CNM</a>), Rosario Arjona&nbsp;(<a href="https://github.com/RosarioArjona">@RosarioArjona</a>), Roberto Román&nbsp;&lt;<a href="mailto:roman@imse-cnm.csic.es">roman@imse-cnm.csic.es</a>&gt;, Iluminada Baturone&nbsp;(<a href="https://github.com/lumi2018">@lumi2018</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4626">4626</a></td> <td class="title">Tokenized Vaults</td> <td class="author">Joey Santoro&nbsp;(<a href="https://github.com/joeysantoro">@joeysantoro</a>), t11s&nbsp;(<a href="https://github.com/transmissions11">@transmissions11</a>), Jet Jadeja&nbsp;(<a href="https://github.com/JetJadeja">@JetJadeja</a>), Alberto Cuesta Cañada&nbsp;(<a href="https://github.com/alcueca">@alcueca</a>), Señor Doggo&nbsp;(<a href="https://github.com/fubuloubu">@fubuloubu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4736">4736</a></td> <td class="title">Consensus Layer Withdrawal Protection</td> <td class="author">Benjamin Chodroff&nbsp;(<a href="https://github.com/benjaminchodroff">@benjaminchodroff</a>), Jim McDonald&nbsp;(<a href="https://github.com/mcdee">@mcdee</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4788">4788</a></td> <td class="title">Beacon block root in the EVM</td> <td class="author">Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4804">4804</a></td> <td class="title">Web3 URL to EVM Call Message Translation</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Chao Pi&nbsp;(<a href="https://github.com/pichaoqkc">@pichaoqkc</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4834">4834</a></td> <td class="title">Hierarchical Domains</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4844">4844</a></td> <td class="title">Shard Blob Transactions</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Diederik Loerakker&nbsp;(<a href="https://github.com/protolambda">@protolambda</a>), George Kadianakis&nbsp;(<a href="https://github.com/asn-d6">@asn-d6</a>), Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Mofi Taiwo&nbsp;(<a href="https://github.com/Inphi">@Inphi</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4881">4881</a></td> <td class="title">Deposit Contract Snapshot Interface</td> <td class="author">Mark Mackey&nbsp;(<a href="https://github.com/ethDreamer">@ethDreamer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4895">4895</a></td> <td class="title">Beacon chain push withdrawals as operations</td> <td class="author">Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4906">4906</a></td> <td class="title">EIP-721 Metadata Update Extension</td> <td class="author">Anders&nbsp;(<a href="https://github.com/0xanders">@0xanders</a>), Lance&nbsp;(<a href="https://github.com/LanceSnow">@LanceSnow</a>), Shrug&nbsp;&lt;<a href="mailto:shrug@emojidao.org">shrug@emojidao.org</a>&gt;, Nathan&nbsp;&lt;<a href="mailto:nathan.gang@gemini.com">nathan.gang@gemini.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4907">4907</a></td> <td class="title">Rental NFT, an Extension of EIP-721</td> <td class="author">Anders&nbsp;(<a href="https://github.com/0xanders">@0xanders</a>), Lance&nbsp;(<a href="https://github.com/LanceSnow">@LanceSnow</a>), Shrug&nbsp;&lt;<a href="mailto:shrug@emojidao.org">shrug@emojidao.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4910">4910</a></td> <td class="title">Royalty Bearing NFTs</td> <td class="author">Andreas Freund&nbsp;(<a href="https://github.com/Therecanbeonlyone1969">@Therecanbeonlyone1969</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4938">4938</a></td> <td class="title">eth/67 - Removal of GetNodeData</td> <td class="author">Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>), Felix Lange&nbsp;&lt;<a href="mailto:fjl@ethereum.org">fjl@ethereum.org</a>&gt;, Gary Rong&nbsp;&lt;<a href="mailto:garyrong@ethereum.org">garyrong@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4955">4955</a></td> <td class="title">Vendor Metadata Extension for NFTs</td> <td class="author">Ignacio Mazzara&nbsp;(<a href="https://github.com/nachomazzara">@nachomazzara</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5006">5006</a></td> <td class="title">Rental NFT, NFT User Extension</td> <td class="author">Lance&nbsp;(<a href="https://github.com/LanceSnow">@LanceSnow</a>), Anders&nbsp;(<a href="https://github.com/0xanders">@0xanders</a>), Shrug&nbsp;&lt;<a href="mailto:shrug@emojidao.org">shrug@emojidao.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5007">5007</a></td> <td class="title">Time NFT, ERC-721 Time Extension</td> <td class="author">Anders&nbsp;(<a href="https://github.com/0xanders">@0xanders</a>), Lance&nbsp;(<a href="https://github.com/LanceSnow">@LanceSnow</a>), Shrug&nbsp;&lt;<a href="mailto:shrug@emojidao.org">shrug@emojidao.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5023">5023</a></td> <td class="title">Shareable Non-Fungible Token</td> <td class="author">Jarno Marttila&nbsp;(<a href="https://github.com/yaruno">@yaruno</a>), Martin Moravek&nbsp;(<a href="https://github.com/mmartinmo">@mmartinmo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5133">5133</a></td> <td class="title">Delaying Difficulty Bomb to mid-September 2022</td> <td class="author">Tomasz Kajetan Stanczak&nbsp;(<a href="https://github.com/tkstanczak">@tkstanczak</a>), Eric Marti Haynes&nbsp;(<a href="https://github.com/ericmartihaynes">@ericmartihaynes</a>), Josh Klopfenstein&nbsp;(<a href="https://github.com/joshklop">@joshklop</a>), Abhimanyu Nag&nbsp;(<a href="https://github.com/AbhiMan1601">@AbhiMan1601</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5169">5169</a></td> <td class="title">Client Script URI for Token Contracts</td> <td class="author">James&nbsp;(<a href="https://github.com/JamesSmartCell">@JamesSmartCell</a>), Weiwu&nbsp;(<a href="https://github.com/weiwu-zhang">@weiwu-zhang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5192">5192</a></td> <td class="title">Minimal Soulbound NFTs</td> <td class="author">Tim Daubenschütz&nbsp;(<a href="https://github.com/TimDaub">@TimDaub</a>), Anders&nbsp;(<a href="https://github.com/0xanders">@0xanders</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5202">5202</a></td> <td class="title">Blueprint contract format</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), Edward Amor&nbsp;(<a href="https://github.com/skellet0r">@skellet0r</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5219">5219</a></td> <td class="title">Contract Resource Requests</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5267">5267</a></td> <td class="title">Retrieval of EIP-712 domain</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5313">5313</a></td> <td class="title">Light Contract Ownership</td> <td class="author">William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5375">5375</a></td> <td class="title">NFT Author Information and Consent</td> <td class="author">Samuele Marro&nbsp;(<a href="https://github.com/samuelemarro">@samuelemarro</a>), Luca Donno&nbsp;(<a href="https://github.com/lucadonnoh">@lucadonnoh</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5380">5380</a></td> <td class="title">ERC-721 Entitlement Extension</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>), Tim Daubenschütz&nbsp;(<a href="https://github.com/TimDaub">@TimDaub</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5484">5484</a></td> <td class="title">Consensual Soulbound Tokens</td> <td class="author">Buzz Cai&nbsp;(<a href="https://github.com/buzzcai">@buzzcai</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5489">5489</a></td> <td class="title">NFT Hyperlink Extension</td> <td class="author">IronMan_CH&nbsp;(<a href="https://github.com/coderfengyun">@coderfengyun</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5507">5507</a></td> <td class="title">Refundable Tokens</td> <td class="author">elie222&nbsp;(<a href="https://github.com/elie222">@elie222</a>), Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5521">5521</a></td> <td class="title">Referable NFT</td> <td class="author">Saber Yu&nbsp;(<a href="https://github.com/OniReimu">@OniReimu</a>), Qin Wang&nbsp;&lt;<a href="mailto:qin.wang@data61.csiro.au">qin.wang@data61.csiro.au</a>&gt;, Shange Fu&nbsp;&lt;<a href="mailto:shange.fu@monash.edu">shange.fu@monash.edu</a>&gt;, Yilin Sai&nbsp;&lt;<a href="mailto:yilin.sai@data61.csiro.au">yilin.sai@data61.csiro.au</a>&gt;, Shiping Chen&nbsp;&lt;<a href="mailto:shiping.chen@data61.csiro.au">shiping.chen@data61.csiro.au</a>&gt;, Sherry Xu&nbsp;&lt;<a href="mailto:xiwei.xu@data61.csiro.au">xiwei.xu@data61.csiro.au</a>&gt;, Jiangshan Yu&nbsp;&lt;<a href="mailto:jiangshan.yu@monash.edu">jiangshan.yu@monash.edu</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5528">5528</a></td> <td class="title">Refundable Fungible Token</td> <td class="author">StartfundInc&nbsp;(<a href="https://github.com/StartfundInc">@StartfundInc</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5564">5564</a></td> <td class="title">Stealth Addresses</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Matt Solomon&nbsp;(<a href="https://github.com/mds1">@mds1</a>), Ben DiFrancesco&nbsp;(<a href="https://github.com/apbendi">@apbendi</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5570">5570</a></td> <td class="title">Digital Receipt Non-Fungible Tokens</td> <td class="author">Sean Darcy&nbsp;(<a href="https://github.com/darcys22">@darcys22</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5585">5585</a></td> <td class="title">ERC-721 NFT Authorization</td> <td class="author">Veega Labs&nbsp;(<a href="https://github.com/VeegaLabsOfficial">@VeegaLabsOfficial</a>), Sean NG&nbsp;(<a href="https://github.com/ngveega">@ngveega</a>), Tiger&nbsp;(<a href="https://github.com/tiger0x">@tiger0x</a>), Fred&nbsp;(<a href="https://github.com/apan826">@apan826</a>), Fov Cao&nbsp;(<a href="https://github.com/fovcao">@fovcao</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5606">5606</a></td> <td class="title">Multiverse NFTs</td> <td class="author">Gaurang Torvekar&nbsp;(<a href="https://github.com/gaurangtorvekar">@gaurangtorvekar</a>), Khemraj Adhawade&nbsp;(<a href="https://github.com/akhemraj">@akhemraj</a>), Nikhil Asrani&nbsp;(<a href="https://github.com/nikhilasrani">@nikhilasrani</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5615">5615</a></td> <td class="title">ERC-1155 Supply Extension</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5625">5625</a></td> <td class="title">NFT Metadata JSON Schema dStorage Extension</td> <td class="author">Gavin Fu&nbsp;(<a href="https://github.com/gavfu">@gavfu</a>), Leo Wang&nbsp;(<a href="https://github.com/wanglie1986">@wanglie1986</a>), Bova Chen&nbsp;(<a href="https://github.com/appoipp">@appoipp</a>), Guang Han&nbsp;(<a href="https://github.com/pangwa">@pangwa</a>), Brian Wu&nbsp;(<a href="https://github.com/wuhaixian1984">@wuhaixian1984</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5646">5646</a></td> <td class="title">Token State Fingerprint</td> <td class="author">Naim Ashhab&nbsp;(<a href="https://github.com/ashhanai">@ashhanai</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5656">5656</a></td> <td class="title">MCOPY - Memory copying instruction</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paul Dworzanski&nbsp;(<a href="https://github.com/poemm">@poemm</a>), Jared Wasinger&nbsp;(<a href="https://github.com/jwasinger">@jwasinger</a>), Casey Detrio&nbsp;(<a href="https://github.com/cdetrio">@cdetrio</a>), Pawel Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5679">5679</a></td> <td class="title">Token Minting and Burning</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5725">5725</a></td> <td class="title">Transferable Vesting NFT</td> <td class="author">Apeguru&nbsp;(<a href="https://github.com/Apegurus">@Apegurus</a>), Marco De Vries&nbsp;&lt;<a href="mailto:marco@paladinsec.co">marco@paladinsec.co</a>&gt;, Mario&nbsp;&lt;<a href="mailto:mario@paladinsec.co">mario@paladinsec.co</a>&gt;, DeFiFoFum&nbsp;(<a href="https://github.com/DeFiFoFum">@DeFiFoFum</a>), Elliott Green&nbsp;(<a href="https://github.com/elliott-green">@elliott-green</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5732">5732</a></td> <td class="title">Commit Interface</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>), Matt Stam&nbsp;(<a href="https://github.com/mattstam">@mattstam</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5749">5749</a></td> <td class="title">The &apos;window.evmproviders&apos; object</td> <td class="author">Kosala Hemachandra&nbsp;(<a href="https://github.com/kvhnuke">@kvhnuke</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5750">5750</a></td> <td class="title">General Extensibility for Method Behaviors</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5757">5757</a></td> <td class="title">Process for Approving External Resources</td> <td class="author">Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5773">5773</a></td> <td class="title">Context-Dependent Multi-Asset Tokens</td> <td class="author">Bruno Škvorc&nbsp;(<a href="https://github.com/Swader">@Swader</a>), Cicada&nbsp;(<a href="https://github.com/CicadaNCR">@CicadaNCR</a>), Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Stevan Bogosavljevic&nbsp;(<a href="https://github.com/stevyhacker">@stevyhacker</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5792">5792</a></td> <td class="title">Wallet Call API</td> <td class="author">Moody Salem&nbsp;(<a href="https://github.com/moodysalem">@moodysalem</a>), Lukas Rosario&nbsp;(<a href="https://github.com/lukasrosario">@lukasrosario</a>), Wilson Cusack&nbsp;(<a href="https://github.com/wilsoncusack">@wilsoncusack</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Jake Moxey&nbsp;(<a href="https://github.com/jxom">@jxom</a>), Derek Rein&nbsp;(<a href="https://github.com/arein">@arein</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Sam Wilson (@SamWilsn)&nbsp;&lt;<a href="mailto:sam@binarycake.ca">sam@binarycake.ca</a>&gt;, Borislav Itskov&nbsp;(<a href="https://github.com/Oxbobby">@Oxbobby</a>), Joao Tavares&nbsp;(<a href="https://github.com/cryptotavares">@cryptotavares</a>), Adam Fuller&nbsp;(<a href="https://github.com/azf20">@azf20</a>), Philip Liao&nbsp;(<a href="https://github.com/phil-ociraptor">@phil-ociraptor</a>), bumblefudge&nbsp;(<a href="https://github.com/bumblefudge">@bumblefudge</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5793">5793</a></td> <td class="title">eth/68 - Add tx type to tx announcement</td> <td class="author">Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6049">6049</a></td> <td class="title">Deprecate SELFDESTRUCT</td> <td class="author">William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6059">6059</a></td> <td class="title">Parent-Governed Nestable Non-Fungible Tokens</td> <td class="author">Bruno Škvorc&nbsp;(<a href="https://github.com/Swader">@Swader</a>), Cicada&nbsp;(<a href="https://github.com/CicadaNCR">@CicadaNCR</a>), Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Stevan Bogosavljevic&nbsp;(<a href="https://github.com/stevyhacker">@stevyhacker</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6066">6066</a></td> <td class="title">Signature Validation Method for NFTs</td> <td class="author">Jack Boyuan Xu&nbsp;(<a href="https://github.com/boyuanx">@boyuanx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6093">6093</a></td> <td class="title">Custom errors for commonly-used tokens</td> <td class="author">Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>), Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6105">6105</a></td> <td class="title">No Intermediary NFT Trading Protocol</td> <td class="author">5660-eth&nbsp;(<a href="https://github.com/5660-eth">@5660-eth</a>), Silvere Heraudeau&nbsp;(<a href="https://github.com/lambdalf-dev">@lambdalf-dev</a>), Martin McConnell&nbsp;(<a href="https://github.com/offgridgecko">@offgridgecko</a>), Abu&nbsp;&lt;<a href="mailto:team10kuni@gmail.com">team10kuni@gmail.com</a>&gt;, Wizard Wang</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6110">6110</a></td> <td class="title">Supply validator deposits on chain</td> <td class="author">Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Peter Davies&nbsp;(<a href="https://github.com/petertdavies">@petertdavies</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6122">6122</a></td> <td class="title">Forkid checks based on timestamps</td> <td class="author">Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6147">6147</a></td> <td class="title">Guard of NFT/SBT, an Extension of ERC-721</td> <td class="author">5660-eth&nbsp;(<a href="https://github.com/5660-eth">@5660-eth</a>), Wizard Wang</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6150">6150</a></td> <td class="title">Hierarchical NFTs</td> <td class="author">Keegan Lee&nbsp;(<a href="https://github.com/keeganlee">@keeganlee</a>), msfew&nbsp;&lt;<a href="mailto:msfew@hyperoracle.io">msfew@hyperoracle.io</a>&gt;, Kartin&nbsp;&lt;<a href="mailto:kartin@hyperoracle.io">kartin@hyperoracle.io</a>&gt;, qizhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6220">6220</a></td> <td class="title">Composable NFTs utilizing Equippable Parts</td> <td class="author">Bruno Škvorc&nbsp;(<a href="https://github.com/Swader">@Swader</a>), Cicada&nbsp;(<a href="https://github.com/CicadaNCR">@CicadaNCR</a>), Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Stevan Bogosavljevic&nbsp;(<a href="https://github.com/stevyhacker">@stevyhacker</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6239">6239</a></td> <td class="title">Semantic Soulbound Tokens</td> <td class="author">Jessica Chang&nbsp;(<a href="https://github.com/JessicaChg">@JessicaChg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6381">6381</a></td> <td class="title">Public Non-Fungible Token Emote Repository</td> <td class="author">Bruno Škvorc&nbsp;(<a href="https://github.com/Swader">@Swader</a>), Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Stevan Bogosavljevic&nbsp;(<a href="https://github.com/stevyhacker">@stevyhacker</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6454">6454</a></td> <td class="title">Minimal Transferable NFT detection interface</td> <td class="author">Bruno Škvorc&nbsp;(<a href="https://github.com/Swader">@Swader</a>), Francesco Sullo&nbsp;(<a href="https://github.com/sullof">@sullof</a>), Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Stevan Bogosavljevic&nbsp;(<a href="https://github.com/stevyhacker">@stevyhacker</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6492">6492</a></td> <td class="title">Signature Validation for Predeploy Contracts</td> <td class="author">Ivo Georgiev&nbsp;(<a href="https://github.com/Ivshti">@Ivshti</a>), Agustin Aguilar&nbsp;(<a href="https://github.com/Agusx1211">@Agusx1211</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6538">6538</a></td> <td class="title">Stealth Meta-Address Registry</td> <td class="author">Matt Solomon&nbsp;(<a href="https://github.com/mds1">@mds1</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Ben DiFrancesco&nbsp;(<a href="https://github.com/apbendi">@apbendi</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Gary Ghayrat&nbsp;(<a href="https://github.com/garyghayrat">@garyghayrat</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6672">6672</a></td> <td class="title">Multi-redeemable NFTs</td> <td class="author">RE:DREAMER Lab&nbsp;&lt;<a href="mailto:dev@redreamer.io">dev@redreamer.io</a>&gt;, Archie Chang (@ArchieR7)&nbsp;&lt;<a href="mailto:archie@redreamer.io">archie@redreamer.io</a>&gt;, Kai Yu (@chihkaiyu)&nbsp;&lt;<a href="mailto:kai@redreamer.io">kai@redreamer.io</a>&gt;, Yonathan Randyanto (@Randyanto)&nbsp;&lt;<a href="mailto:randy@redreamer.io">randy@redreamer.io</a>&gt;, Boyu Chu (@chuboyu)&nbsp;&lt;<a href="mailto:boyu@redreamer.io">boyu@redreamer.io</a>&gt;, Boxi Li (@boxi79)&nbsp;&lt;<a href="mailto:boxi@redreamer.io">boxi@redreamer.io</a>&gt;, Jason Cheng (@JasonCheng0729)&nbsp;&lt;<a href="mailto:jason@redreamer.io">jason@redreamer.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6780">6780</a></td> <td class="title">SELFDESTRUCT only in same transaction</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6808">6808</a></td> <td class="title">Fungible Key Bound Token</td> <td class="author">Mihai Onila&nbsp;(<a href="https://github.com/MihaiORO">@MihaiORO</a>), Nick Zeman&nbsp;(<a href="https://github.com/NickZCZ">@NickZCZ</a>), Narcis Cotaie&nbsp;(<a href="https://github.com/NarcisCRO">@NarcisCRO</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6809">6809</a></td> <td class="title">Non-Fungible Key Bound Token</td> <td class="author">Mihai Onila&nbsp;(<a href="https://github.com/MihaiORO">@MihaiORO</a>), Nick Zeman&nbsp;(<a href="https://github.com/NickZCZ">@NickZCZ</a>), Narcis Cotaie&nbsp;(<a href="https://github.com/NarcisCRO">@NarcisCRO</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6909">6909</a></td> <td class="title">Minimal Multi-Token Interface</td> <td class="author">JT Riley&nbsp;(<a href="https://github.com/jtriley2p">@jtriley2p</a>), Dillon&nbsp;(<a href="https://github.com/d1ll0n">@d1ll0n</a>), Sara&nbsp;(<a href="https://github.com/snreynolds">@snreynolds</a>), Vectorized&nbsp;(<a href="https://github.com/Vectorized">@Vectorized</a>), Neodaoist&nbsp;(<a href="https://github.com/neodaoist">@neodaoist</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6916">6916</a></td> <td class="title">Automatically Reset Testnet</td> <td class="author">Mário Havel&nbsp;(<a href="https://github.com/taxmeifyoucan">@taxmeifyoucan</a>), pk910&nbsp;(<a href="https://github.com/pk910">@pk910</a>), Rémy Roy&nbsp;(<a href="https://github.com/remyroy">@remyroy</a>), Holly Atkinson&nbsp;(<a href="https://github.com/atkinsonholly">@atkinsonholly</a>), Tereza Burianova&nbsp;(<a href="https://github.com/T-ess">@T-ess</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6953">6953</a></td> <td class="title">Network Upgrade Activation Triggers</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6963">6963</a></td> <td class="title">Multi Injected Provider Discovery</td> <td class="author">Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>), Kosala Hemachandra&nbsp;(<a href="https://github.com/kvhnuke">@kvhnuke</a>), Richard Moore&nbsp;(<a href="https://github.com/ricmoo">@ricmoo</a>), Gregory Markou&nbsp;(<a href="https://github.com/GregTheGreek">@GregTheGreek</a>), Kyle Den Hartog&nbsp;(<a href="https://github.com/kdenhartog">@kdenhartog</a>), Glitch&nbsp;(<a href="https://github.com/glitch-txs">@glitch-txs</a>), Jake Moxey&nbsp;(<a href="https://github.com/jxom">@jxom</a>), Pierre Bertet&nbsp;(<a href="https://github.com/bpierre">@bpierre</a>), Darryl Yeo&nbsp;(<a href="https://github.com/darrylyeo">@darrylyeo</a>), Yaroslav Sergievsky&nbsp;(<a href="https://github.com/everdimension">@everdimension</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6982">6982</a></td> <td class="title">Efficient Default Lockable Tokens</td> <td class="author">Francesco Sullo&nbsp;(<a href="https://github.com/sullof">@sullof</a>), Alexe Spataru&nbsp;(<a href="https://github.com/urataps">@urataps</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7002">7002</a></td> <td class="title">Execution layer triggerable withdrawals</td> <td class="author">Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Hsiao-Wei Wang&nbsp;(<a href="https://github.com/hwwhww">@hwwhww</a>), lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Felix Lange&nbsp;(<a href="https://github.com/fjl">@fjl</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7007">7007</a></td> <td class="title">Verifiable AI-Generated Content Token</td> <td class="author">Cathie So&nbsp;(<a href="https://github.com/socathie">@socathie</a>), Xiaohang Yu&nbsp;(<a href="https://github.com/xhyumiracle">@xhyumiracle</a>), Conway&nbsp;(<a href="https://github.com/0x1cc">@0x1cc</a>), Lee Ting Ting&nbsp;(<a href="https://github.com/tina1998612">@tina1998612</a>), Kartin&nbsp;&lt;<a href="mailto:kartin@hyperoracle.io">kartin@hyperoracle.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7044">7044</a></td> <td class="title">Perpetually Valid Signed Voluntary Exits</td> <td class="author">Lion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7045">7045</a></td> <td class="title">Increase max attestation inclusion slot</td> <td class="author">Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7053">7053</a></td> <td class="title">Interoperable Digital Media Indexing</td> <td class="author">Bofu Chen&nbsp;(<a href="https://github.com/bafu">@bafu</a>), Tammy Yang&nbsp;(<a href="https://github.com/tammyyang">@tammyyang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7066">7066</a></td> <td class="title">Lockable Extension for ERC-721</td> <td class="author">Piyush Chittara&nbsp;(<a href="https://github.com/piyush-chittara">@piyush-chittara</a>), StreamNFT&nbsp;(<a href="https://github.com/streamnft-tech">@streamnft-tech</a>), Srinivas Joshi&nbsp;(<a href="https://github.com/SrinivasJoshi">@SrinivasJoshi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7092">7092</a></td> <td class="title">Financial Bonds</td> <td class="author">Samuel Gwlanold Edoumou&nbsp;(<a href="https://github.com/Edoumou">@Edoumou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7160">7160</a></td> <td class="title">ERC-721 Multi-Metadata Extension</td> <td class="author">0xG&nbsp;(<a href="https://github.com/0xGh">@0xGh</a>), Marco Peyfuss&nbsp;(<a href="https://github.com/mpeyfuss">@mpeyfuss</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7201">7201</a></td> <td class="title">Namespaced Storage Layout</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>), Eric Lau&nbsp;(<a href="https://github.com/ericglau">@ericglau</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7208">7208</a></td> <td class="title">On-Chain Data Containers</td> <td class="author">Rachid Ajaja&nbsp;(<a href="https://github.com/abrajaja">@abrajaja</a>), Matthijs de Vries&nbsp;(<a href="https://github.com/sudomati">@sudomati</a>), Alexandros Athanasopulos&nbsp;(<a href="https://github.com/Xaleee">@Xaleee</a>), Pavel Rubin&nbsp;(<a href="https://github.com/pash7ka">@pash7ka</a>), Sebastian Galimberti Romano&nbsp;(<a href="https://github.com/galimba">@galimba</a>), Daniel Berbesi&nbsp;(<a href="https://github.com/berbex">@berbex</a>), Apostolos Mavropoulos&nbsp;(<a href="https://github.com/ApostolosMavro">@ApostolosMavro</a>), Barbara Marcano&nbsp;(<a href="https://github.com/Barbara-Marcano">@Barbara-Marcano</a>), Daniel Ortega&nbsp;(<a href="https://github.com/xdaniortega">@xdaniortega</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7231">7231</a></td> <td class="title">Identity-aggregated NFT</td> <td class="author">Chloe Gu&nbsp;&lt;<a href="mailto:chloe@carv.io">chloe@carv.io</a>&gt;, Navid X.&nbsp;(<a href="https://github.com/xuxinlai2002">@xuxinlai2002</a>), Victor Yu&nbsp;&lt;<a href="mailto:victor@carv.io">victor@carv.io</a>&gt;, Archer H.</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7251">7251</a></td> <td class="title">Increase the MAX_EFFECTIVE_BALANCE</td> <td class="author">mike&nbsp;(<a href="https://github.com/michaelneuder">@michaelneuder</a>), Francesco&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), dapplion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>), Mikhail&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>), Aditya&nbsp;(<a href="https://github.com/adiasg">@adiasg</a>), Justin&nbsp;(<a href="https://github.com/justindrake">@justindrake</a>), lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Felix Lange&nbsp;(<a href="https://github.com/fjl">@fjl</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7291">7291</a></td> <td class="title">Purpose bound money</td> <td class="author">Orchid-Dev&nbsp;(<a href="https://github.com/proj-orchid-straitsx">@proj-orchid-straitsx</a>), Victor Liew&nbsp;(<a href="https://github.com/alcedo">@alcedo</a>), Wong Tse Jian&nbsp;(<a href="https://github.com/wongtsejian">@wongtsejian</a>), Jacob Shan&nbsp;(<a href="https://github.com/Jacobshan429">@Jacobshan429</a>), Chin Sin Ong&nbsp;(<a href="https://github.com/chinsinong">@chinsinong</a>), Praveen Kumar&nbsp;(<a href="https://github.com/veenkumarr">@veenkumarr</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7329">7329</a></td> <td class="title">ERC/EIP Repository split</td> <td class="author">Lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7401">7401</a></td> <td class="title">Parent-Governed Non-Fungible Tokens Nesting</td> <td class="author">Bruno Škvorc&nbsp;(<a href="https://github.com/Swader">@Swader</a>), Cicada&nbsp;(<a href="https://github.com/CicadaNCR">@CicadaNCR</a>), Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Stevan Bogosavljevic&nbsp;(<a href="https://github.com/stevyhacker">@stevyhacker</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7409">7409</a></td> <td class="title">Public Non-Fungible Tokens Emote Repository</td> <td class="author">Bruno Škvorc&nbsp;(<a href="https://github.com/Swader">@Swader</a>), Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Stevan Bogosavljevic&nbsp;(<a href="https://github.com/stevyhacker">@stevyhacker</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7432">7432</a></td> <td class="title">Non-Fungible Token Roles</td> <td class="author">Ernani São Thiago&nbsp;(<a href="https://github.com/ernanirst">@ernanirst</a>), Daniel Lima&nbsp;(<a href="https://github.com/karacurt">@karacurt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7439">7439</a></td> <td class="title">Prevent ticket touting</td> <td class="author">LeadBest Consulting Group&nbsp;&lt;<a href="mailto:service@getoken.io">service@getoken.io</a>&gt;, Sandy Sung&nbsp;(<a href="https://github.com/sandy-sung-lb">@sandy-sung-lb</a>), Mars Peng&nbsp;&lt;<a href="mailto:mars.peng@getoken.io">mars.peng@getoken.io</a>&gt;, Taien Wang&nbsp;&lt;<a href="mailto:taien.wang@getoken.io">taien.wang@getoken.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7514">7514</a></td> <td class="title">Add Max Epoch Churn Limit</td> <td class="author">dapplion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>), Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7516">7516</a></td> <td class="title">BLOBBASEFEE instruction</td> <td class="author">Carl Beekhuizen&nbsp;(<a href="https://github.com/carlbeek">@carlbeek</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7528">7528</a></td> <td class="title">ETH (Native Asset) Address Convention</td> <td class="author">Joey Santoro&nbsp;(<a href="https://github.com/joeysantoro">@joeysantoro</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7535">7535</a></td> <td class="title">Native Asset ERC-4626 Tokenized Vault</td> <td class="author">Joey Santoro&nbsp;(<a href="https://github.com/joeysantoro">@joeysantoro</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7540">7540</a></td> <td class="title">Asynchronous ERC-4626 Tokenized Vaults</td> <td class="author">Jeroen Offerijns&nbsp;(<a href="https://github.com/hieronx">@hieronx</a>), Alina Sinelnikova&nbsp;(<a href="https://github.com/ilinzweilin">@ilinzweilin</a>), Vikram Arun&nbsp;(<a href="https://github.com/vikramarun">@vikramarun</a>), Joey Santoro&nbsp;(<a href="https://github.com/joeysantoro">@joeysantoro</a>), Farhaan Ali&nbsp;(<a href="https://github.com/0xfarhaan">@0xfarhaan</a>), João Martins&nbsp;(<a href="https://github.com/0xTimepunk">@0xTimepunk</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7549">7549</a></td> <td class="title">Move committee index outside Attestation</td> <td class="author">dapplion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>), Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7568">7568</a></td> <td class="title">Hardfork Meta Backfill - Berlin to Shapella</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7569">7569</a></td> <td class="title">Hardfork Meta - Dencun</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7575">7575</a></td> <td class="title">Multi-Asset ERC-4626 Vaults</td> <td class="author">Jeroen Offerijns&nbsp;(<a href="https://github.com/hieronx">@hieronx</a>), Alina Sinelnikova&nbsp;(<a href="https://github.com/ilinzweilin">@ilinzweilin</a>), Vikram Arun&nbsp;(<a href="https://github.com/vikramarun">@vikramarun</a>), Joey Santoro&nbsp;(<a href="https://github.com/joeysantoro">@joeysantoro</a>), Farhaan Ali&nbsp;(<a href="https://github.com/0xfarhaan">@0xfarhaan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7578">7578</a></td> <td class="title">Physical Asset Redemption</td> <td class="author">Lee Vidor&nbsp;(<a href="https://github.com/V1d0r">@V1d0r</a>), David Tan&nbsp;&lt;<a href="mailto:david@emergentx.org">david@emergentx.org</a>&gt;, Lee Smith&nbsp;&lt;<a href="mailto:lee@emergentx.org">lee@emergentx.org</a>&gt;, Gabriel Stoica&nbsp;(<a href="https://github.com/gabrielstoica">@gabrielstoica</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7587">7587</a></td> <td class="title">Reserve Precompile Address Range for RIPs</td> <td class="author">Carl Beekhuizen&nbsp;(<a href="https://github.com/carlbeek">@carlbeek</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7588">7588</a></td> <td class="title">Blob Transactions Metadata JSON Schema</td> <td class="author">Gavin Fu&nbsp;(<a href="https://github.com/gavfu">@gavfu</a>), Leo Wang&nbsp;(<a href="https://github.com/wanglie1986">@wanglie1986</a>), Bova Chen&nbsp;(<a href="https://github.com/appoipp">@appoipp</a>), Aiden X&nbsp;(<a href="https://github.com/4ever9">@4ever9</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7594">7594</a></td> <td class="title">PeerDAS - Peer Data Availability Sampling</td> <td class="author">Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Hsiao-Wei Wang&nbsp;(<a href="https://github.com/hwwhww">@hwwhww</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7600">7600</a></td> <td class="title">Hardfork Meta - Pectra</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7607">7607</a></td> <td class="title">Hardfork Meta - Fusaka</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7623">7623</a></td> <td class="title">Increase calldata cost</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7627">7627</a></td> <td class="title">Secure Messaging Protocol</td> <td class="author">Chen Liaoyuan (@chenly)&nbsp;&lt;<a href="mailto:cly@kip.pro">cly@kip.pro</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7631">7631</a></td> <td class="title">Dual Nature Token Pair</td> <td class="author">vectorized&nbsp;(<a href="https://github.com/vectorized">@vectorized</a>), Thomas&nbsp;(<a href="https://github.com/0xth0mas">@0xth0mas</a>), Quit&nbsp;(<a href="https://github.com/quitcrypto">@quitcrypto</a>), Michael Amadi&nbsp;(<a href="https://github.com/AmadiMichael">@AmadiMichael</a>), cygaar&nbsp;(<a href="https://github.com/cygaar">@cygaar</a>), Harrison&nbsp;(<a href="https://github.com/pop-punk">@pop-punk</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7634">7634</a></td> <td class="title">Limited Transfer Count NFT</td> <td class="author">Qin Wang&nbsp;(<a href="https://github.com/qinwang-git">@qinwang-git</a>), Saber Yu&nbsp;(<a href="https://github.com/OniReimu">@OniReimu</a>), Shiping Chen&nbsp;&lt;<a href="mailto:shiping.chen@data61.csiro.au">shiping.chen@data61.csiro.au</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7642">7642</a></td> <td class="title">eth/69 - history expiry and simpler receipts</td> <td class="author">Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>), Felix Lange&nbsp;&lt;<a href="mailto:fjl@ethereum.org">fjl@ethereum.org</a>&gt;, Ahmad Bitar (@smartprogrammer93)&nbsp;&lt;<a href="mailto:smartprogrammer@windowslive.com">smartprogrammer@windowslive.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7656">7656</a></td> <td class="title">Generalized Contract-Linked Services</td> <td class="author">Francesco Sullo&nbsp;(<a href="https://github.com/sullof">@sullof</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7685">7685</a></td> <td class="title">General purpose execution layer requests</td> <td class="author">lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Felix Lange&nbsp;(<a href="https://github.com/fjl">@fjl</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7691">7691</a></td> <td class="title">Blob throughput increase</td> <td class="author">Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithosh">@parithosh</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Sam Calder-Mason&nbsp;(<a href="https://github.com/samcm">@samcm</a>), Andrew Davis&nbsp;(<a href="https://github.com/savid">@savid</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7702">7702</a></td> <td class="title">Set Code for EOAs</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7734">7734</a></td> <td class="title">Decentralized Identity Verification (DID)</td> <td class="author">Anushka Yadav (@64anushka)&nbsp;&lt;<a href="mailto:64anushka@gmail.com">64anushka@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7743">7743</a></td> <td class="title">Multi-Owner Non-Fungible Tokens (MO-NFT)</td> <td class="author">Cheng Qian (@jamesavechives)&nbsp;&lt;<a href="mailto:james.walstonn@gmail.com">james.walstonn@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7751">7751</a></td> <td class="title">Wrapping of bubbled up reverts</td> <td class="author">Daniel Gretzke&nbsp;(<a href="https://github.com/gretzke">@gretzke</a>), Sara Reynolds&nbsp;(<a href="https://github.com/snreynolds">@snreynolds</a>), Alice Henshaw&nbsp;(<a href="https://github.com/hensha256">@hensha256</a>), Marko Veniger&nbsp;&lt;<a href="mailto:marko.veniger@tenderly.co">marko.veniger@tenderly.co</a>&gt;, Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7786">7786</a></td> <td class="title">Cross-Chain Messaging Gateway</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>), CJ Cobb&nbsp;(<a href="https://github.com/cjcobb23">@cjcobb23</a>), Sergey Gorbunov&nbsp;(<a href="https://github.com/sergeynog">@sergeynog</a>), joxes&nbsp;(<a href="https://github.com/Joxess">@Joxess</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7818">7818</a></td> <td class="title">Expirable ERC-20</td> <td class="author">sirawt&nbsp;(<a href="https://github.com/MASDXI">@MASDXI</a>), ADISAKBOONMARK&nbsp;(<a href="https://github.com/ADISAKBOONMARK">@ADISAKBOONMARK</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7820">7820</a></td> <td class="title">Access Control Registry</td> <td class="author">Shubham Khandelwal&nbsp;(<a href="https://github.com/shubh-ta">@shubh-ta</a>), Anushka Yadav&nbsp;(<a href="https://github.com/anushka642000">@anushka642000</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7823">7823</a></td> <td class="title">Set upper bounds for MODEXP</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Radoslaw Zagorowicz&nbsp;(<a href="https://github.com/rodiazet">@rodiazet</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7825">7825</a></td> <td class="title">Transaction Gas Limit Cap</td> <td class="author">Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7837">7837</a></td> <td class="title">Diffusive Tokens</td> <td class="author">Cheng Qian (@jamesavechives)&nbsp;&lt;<a href="mailto:james.walstonn@gmail.com">james.walstonn@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7840">7840</a></td> <td class="title">Add blob schedule to EL config files</td> <td class="author">lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7857">7857</a></td> <td class="title">AI Agents NFT with Private Metadata</td> <td class="author">Ming Wu&nbsp;(<a href="https://github.com/sparkmiw">@sparkmiw</a>), Jason Zeng&nbsp;(<a href="https://github.com/zenghbo">@zenghbo</a>), Wei Wu&nbsp;(<a href="https://github.com/Wilbert957">@Wilbert957</a>), Michael Heinrich&nbsp;(<a href="https://github.com/michaelomg">@michaelomg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7858">7858</a></td> <td class="title">Expirable NFTs and SBTs</td> <td class="author">sirawt&nbsp;(<a href="https://github.com/MASDXI">@MASDXI</a>), ADISAKBOONMARK&nbsp;(<a href="https://github.com/ADISAKBOONMARK">@ADISAKBOONMARK</a>), parametprame&nbsp;(<a href="https://github.com/parametprame">@parametprame</a>), Nacharoen&nbsp;(<a href="https://github.com/najaroen">@najaroen</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7878">7878</a></td> <td class="title">Bequeathable Contracts</td> <td class="author">Wamith Mockbill&nbsp;(<a href="https://github.com/wamith">@wamith</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7883">7883</a></td> <td class="title">ModExp Gas Cost Increase</td> <td class="author">Marcin Sobczak&nbsp;(<a href="https://github.com/marcindsobczak">@marcindsobczak</a>), Marek Moraczyński&nbsp;(<a href="https://github.com/MarekM25">@MarekM25</a>), Marcos Maceo&nbsp;(<a href="https://github.com/stdevMac">@stdevMac</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7892">7892</a></td> <td class="title">Blob Parameter Only Hardforks</td> <td class="author">Mark Mackey&nbsp;(<a href="https://github.com/ethDreamer">@ethDreamer</a>), Raúl Kripalani&nbsp;(<a href="https://github.com/raulk">@raulk</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7893">7893</a></td> <td class="title">DeFi Protocol Solvency Proof Mechanism</td> <td class="author">Sean Luis Guada Rodríguez (@SeanLuis)&nbsp;&lt;<a href="mailto:seanluis47@gmail.com">seanluis47@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7908">7908</a></td> <td class="title">HD wallet In Treasury Management</td> <td class="author">Xiaoyu Liu (@elizabethxiaoyu)&nbsp;&lt;<a href="mailto:jiushi.lxy@antgroup.com">jiushi.lxy@antgroup.com</a>&gt;, Yuxiang Fu (@tmac4096)&nbsp;&lt;<a href="mailto:kunfu.fyx@antgroup.com">kunfu.fyx@antgroup.com</a>&gt;, Yanyi Liang&nbsp;&lt;<a href="mailto:eason.lyy@antgroup.com">eason.lyy@antgroup.com</a>&gt;, Hao Zou (@BruceZH0915)&nbsp;&lt;<a href="mailto:situ.zh@antgroup.com">situ.zh@antgroup.com</a>&gt;, Siyuan Zheng (@andrewcoder666)&nbsp;&lt;<a href="mailto:zhengsiyuan.zsy@antgroup.com">zhengsiyuan.zsy@antgroup.com</a>&gt;, yuanshanhshan (@xunayuan)&nbsp;&lt;<a href="mailto:yuanshanshan.yss@antgroup.com">yuanshanshan.yss@antgroup.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7910">7910</a></td> <td class="title">eth_config JSON-RPC Method</td> <td class="author">Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7913">7913</a></td> <td class="title">Signature Verifiers</td> <td class="author">Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>), Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Aryeh Greenberg&nbsp;(<a href="https://github.com/arr00">@arr00</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7917">7917</a></td> <td class="title">Deterministic proposer lookahead</td> <td class="author">Lin Oshitani (@linoscope)&nbsp;&lt;<a href="mailto:lin@nethermind.io">lin@nethermind.io</a>&gt;, Justin Drake (@JustinDrake)&nbsp;&lt;<a href="mailto:justin@ethereum.org">justin@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7918">7918</a></td> <td class="title">Blob base fee bounded by execution cost</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7934">7934</a></td> <td class="title">RLP Execution Block Size Limit</td> <td class="author">Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Storm Slivkoff&nbsp;(<a href="https://github.com/sslivkoff">@sslivkoff</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7935">7935</a></td> <td class="title">Set default gas limit to 60M</td> <td class="author">Sophia Gold&nbsp;(<a href="https://github.com/sophia-gold">@sophia-gold</a>), Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithoshj">@parithoshj</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Carl Beekhuizen&nbsp;(<a href="https://github.com/CarlBeek">@CarlBeek</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Josh Rudolph&nbsp;(<a href="https://github.com/jrudolph">@jrudolph</a>), Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>), Storm Slivkoff&nbsp;(<a href="https://github.com/sslivkoff">@sslivkoff</a>), Kamil Chodoła&nbsp;(<a href="https://github.com/kamilchodola">@kamilchodola</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7939">7939</a></td> <td class="title">Count leading zeros (CLZ) opcode</td> <td class="author">Vectorized&nbsp;(<a href="https://github.com/Vectorized">@Vectorized</a>), Georgios Konstantopoulos&nbsp;(<a href="https://github.com/gakonst">@gakonst</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7943">7943</a></td> <td class="title">uRWA - Universal Real World Asset Interface</td> <td class="author">Dario Lo Buglio&nbsp;(<a href="https://github.com/xaler5">@xaler5</a>), Tino Martinez Molina&nbsp;(<a href="https://github.com/tinom9">@tinom9</a>), Mihai Colceriu&nbsp;(<a href="https://github.com/mihaic195">@mihaic195</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7950">7950</a></td> <td class="title">Encode chain id with transaction hash</td> <td class="author">Lauri Peltonen&nbsp;(<a href="https://github.com/microbecode">@microbecode</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7951">7951</a></td> <td class="title">Precompile for secp256r1 Curve Support</td> <td class="author">Carl Beekhuizen&nbsp;(<a href="https://github.com/carlbeek">@carlbeek</a>), Ulaş Erdoğan&nbsp;(<a href="https://github.com/ulerdogan">@ulerdogan</a>), Doğan Alpaslan&nbsp;(<a href="https://github.com/doganalpaslan">@doganalpaslan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7994">7994</a></td> <td class="title">Purpose-Bound ERC-20 with Conditional Unlock</td> <td class="author">Anushka Yadav&nbsp;(<a href="https://github.com/64anushka">@64anushka</a>), Akash Kothawade&nbsp;(<a href="https://github.com/akash3927">@akash3927</a>), Atishek Singh&nbsp;(<a href="https://github.com/atisheksingh">@atisheksingh</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8001">8001</a></td> <td class="title">Agent Coordination Framework</td> <td class="author">Kwame Bryan&nbsp;(<a href="https://github.com/KBryan">@KBryan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8034">8034</a></td> <td class="title">Referable NFT Royalties</td> <td class="author">Ruiqiang Li (@richard-620)&nbsp;&lt;<a href="mailto:richard.620.research@gmail.com">richard.620.research@gmail.com</a>&gt;, Qin Wang&nbsp;&lt;<a href="mailto:qin.wang@data61.csiro.au">qin.wang@data61.csiro.au</a>&gt;, Shiping Chen&nbsp;&lt;<a href="mailto:shiping.chen@data61.csiro.au">shiping.chen@data61.csiro.au</a>&gt;, Saber Yu&nbsp;(<a href="https://github.com/OniReimu">@OniReimu</a>), Brian Yecies&nbsp;&lt;<a href="mailto:byecies@uow.edu.au">byecies@uow.edu.au</a>&gt;, John Le&nbsp;&lt;<a href="mailto:johnle@uow.edu.au">johnle@uow.edu.au</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8042">8042</a></td> <td class="title">Diamond Storage</td> <td class="author">Nick Mudge&nbsp;(<a href="https://github.com/mudgen">@mudgen</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8063">8063</a></td> <td class="title">Groups - Membership Tokens</td> <td class="author">Cheng Qian (@jamesavechives)&nbsp;&lt;<a href="mailto:contact@deakee.com">contact@deakee.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8134">8134</a></td> <td class="title">Hardfork Meta - BPO1</td> <td class="author">Pooja Ranjan&nbsp;(<a href="https://github.com/poojaranjan">@poojaranjan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8135">8135</a></td> <td class="title">Hardfork Meta - BPO2</td> <td class="author">Pooja Ranjan&nbsp;(<a href="https://github.com/poojaranjan">@poojaranjan</a>)</td> </tr> </table> <h2 id="last-call">Last Call</h2> <table class="eiptable"> <thead> <tr> <th class="eipnum">Number</th><th class="date">Review ends</th><th class="title">Title</th><th class="author">Author</th></tr> </thead> <tr> <td class="eipnum"><a href="/EIPS/eip-1191">1191</a></td> <td class="date">2019-11-18</td> <td class="title">Add chain id to mixed-case checksum address encoding</td> <td class="author">Juliano Rizzo&nbsp;(<a href="https://github.com/juli">@juli</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2266">2266</a></td> <td class="date">2020-12-31</td> <td class="title">Atomic Swap-based American Call Option Contract Standard</td> <td class="author">Runchao Han&nbsp;&lt;<a href="mailto:runchao.han@monash.edu">runchao.han@monash.edu</a>&gt;, Haoyu Lin&nbsp;&lt;<a href="mailto:chris.haoyul@gmail.com">chris.haoyul@gmail.com</a>&gt;, Jiangshan Yu&nbsp;&lt;<a href="mailto:jiangshan.yu@monash.edu">jiangshan.yu@monash.edu</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3076">3076</a></td> <td class="date">2021-11-03</td> <td class="title">Slashing Protection Interchange Format</td> <td class="author">Michael Sproul&nbsp;(<a href="https://github.com/michaelsproul">@michaelsproul</a>), Sacha Saint-Leger&nbsp;(<a href="https://github.com/sachayves">@sachayves</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3155">3155</a></td> <td class="date">2025-03-01</td> <td class="title">EVM trace specification</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5008">5008</a></td> <td class="date">2023-08-15</td> <td class="title">ERC-721 Nonce Extension</td> <td class="author">Anders&nbsp;(<a href="https://github.com/0xanders">@0xanders</a>), Lance&nbsp;(<a href="https://github.com/LanceSnow">@LanceSnow</a>), Shrug&nbsp;&lt;<a href="mailto:shrug@emojidao.org">shrug@emojidao.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5114">5114</a></td> <td class="date">2023-09-19</td> <td class="title">Soulbound Badge</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5164">5164</a></td> <td class="date">2023-11-15</td> <td class="title">Cross-Chain Execution</td> <td class="author">Brendan Asselstine&nbsp;(<a href="https://github.com/asselstine">@asselstine</a>), Pierrick Turelier&nbsp;(<a href="https://github.com/PierrickGT">@PierrickGT</a>), Chris Whinfrey&nbsp;(<a href="https://github.com/cwhinfrey">@cwhinfrey</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5216">5216</a></td> <td class="date">2022-11-12</td> <td class="title">ERC-1155 Allowance Extension</td> <td class="author">Iván Mañús&nbsp;(<a href="https://github.com/ivanmmurciaua">@ivanmmurciaua</a>), Juan Carlos Cantó&nbsp;(<a href="https://github.com/EscuelaCryptoES">@EscuelaCryptoES</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5453">5453</a></td> <td class="date">2023-09-27</td> <td class="title">Endorsement - Permit for Any Functions</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5496">5496</a></td> <td class="date">2022-11-29</td> <td class="title">Multi-privilege Management NFT Extension</td> <td class="author">Jeremy Z&nbsp;(<a href="https://github.com/wnft">@wnft</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6224">6224</a></td> <td class="date">2025-07-31</td> <td class="title">Contracts Dependencies Registry</td> <td class="author">Artem Chystiakov&nbsp;(<a href="https://github.com/arvolear">@arvolear</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6357">6357</a></td> <td class="date">2023-11-10</td> <td class="title">Single-contract Multi-delegatecall</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7523">7523</a></td> <td class="date">2024-03-26</td> <td class="title">Empty accounts deprecation</td> <td class="author">Peter Davies&nbsp;(<a href="https://github.com/petertdavies">@petertdavies</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7610">7610</a></td> <td class="date">2024-11-20</td> <td class="title">Revert creation in case of non-empty storage</td> <td class="author">Gary Rong&nbsp;(<a href="https://github.com/rjl493456442">@rjl493456442</a>), Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7723">7723</a></td> <td class="date">2025-04-01</td> <td class="title">Network Upgrade Inclusion Stages</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Nixo&nbsp;(<a href="https://github.com/nixorokish">@nixorokish</a>), Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithosh">@parithosh</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7744">7744</a></td> <td class="date">2025-07-29</td> <td class="title">Code Index</td> <td class="author">Tim Pechersky (@peersky)&nbsp;&lt;<a href="mailto:t@peersky.xyz">t@peersky.xyz</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7746">7746</a></td> <td class="date">2025-07-29</td> <td class="title">Composable Security Middleware Hooks</td> <td class="author">Tim Pechersky&nbsp;(<a href="https://github.com/peersky">@peersky</a>)</td> </tr> </table> <h2 id="review">Review</h2> <table class="eiptable"> <thead> <tr><th class="eipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr> </thead> <tr> <td class="eipnum"><a href="/EIPS/eip-1185">1185</a></td> <td class="title">Storage of DNS Records in ENS</td> <td class="author">Jim McDonald&nbsp;(<a href="https://github.com/mcdee">@mcdee</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1202">1202</a></td> <td class="title">Voting Interface</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>), ERC-1202 Working Group&nbsp;&lt;<a href="mailto:erc1202@googlegroups.com">erc1202@googlegroups.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2333">2333</a></td> <td class="title">BLS12-381 Key Generation</td> <td class="author">Carl Beekhuizen (@CarlBeek)&nbsp;&lt;<a href="mailto:carl@ethereum.org">carl@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2334">2334</a></td> <td class="title">BLS12-381 Deterministic Account Hierarchy</td> <td class="author">Carl Beekhuizen (@CarlBeek)&nbsp;&lt;<a href="mailto:carl@ethereum.org">carl@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2335">2335</a></td> <td class="title">BLS12-381 Keystore</td> <td class="author">Carl Beekhuizen (@CarlBeek)&nbsp;&lt;<a href="mailto:carl@ethereum.org">carl@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4337">4337</a></td> <td class="title">Account Abstraction Using Alt Mempool</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Kristof Gazso&nbsp;(<a href="https://github.com/kristofgazso">@kristofgazso</a>), Tjaden Hess&nbsp;(<a href="https://github.com/tjade273">@tjade273</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4824">4824</a></td> <td class="title">Common Interfaces for DAOs</td> <td class="author">Joshua Tan&nbsp;(<a href="https://github.com/thelastjosh">@thelastjosh</a>), Isaac Patka&nbsp;(<a href="https://github.com/ipatka">@ipatka</a>), Ido Gershtein&nbsp;&lt;<a href="mailto:ido@daostack.io">ido@daostack.io</a>&gt;, Eyal Eithcowich&nbsp;&lt;<a href="mailto:eyal@deepdao.io">eyal@deepdao.io</a>&gt;, Michael Zargham&nbsp;(<a href="https://github.com/mzargham">@mzargham</a>), Sam Furter&nbsp;(<a href="https://github.com/nivida">@nivida</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4973">4973</a></td> <td class="title">Account-bound Tokens</td> <td class="author">Tim Daubenschütz&nbsp;(<a href="https://github.com/TimDaub">@TimDaub</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5247">5247</a></td> <td class="title">Smart Contract Executable Proposal Interface</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5269">5269</a></td> <td class="title">ERC Detection and Discovery</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5289">5289</a></td> <td class="title">Ethereum Notary Interface</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5485">5485</a></td> <td class="title">Jurisdiction, Accreditation, and Enforcement</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5568">5568</a></td> <td class="title">Well-Known Format for Required Actions</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5639">5639</a></td> <td class="title">Delegation Registry</td> <td class="author">foobar&nbsp;(<a href="https://github.com/0xfoobar">@0xfoobar</a>), Wilkins Chung (@wwhchung)&nbsp;&lt;<a href="mailto:wilkins@manifold.xyz">wilkins@manifold.xyz</a>&gt;, ryley-o&nbsp;(<a href="https://github.com/ryley-o">@ryley-o</a>), Jake Rockland&nbsp;(<a href="https://github.com/jakerockland">@jakerockland</a>), andy8052&nbsp;(<a href="https://github.com/andy8052">@andy8052</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5982">5982</a></td> <td class="title">Role-based Access Control</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6065">6065</a></td> <td class="title">Real Estate Token</td> <td class="author">Alex&nbsp;(<a href="https://github.com/Alex-Klasma">@Alex-Klasma</a>), Ben Fusek&nbsp;(<a href="https://github.com/bfusek">@bfusek</a>), Daniel Fallon-Cyr&nbsp;(<a href="https://github.com/dfalloncyr">@dfalloncyr</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6120">6120</a></td> <td class="title">Universal Token Router</td> <td class="author">Derion&nbsp;(<a href="https://github.com/derion-io">@derion-io</a>), Zergity&nbsp;(<a href="https://github.com/Zergity">@Zergity</a>), Ngo Quang Anh&nbsp;(<a href="https://github.com/anhnq82">@anhnq82</a>), BerlinP&nbsp;(<a href="https://github.com/BerlinP">@BerlinP</a>), Khanh Pham&nbsp;(<a href="https://github.com/blackskin18">@blackskin18</a>), Hal Blackburn&nbsp;(<a href="https://github.com/h4l">@h4l</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6315">6315</a></td> <td class="title">ERC-2771 Namespaced Account Abstraction</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6358">6358</a></td> <td class="title">Cross-Chain Token States Synchronization</td> <td class="author">Shawn Zheng&nbsp;(<a href="https://github.com/xiyu1984">@xiyu1984</a>), Jason Cheng&nbsp;&lt;<a href="mailto:chengjingxx@gmail.com">chengjingxx@gmail.com</a>&gt;, George Huang&nbsp;(<a href="https://github.com/virgil2019">@virgil2019</a>), Kay Lin&nbsp;(<a href="https://github.com/kay404">@kay404</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6366">6366</a></td> <td class="title">Permission Token</td> <td class="author">Chiro&nbsp;(<a href="https://github.com/chiro-hiro">@chiro-hiro</a>), Victor Dusart&nbsp;(<a href="https://github.com/vdusart">@vdusart</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6372">6372</a></td> <td class="title">Contract clock</td> <td class="author">Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6551">6551</a></td> <td class="title">Non-fungible Token Bound Accounts</td> <td class="author">Jayden Windle&nbsp;(<a href="https://github.com/jaydenwindle">@jaydenwindle</a>), Benny Giang&nbsp;&lt;<a href="mailto:bg@futureprimitive.xyz">bg@futureprimitive.xyz</a>&gt;, Steve Jang, Druzy Downs&nbsp;(<a href="https://github.com/druzydowns">@druzydowns</a>), Raymond Huynh&nbsp;(<a href="https://github.com/huynhr">@huynhr</a>), Alanah Lam&nbsp;&lt;<a href="mailto:alanah@futureprimitive.xyz">alanah@futureprimitive.xyz</a>&gt;, Wilkins Chung (@wwhchung)&nbsp;&lt;<a href="mailto:wilkins@manifold.xyz">wilkins@manifold.xyz</a>&gt;, Paul Sullivan (@sullivph)&nbsp;&lt;<a href="mailto:paul.sullivan@manifold.xyz">paul.sullivan@manifold.xyz</a>&gt;, Auryn Macmillan&nbsp;(<a href="https://github.com/auryn-macmillan">@auryn-macmillan</a>), Jan-Felix Schwarz&nbsp;(<a href="https://github.com/jfschwarz">@jfschwarz</a>), Anton Bukov&nbsp;(<a href="https://github.com/k06a">@k06a</a>), Mikhail Melnik&nbsp;(<a href="https://github.com/ZumZoom">@ZumZoom</a>), Josh Weintraub (@jhweintraub)&nbsp;&lt;<a href="mailto:jhweintraub@gmail.com">jhweintraub@gmail.com</a>&gt;, Rob Montgomery (@RobAnon)&nbsp;&lt;<a href="mailto:rob@revest.finance">rob@revest.finance</a>&gt;, vectorized&nbsp;(<a href="https://github.com/vectorized">@vectorized</a>), Víctor Martínez&nbsp;(<a href="https://github.com/vnmrtz">@vnmrtz</a>), Adrián Pajares&nbsp;(<a href="https://github.com/0xadrii">@0xadrii</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6596">6596</a></td> <td class="title">Cultural and Historical Asset Token</td> <td class="author">Phillip Pon&nbsp;&lt;<a href="mailto:phillip@artifactlabs.com">phillip@artifactlabs.com</a>&gt;, Gary Liu&nbsp;&lt;<a href="mailto:gary@artifactlabs.com">gary@artifactlabs.com</a>&gt;, Henry Chan&nbsp;&lt;<a href="mailto:henry@artifactlabs.com">henry@artifactlabs.com</a>&gt;, Joey Liu&nbsp;&lt;<a href="mailto:joey@artifactlabs.com">joey@artifactlabs.com</a>&gt;, Lauren Ho&nbsp;&lt;<a href="mailto:lauren@artifactlabs.com">lauren@artifactlabs.com</a>&gt;, Jeff Leung&nbsp;&lt;<a href="mailto:jeff@artifactlabs.com">jeff@artifactlabs.com</a>&gt;, Brian Liang&nbsp;&lt;<a href="mailto:brian@artifactlabs.com">brian@artifactlabs.com</a>&gt;, Joyce Li&nbsp;&lt;<a href="mailto:joyce@artifactlabs.com">joyce@artifactlabs.com</a>&gt;, Avir Mahtani&nbsp;&lt;<a href="mailto:avir@artifactlabs.com">avir@artifactlabs.com</a>&gt;, Antoine Cote&nbsp;(<a href="https://github.com/acote88">@acote88</a>), David Leung&nbsp;(<a href="https://github.com/dhl">@dhl</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6617">6617</a></td> <td class="title">Bit Based Permission</td> <td class="author">Chiro&nbsp;(<a href="https://github.com/chiro-hiro">@chiro-hiro</a>), Victor Dusart&nbsp;(<a href="https://github.com/vdusart">@vdusart</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6734">6734</a></td> <td class="title">L2 Token List</td> <td class="author">Kelvin Fichter&nbsp;(<a href="https://github.com/smartcontracts">@smartcontracts</a>), Andreas Freund&nbsp;(<a href="https://github.com/Therecanbeonlyone1969">@Therecanbeonlyone1969</a>), Pavel Sinelnikov&nbsp;(<a href="https://github.com/psinelnikov">@psinelnikov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6735">6735</a></td> <td class="title">L2 Aliasing of EVM-based Addresses</td> <td class="author">Kelvin Fichter&nbsp;(<a href="https://github.com/smartcontracts">@smartcontracts</a>), Andreas Freund&nbsp;(<a href="https://github.com/Therecanbeonlyone1969">@Therecanbeonlyone1969</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6956">6956</a></td> <td class="title">Asset-bound Non-Fungible Tokens</td> <td class="author">Thomas Bergmueller&nbsp;(<a href="https://github.com/tbergmueller">@tbergmueller</a>), Lukas Meyer&nbsp;(<a href="https://github.com/ibex-technology">@ibex-technology</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6997">6997</a></td> <td class="title">ERC-721 with transaction validation step.</td> <td class="author">Eduard López i Fina&nbsp;(<a href="https://github.com/eduardfina">@eduardfina</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7015">7015</a></td> <td class="title">NFT Creator Attribution</td> <td class="author">indreams&nbsp;(<a href="https://github.com/strollinghome">@strollinghome</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7144">7144</a></td> <td class="title">ERC-20 with transaction validation step.</td> <td class="author">Eduard López i Fina&nbsp;(<a href="https://github.com/eduardfina">@eduardfina</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7246">7246</a></td> <td class="title">Encumber - Splitting Ownership &amp; Guarantees</td> <td class="author">Coburn Berry&nbsp;(<a href="https://github.com/coburncoburn">@coburncoburn</a>), Mykel Pereira&nbsp;(<a href="https://github.com/mykelp">@mykelp</a>), Scott Silver&nbsp;(<a href="https://github.com/scott-silver">@scott-silver</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7399">7399</a></td> <td class="title">⚡ Flash Loans ⚡</td> <td class="author">Alberto Cuesta Cañada&nbsp;(<a href="https://github.com/alcueca">@alcueca</a>), Michael Amadi&nbsp;(<a href="https://github.com/AmadiMichaels">@AmadiMichaels</a>), Devtooligan&nbsp;(<a href="https://github.com/devtooligan">@devtooligan</a>), Ultrasecr.eth&nbsp;(<a href="https://github.com/ultrasecreth">@ultrasecreth</a>), Sam Bacha&nbsp;(<a href="https://github.com/sambacha">@sambacha</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7417">7417</a></td> <td class="title">Token Converter</td> <td class="author">Dexaran (@Dexaran)&nbsp;&lt;<a href="mailto:dexaran@ethereumclassic.org">dexaran@ethereumclassic.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7495">7495</a></td> <td class="title">SSZ ProgressiveContainer</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Cayman&nbsp;(<a href="https://github.com/wemeetagain">@wemeetagain</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7518">7518</a></td> <td class="title">Dynamic Compliant Interop Security Token</td> <td class="author">Abhinav (@abhinav-d3v)&nbsp;&lt;<a href="mailto:abhinav@zoniqx.com">abhinav@zoniqx.com</a>&gt;, Prithvish Baidya (@d4mr)&nbsp;&lt;<a href="mailto:pbaidya@zoniqx.com">pbaidya@zoniqx.com</a>&gt;, Rajat Kumar (@rajatwasan)&nbsp;&lt;<a href="mailto:rwasan@zoniqx.com">rwasan@zoniqx.com</a>&gt;, Prasanth Kalangi&nbsp;&lt;<a href="mailto:pkalangi@zoniqx.com">pkalangi@zoniqx.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7531">7531</a></td> <td class="title">Staked ERC-721 Ownership Recognition</td> <td class="author">Francesco Sullo&nbsp;(<a href="https://github.com/sullof">@sullof</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7586">7586</a></td> <td class="title">Interest Rate Swaps</td> <td class="author">Samuel Gwlanold Edoumou&nbsp;(<a href="https://github.com/Edoumou">@Edoumou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7590">7590</a></td> <td class="title">ERC-20 Holder Extension for NFTs</td> <td class="author">Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7628">7628</a></td> <td class="title">ERC-721 Ownership Shares Extension</td> <td class="author">Chen Liaoyuan (@chenly)&nbsp;&lt;<a href="mailto:cly@kip.pro">cly@kip.pro</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7673">7673</a></td> <td class="title">Distinguishable base256emoji Addresses</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7674">7674</a></td> <td class="title">Temporary Approval Extension for ERC-20</td> <td class="author">Xenia Shape&nbsp;(<a href="https://github.com/byshape">@byshape</a>), Mikhail Melnik&nbsp;(<a href="https://github.com/ZumZoom">@ZumZoom</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7677">7677</a></td> <td class="title">Paymaster Web Service Capability</td> <td class="author">Lukas Rosario&nbsp;(<a href="https://github.com/lukasrosario">@lukasrosario</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Wilson Cusack&nbsp;(<a href="https://github.com/wilsoncusack">@wilsoncusack</a>), Kristof Gazso&nbsp;(<a href="https://github.com/kristofgazso">@kristofgazso</a>), Hazim Jumali&nbsp;(<a href="https://github.com/hazim-j">@hazim-j</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7688">7688</a></td> <td class="title">Forward compatible consensus data structures</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Cayman&nbsp;(<a href="https://github.com/wemeetagain">@wemeetagain</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7750">7750</a></td> <td class="title">Decentralized Employment System</td> <td class="author">James Savechives (@jamesavechives)&nbsp;&lt;<a href="mailto:james.walstonn@gmail.com">james.walstonn@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7758">7758</a></td> <td class="title">Transfer With Authorization</td> <td class="author">Peter Jihoon Kim&nbsp;(<a href="https://github.com/petejkim">@petejkim</a>), Kevin Britz&nbsp;(<a href="https://github.com/kbrizzle">@kbrizzle</a>), David Knott&nbsp;(<a href="https://github.com/DavidLKnott">@DavidLKnott</a>), Dongri Jin&nbsp;(<a href="https://github.com/dongri">@dongri</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7776">7776</a></td> <td class="title">Transparent Financial Statements</td> <td class="author">Ignacio Ceaglio (@Nachoxt17)&nbsp;&lt;<a href="mailto:ignacioceaglio@gmail.com">ignacioceaglio@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7777">7777</a></td> <td class="title">Governance for Human Robot Societies</td> <td class="author">OpenMind, Jan Liphardt&nbsp;&lt;<a href="mailto:jan@openmind.org">jan@openmind.org</a>&gt;, Shaohong Zhong&nbsp;(<a href="https://github.com/ShaohongZ">@ShaohongZ</a>), Boyuan Chen&nbsp;(<a href="https://github.com/bchen-dev">@bchen-dev</a>), Paige Xu&nbsp;&lt;<a href="mailto:paige@openmind.org">paige@openmind.org</a>&gt;, James Ball&nbsp;&lt;<a href="mailto:james.ball@nethermind.io">james.ball@nethermind.io</a>&gt;, Thamer Dridi&nbsp;&lt;<a href="mailto:thamer.dridi@nethermind.io">thamer.dridi@nethermind.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7812">7812</a></td> <td class="title">ZK Identity Registry</td> <td class="author">Artem Chystiakov (@arvolear)&nbsp;&lt;<a href="mailto:artem@rarilabs.com">artem@rarilabs.com</a>&gt;, Oleksandr Kurbatov&nbsp;&lt;<a href="mailto:oleksandr@rarilabs.com">oleksandr@rarilabs.com</a>&gt;, Yaroslav Panasenko&nbsp;&lt;<a href="mailto:yaroslav@rarilabs.com">yaroslav@rarilabs.com</a>&gt;, Michael Elliot (@michaelelliot)&nbsp;&lt;<a href="mailto:mike@zkpassport.id">mike@zkpassport.id</a>&gt;, Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7813">7813</a></td> <td class="title">Store, Table-Based Introspectable Storage</td> <td class="author">alvarius&nbsp;(<a href="https://github.com/alvrs">@alvrs</a>), dk1a&nbsp;(<a href="https://github.com/dk1a">@dk1a</a>), frolic&nbsp;(<a href="https://github.com/frolic">@frolic</a>), ludens&nbsp;(<a href="https://github.com/ludns">@ludns</a>), vdrg&nbsp;(<a href="https://github.com/vdrg">@vdrg</a>), yonada&nbsp;&lt;<a href="mailto:yonada@proton.me">yonada@proton.me</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7828">7828</a></td> <td class="title">Interoperable Names</td> <td class="author">Sam Kaufman&nbsp;(<a href="https://github.com/SampkaML">@SampkaML</a>), Marco Stronati&nbsp;(<a href="https://github.com/paracetamolo">@paracetamolo</a>), Yuliya Alexiev&nbsp;(<a href="https://github.com/yuliyaalexiev">@yuliyaalexiev</a>), Jeff Lau&nbsp;(<a href="https://github.com/jefflau">@jefflau</a>), Sam Wilson&nbsp;(<a href="https://github.com/samwilsn">@samwilsn</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Teddy&nbsp;(<a href="https://github.com/0xteddybear">@0xteddybear</a>), Joxes&nbsp;(<a href="https://github.com/Joxess">@Joxess</a>), Racu&nbsp;(<a href="https://github.com/0xRacoon">@0xRacoon</a>), Skeletor Spaceman&nbsp;(<a href="https://github.com/0xskeletor-spaceman">@0xskeletor-spaceman</a>), TiTi&nbsp;(<a href="https://github.com/0xtiti">@0xtiti</a>), Gori&nbsp;(<a href="https://github.com/0xGorilla">@0xGorilla</a>), Ardy&nbsp;(<a href="https://github.com/0xArdy">@0xArdy</a>), Onizuka&nbsp;(<a href="https://github.com/onizuka-wl">@onizuka-wl</a>), Lumi&nbsp;(<a href="https://github.com/oxlumi">@oxlumi</a>), Moebius&nbsp;(<a href="https://github.com/0xmoebius">@0xmoebius</a>), Thomas Clowes&nbsp;(<a href="https://github.com/clowestab">@clowestab</a>), Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>), Mono&nbsp;(<a href="https://github.com/0xMonoAx">@0xMonoAx</a>), Orca&nbsp;(<a href="https://github.com/0xrcinus">@0xrcinus</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7829">7829</a></td> <td class="title">Data Asset NFT</td> <td class="author">Allen Dong&nbsp;(<a href="https://github.com/Allen2730">@Allen2730</a>), Lonika Zhang&nbsp;&lt;<a href="mailto:lonika@memolabs.net">lonika@memolabs.net</a>&gt;, Steven He&nbsp;&lt;<a href="mailto:steven@memolabs.net">steven@memolabs.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7832">7832</a></td> <td class="title">Sustainable collaborative NFT collections</td> <td class="author">Gustavo Lobo&nbsp;(<a href="https://github.com/gflobo">@gflobo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7834">7834</a></td> <td class="title">Separate Metadata Section for EOF</td> <td class="author">Kaan Uzdogan&nbsp;(<a href="https://github.com/kuzdogan">@kuzdogan</a>), Marco Castignoli&nbsp;(<a href="https://github.com/marcocastignoli">@marcocastignoli</a>), Manuel Wedler&nbsp;(<a href="https://github.com/manuelwedler">@manuelwedler</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7866">7866</a></td> <td class="title">Decentralised User Profiles</td> <td class="author">Kumar Anirudha&nbsp;(<a href="https://github.com/anistark">@anistark</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7872">7872</a></td> <td class="title">Max blob flag for local builders</td> <td class="author">Francesco D'Amato&nbsp;&lt;<a href="mailto:francesco.damato@ethereum.org">francesco.damato@ethereum.org</a>&gt;, Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Dustin&nbsp;(<a href="https://github.com/tersec">@tersec</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7880">7880</a></td> <td class="title">EOF - EXTCODEADDRESS instruction</td> <td class="author">Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7916">7916</a></td> <td class="title">SSZ ProgressiveList</td> <td class="author">Zsolt Felföldi&nbsp;(<a href="https://github.com/zsfelfoldi">@zsfelfoldi</a>), Cayman&nbsp;(<a href="https://github.com/wemeetagain">@wemeetagain</a>), Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7930">7930</a></td> <td class="title">Interoperable Addresses</td> <td class="author">Teddy&nbsp;(<a href="https://github.com/0xteddybear">@0xteddybear</a>), Joxes&nbsp;(<a href="https://github.com/0xJoxess">@0xJoxess</a>), Nick Johnson&nbsp;(<a href="https://github.com/Arachnid">@Arachnid</a>), Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Skeletor Spaceman&nbsp;(<a href="https://github.com/skeletor-spaceman">@skeletor-spaceman</a>), Racu&nbsp;(<a href="https://github.com/0xRacoon">@0xRacoon</a>), TiTi&nbsp;(<a href="https://github.com/0xtiti">@0xtiti</a>), Gori&nbsp;(<a href="https://github.com/0xGorilla">@0xGorilla</a>), Ardy&nbsp;(<a href="https://github.com/0xArdy">@0xArdy</a>), Onizuka&nbsp;(<a href="https://github.com/onizuka-wl">@onizuka-wl</a>), Sam Kaufman&nbsp;(<a href="https://github.com/SampkaML">@SampkaML</a>), Marco Stronati&nbsp;(<a href="https://github.com/paracetamolo">@paracetamolo</a>), Yuliya Alexiev&nbsp;(<a href="https://github.com/yuliyaalexiev">@yuliyaalexiev</a>), Jeff Lau&nbsp;(<a href="https://github.com/jefflau">@jefflau</a>), Sam Wilson&nbsp;(<a href="https://github.com/samwilsn">@samwilsn</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Thomas Clowes&nbsp;(<a href="https://github.com/clowestab">@clowestab</a>), Mono&nbsp;(<a href="https://github.com/0xMonoAx">@0xMonoAx</a>), Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>), Orca&nbsp;(<a href="https://github.com/0xrcinus">@0xrcinus</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7936">7936</a></td> <td class="title">Versioned Proxy Contract Interface</td> <td class="author">Raphina Liu&nbsp;(<a href="https://github.com/Stamp9">@Stamp9</a>), Monica Jin&nbsp;(<a href="https://github.com/mokita-j">@mokita-j</a>), Martin Monperrus&nbsp;(<a href="https://github.com/monperrus">@monperrus</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7945">7945</a></td> <td class="title">Confidential Transactions Supported Token</td> <td class="author">Siyuan Zheng (@andrewcoder666)&nbsp;&lt;<a href="mailto:zhengsiyuan.zsy@antgroup.com">zhengsiyuan.zsy@antgroup.com</a>&gt;, Zhe Han (@iampkuhz)&nbsp;&lt;<a href="mailto:hanzhe.hz@ant-intl.com">hanzhe.hz@ant-intl.com</a>&gt;, Xiaoyu Liu (@elizabethxiaoyu)&nbsp;&lt;<a href="mailto:jiushi.lxy@antgroup.com">jiushi.lxy@antgroup.com</a>&gt;, Wenwei Ma (@madyinglight)&nbsp;&lt;<a href="mailto:huiwei.mww@antgroup.com">huiwei.mww@antgroup.com</a>&gt;, Jun Meng Tan (@chadxeth)&nbsp;&lt;<a href="mailto:junmeng.t@antgroup.com">junmeng.t@antgroup.com</a>&gt;, Yuxiang Fu (@tmac4096)&nbsp;&lt;<a href="mailto:kunfu.fyx@antgroup.com">kunfu.fyx@antgroup.com</a>&gt;, Kecheng Gao (@thanks-v-me-50)&nbsp;&lt;<a href="mailto:gaokecheng.gkc@antgroup.com">gaokecheng.gkc@antgroup.com</a>&gt;, Alwin Ng Jun Wei (@alwinngjw)&nbsp;&lt;<a href="mailto:alwin.ng@antgroup.com">alwin.ng@antgroup.com</a>&gt;, Chenxin Wang (@3235773541)&nbsp;&lt;<a href="mailto:wcx465603@antgroup.com">wcx465603@antgroup.com</a>&gt;, Xiang Gao (@GaoYiRu)&nbsp;&lt;<a href="mailto:gaoxiang.gao@antgroup.com">gaoxiang.gao@antgroup.com</a>&gt;, yuanshanhshan (@xunayuan)&nbsp;&lt;<a href="mailto:yuanshanshan.yss@antgroup.com">yuanshanshan.yss@antgroup.com</a>&gt;, Hao Zou (@BruceZH0915)&nbsp;&lt;<a href="mailto:situ.zh@antgroup.com">situ.zh@antgroup.com</a>&gt;, Yanyi Liang&nbsp;&lt;<a href="mailto:eason.lyy@antgroup.com">eason.lyy@antgroup.com</a>&gt;, Yuehua Zhang (@astroyhzcc)&nbsp;&lt;<a href="mailto:ruoying.zyh@antgroup.com">ruoying.zyh@antgroup.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8019">8019</a></td> <td class="title">Minimal Wallet-Managed Auto-Login for SIWE</td> <td class="author">Ivo Georgiev&nbsp;(<a href="https://github.com/Ivshti">@Ivshti</a>), Vijay Krishnavanshi&nbsp;(<a href="https://github.com/vijaykrishnavanshi">@vijaykrishnavanshi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8024">8024</a></td> <td class="title">Backward compatible SWAPN, DUPN, EXCHANGE</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8111">8111</a></td> <td class="title">Bound Signatures</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8126">8126</a></td> <td class="title">AI Agent Verification</td> <td class="author">Leigh Cronian (@cybercentry)&nbsp;&lt;<a href="mailto:leigh.cronian@cybercentry.co.uk">leigh.cronian@cybercentry.co.uk</a>&gt;, Chris Johnson&nbsp;&lt;<a href="mailto:chris@virtuals.io">chris@virtuals.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8152">8152</a></td> <td class="title">Content-Addressable Logic Modules (CALM)</td> <td class="author">Radek Svarz&nbsp;(<a href="https://github.com/radeksvarz">@radeksvarz</a>), Nick Mudge&nbsp;(<a href="https://github.com/mudgen">@mudgen</a>), William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8161">8161</a></td> <td class="title">Transferable Tokenized Vault Requests</td> <td class="author">Cain O'Sullivan&nbsp;(<a href="https://github.com/cosullivan">@cosullivan</a>), Jeroen Offerijns&nbsp;(<a href="https://github.com/hieronx">@hieronx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8167">8167</a></td> <td class="title">Modular Dispatch Proxies</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>), Radek Svarz&nbsp;(<a href="https://github.com/radeksvarz">@radeksvarz</a>)</td> </tr> </table> <h2 id="draft">Draft</h2> <table class="eiptable"> <thead> <tr><th class="eipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr> </thead> <tr> <td class="eipnum"><a href="/assets/eip-7932/template-eip"></a></td> <td class="title">Example EIP to add generic algorithm as an algorithmic type</td> <td class="author"></td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-725">725</a></td> <td class="title">General data key/value store and execution</td> <td class="author">Fabian Vogelsteller&nbsp;(<a href="https://github.com/frozeman">@frozeman</a>), Tyler Yasaka&nbsp;(<a href="https://github.com/tyleryasaka">@tyleryasaka</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-838">838</a></td> <td class="title">ABI specification for REVERT reason string</td> <td class="author">Federico Bond&nbsp;(<a href="https://github.com/federicobond">@federicobond</a>), Renan Rodrigues de Souza&nbsp;(<a href="https://github.com/RenanSouza2">@RenanSouza2</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-998">998</a></td> <td class="title">Composable Non-Fungible Token</td> <td class="author">Matt Lockyer&nbsp;&lt;<a href="mailto:mattdlockyer@gmail.com">mattdlockyer@gmail.com</a>&gt;, Nick Mudge&nbsp;&lt;<a href="mailto:nick@perfectabstractions.com">nick@perfectabstractions.com</a>&gt;, Jordan Schalm&nbsp;&lt;<a href="mailto:jordan.schalm@gmail.com">jordan.schalm@gmail.com</a>&gt;, sebastian echeverry&nbsp;&lt;<a href="mailto:sebastian.echeverry@robotouniverse.com">sebastian.echeverry@robotouniverse.com</a>&gt;, Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2780">2780</a></td> <td class="title">Reduce intrinsic transaction gas</td> <td class="author">Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Uri Klarman&nbsp;(<a href="https://github.com/uriklarman">@uriklarman</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Maria Inês Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Anthony Sassano&nbsp;(<a href="https://github.com/sassal">@sassal</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2926">2926</a></td> <td class="title">Chunk-Based Code Merkleization</td> <td class="author">Sina Mahmoodi&nbsp;(<a href="https://github.com/s1na">@s1na</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3009">3009</a></td> <td class="title">Transfer With Authorization</td> <td class="author">Peter Jihoon Kim&nbsp;(<a href="https://github.com/petejkim">@petejkim</a>), Kevin Britz&nbsp;(<a href="https://github.com/kbrizzle">@kbrizzle</a>), David Knott&nbsp;(<a href="https://github.com/DavidLKnott">@DavidLKnott</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3770">3770</a></td> <td class="title">Chain-specific addresses</td> <td class="author">Lukas Schor&nbsp;(<a href="https://github.com/lukasschor">@lukasschor</a>), Richard Meissner&nbsp;(<a href="https://github.com/rmeissner">@rmeissner</a>), Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>), ligi&nbsp;&lt;<a href="mailto:ligi@ligi.de">ligi@ligi.de</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4762">4762</a></td> <td class="title">Statelessness gas cost changes</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Tanishq Jasoria&nbsp;(<a href="https://github.com/tanishqjasoria">@tanishqjasoria</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4883">4883</a></td> <td class="title">Composable SVG NFT</td> <td class="author">Andrew B Coathup&nbsp;(<a href="https://github.com/abcoathup">@abcoathup</a>), Alex&nbsp;(<a href="https://github.com/AlexPartyPanda">@AlexPartyPanda</a>), Damian Martinelli&nbsp;(<a href="https://github.com/damianmarti">@damianmarti</a>), blockdev&nbsp;(<a href="https://github.com/0xbok">@0xbok</a>), Austin Griffith&nbsp;(<a href="https://github.com/austintgriffith">@austintgriffith</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4972">4972</a></td> <td class="title">Name-Owned Account</td> <td class="author">Shu Dong&nbsp;(<a href="https://github.com/dongshu2013">@dongshu2013</a>), Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Zihao Chen&nbsp;(<a href="https://github.com/zihaoccc">@zihaoccc</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5115">5115</a></td> <td class="title">SY Token</td> <td class="author">Vu Nguyen&nbsp;(<a href="https://github.com/mrenoon">@mrenoon</a>), Long Vuong&nbsp;(<a href="https://github.com/UncleGrandpa925">@UncleGrandpa925</a>), Anton Buenavista&nbsp;(<a href="https://github.com/ayobuenavista">@ayobuenavista</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5173">5173</a></td> <td class="title">NFT Future Rewards (nFR)</td> <td class="author">Yale ReiSoleil&nbsp;(<a href="https://github.com/longnshort">@longnshort</a>), dRadiant&nbsp;(<a href="https://github.com/dRadiant">@dRadiant</a>), D Wang, PhD&nbsp;&lt;<a href="mailto:david@iob.fi">david@iob.fi</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5189">5189</a></td> <td class="title">Account Abstraction via Endorsed Operations</td> <td class="author">Agustín Aguilar&nbsp;(<a href="https://github.com/agusx1211">@agusx1211</a>), Philippe Castonguay&nbsp;(<a href="https://github.com/phabc">@phabc</a>), Michael Standen&nbsp;(<a href="https://github.com/ScreamingHawk">@ScreamingHawk</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5516">5516</a></td> <td class="title">Soulbound Multi-owner Tokens</td> <td class="author">Lucas Martín Grasso Ramos&nbsp;(<a href="https://github.com/LucasGrasso">@LucasGrasso</a>), Matias Arazi&nbsp;(<a href="https://github.com/MatiArazi">@MatiArazi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5573">5573</a></td> <td class="title">Sign-In with Ethereum Capabilities, ReCaps</td> <td class="author">Oliver Terbu&nbsp;(<a href="https://github.com/awoie">@awoie</a>), Jacob Ward&nbsp;(<a href="https://github.com/cobward">@cobward</a>), Charles Lehner&nbsp;(<a href="https://github.com/clehner">@clehner</a>), Sam Gbafa&nbsp;(<a href="https://github.com/skgbafa">@skgbafa</a>), Wayne Chang&nbsp;(<a href="https://github.com/wyc">@wyc</a>), Charles Cunningham&nbsp;(<a href="https://github.com/chunningham">@chunningham</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5604">5604</a></td> <td class="title">NFT Lien</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>), Allen Zhou&nbsp;&lt;<a href="mailto:allen@ubiloan.io">allen@ubiloan.io</a>&gt;, Alex Qin&nbsp;&lt;<a href="mailto:alex@ubiloan.io">alex@ubiloan.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5630">5630</a></td> <td class="title">New approach for encryption / decryption</td> <td class="author">Firn Protocol&nbsp;(<a href="https://github.com/firnprotocol">@firnprotocol</a>), Fried L. Trout, Weiji Guo&nbsp;(<a href="https://github.com/weijiguo">@weijiguo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5700">5700</a></td> <td class="title">Bindable Token Interface</td> <td class="author">Leeren&nbsp;(<a href="https://github.com/leeren">@leeren</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5727">5727</a></td> <td class="title">Semi-Fungible Soulbound Token</td> <td class="author">Austin Zhu&nbsp;(<a href="https://github.com/AustinZhu">@AustinZhu</a>), Terry Chen&nbsp;&lt;<a href="mailto:terry.chen@phaneroz.io">terry.chen@phaneroz.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5791">5791</a></td> <td class="title">Physical Backed Tokens</td> <td class="author">2pmflow&nbsp;(<a href="https://github.com/2pmflow">@2pmflow</a>), locationtba&nbsp;(<a href="https://github.com/locationtba">@locationtba</a>), Cameron Robertson&nbsp;(<a href="https://github.com/ccamrobertson">@ccamrobertson</a>), cygaar&nbsp;(<a href="https://github.com/cygaar">@cygaar</a>), Brian Weick&nbsp;(<a href="https://github.com/bweick">@bweick</a>), vectorized&nbsp;(<a href="https://github.com/vectorized">@vectorized</a>), djdabs&nbsp;(<a href="https://github.com/djdabs">@djdabs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6123">6123</a></td> <td class="title">Smart Derivative Contract</td> <td class="author">Christian Fries&nbsp;(<a href="https://github.com/cfries">@cfries</a>), Peter Kohl-Landgraf&nbsp;(<a href="https://github.com/pekola">@pekola</a>), Alexandros Korpis&nbsp;(<a href="https://github.com/kourouta">@kourouta</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6170">6170</a></td> <td class="title">Cross-Chain Messaging Interface</td> <td class="author">Sujith Somraaj&nbsp;(<a href="https://github.com/sujithsomraaj">@sujithsomraaj</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6229">6229</a></td> <td class="title">Tokenized Vaults with Lock-in Period</td> <td class="author">Anderson Chen&nbsp;(<a href="https://github.com/Ankarrr">@Ankarrr</a>), Martinet Lee&nbsp;&lt;<a href="mailto:martinetlee@gmail.com">martinetlee@gmail.com</a>&gt;, Anton Cheng&nbsp;&lt;<a href="mailto:antonassocareer@gmail.com">antonassocareer@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6327">6327</a></td> <td class="title">Elastic Signature</td> <td class="author">George&nbsp;(<a href="https://github.com/JXRow">@JXRow</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6404">6404</a></td> <td class="title">SSZ transactions</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6465">6465</a></td> <td class="title">SSZ withdrawals root</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6466">6466</a></td> <td class="title">SSZ receipts</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6493">6493</a></td> <td class="title">SSZ transaction signature scheme</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6604">6604</a></td> <td class="title">Abstract Token</td> <td class="author">Chris Walker (@cr-walker)&nbsp;&lt;<a href="mailto:chris@ckwalker.com">chris@ckwalker.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6662">6662</a></td> <td class="title">AA Account Metadata For Authentication</td> <td class="author">Shu Dong&nbsp;(<a href="https://github.com/dongshu2013">@dongshu2013</a>), Zihao Chen&nbsp;(<a href="https://github.com/zihaoccc">@zihaoccc</a>), Peter Chen&nbsp;(<a href="https://github.com/pette1999">@pette1999</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6682">6682</a></td> <td class="title">NFT Flashloans</td> <td class="author">out.eth&nbsp;(<a href="https://github.com/outdoteth">@outdoteth</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6785">6785</a></td> <td class="title">ERC-721 Utilities Information Extension</td> <td class="author">Otniel Nicola&nbsp;(<a href="https://github.com/OT-kthd">@OT-kthd</a>), Bogdan Popa&nbsp;(<a href="https://github.com/BogdanKTHD">@BogdanKTHD</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6786">6786</a></td> <td class="title">Registry for royalties payment for NFTs</td> <td class="author">Otniel Nicola&nbsp;(<a href="https://github.com/OT-kthd">@OT-kthd</a>), Bogdan Popa&nbsp;(<a href="https://github.com/BogdanKTHD">@BogdanKTHD</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6787">6787</a></td> <td class="title">Order Book DEX with Two Phase Withdrawal</td> <td class="author">Jessica&nbsp;(<a href="https://github.com/qizheng09">@qizheng09</a>), Roy&nbsp;(<a href="https://github.com/royshang">@royshang</a>), Jun&nbsp;(<a href="https://github.com/SniperUsopp">@SniperUsopp</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6806">6806</a></td> <td class="title">ERC-721 Holding Time Tracking</td> <td class="author">Saitama&nbsp;(<a href="https://github.com/saitama2009">@saitama2009</a>), Combo&nbsp;&lt;<a href="mailto:combo@1combo.io">combo@1combo.io</a>&gt;, Luigi&nbsp;&lt;<a href="mailto:luigi@1combo.io">luigi@1combo.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6821">6821</a></td> <td class="title">Support ENS Name for Web3 URL</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Qiang Zhu&nbsp;(<a href="https://github.com/qzhodl">@qzhodl</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6823">6823</a></td> <td class="title">Token Mapping Slot Retrieval Extension</td> <td class="author">qdqd (@qd-qd)&nbsp;&lt;<a href="mailto:qdqdqdqdqd@protonmail.com">qdqdqdqdqd@protonmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6860">6860</a></td> <td class="title">Web3 URL to EVM Call Message Translation</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Chao Pi&nbsp;(<a href="https://github.com/pichaoqkc">@pichaoqkc</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>), Nicolas Deschildre&nbsp;(<a href="https://github.com/nand2">@nand2</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6864">6864</a></td> <td class="title">Upgradable Fungible Token</td> <td class="author">Jeff Huang&nbsp;(<a href="https://github.com/jeffishjeff">@jeffishjeff</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6865">6865</a></td> <td class="title">On-Chain EIP-712 Visualization</td> <td class="author">Abderrahmen Hanafi&nbsp;(<a href="https://github.com/a6-dou">@a6-dou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6900">6900</a></td> <td class="title">Modular Smart Contract Accounts</td> <td class="author">Adam Egyed&nbsp;(<a href="https://github.com/adamegyed">@adamegyed</a>), Fangting Liu&nbsp;(<a href="https://github.com/trinity-0111">@trinity-0111</a>), Jay Paik&nbsp;(<a href="https://github.com/jaypaik">@jaypaik</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Huawei Gu&nbsp;(<a href="https://github.com/huaweigu">@huaweigu</a>), Daniel Lim&nbsp;(<a href="https://github.com/dlim-circle">@dlim-circle</a>), Ruben Koch&nbsp;(<a href="https://github.com/0xrubes">@0xrubes</a>), David Philipson&nbsp;(<a href="https://github.com/dphilipson">@dphilipson</a>), Howy Ho&nbsp;(<a href="https://github.com/howydev">@howydev</a>), Nikita Belenkov&nbsp;(<a href="https://github.com/nikita-quantstamp">@nikita-quantstamp</a>), zer0dot&nbsp;(<a href="https://github.com/zer0dot">@zer0dot</a>), David Kim&nbsp;(<a href="https://github.com/PowerStream3604">@PowerStream3604</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6932">6932</a></td> <td class="title">Subscription-Based Token</td> <td class="author">360 Core&nbsp;&lt;<a href="mailto:hello@360coreinc.com">hello@360coreinc.com</a>&gt;, Robin Rajput&nbsp;(<a href="https://github.com/0xRobinR">@0xRobinR</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6944">6944</a></td> <td class="title">ERC-5219 Resolve Mode</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>), Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6960">6960</a></td> <td class="title">Dual Layer Token</td> <td class="author">Adam Boudjemaa&nbsp;(<a href="https://github.com/aboudjem">@aboudjem</a>), Mohamad Hammoud&nbsp;(<a href="https://github.com/mohamadhammoud">@mohamadhammoud</a>), Nawar Hisso&nbsp;(<a href="https://github.com/nawar-hisso">@nawar-hisso</a>), Khawla Hassan&nbsp;(<a href="https://github.com/khawlahssn">@khawlahssn</a>), Mohammad Zakeri Rad&nbsp;(<a href="https://github.com/zakrad">@zakrad</a>), Ashish Sood&nbsp;&lt;<a href="mailto:soodgen@gmail.com">soodgen@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6981">6981</a></td> <td class="title">Reserved Ownership Accounts</td> <td class="author">Paul Sullivan (@sullivph)&nbsp;&lt;<a href="mailto:paul.sullivan@manifold.xyz">paul.sullivan@manifold.xyz</a>&gt;, Wilkins Chung (@wwchung)&nbsp;&lt;<a href="mailto:wilkins@manifold.xyz">wilkins@manifold.xyz</a>&gt;, Kartik Patel (@Slokh)&nbsp;&lt;<a href="mailto:kartik@manifold.xyz">kartik@manifold.xyz</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7085">7085</a></td> <td class="title">NFT Relationship Enhancement</td> <td class="author">Guang&nbsp;(<a href="https://github.com/xg1990">@xg1990</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7087">7087</a></td> <td class="title">MIME type for Web3 URL in Auto Mode</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Nicolas Deschildre&nbsp;(<a href="https://github.com/nand2">@nand2</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7093">7093</a></td> <td class="title">Social Recovery Interface</td> <td class="author">John Zhang&nbsp;(<a href="https://github.com/johnz1019">@johnz1019</a>), Davis Xiang&nbsp;(<a href="https://github.com/xcshuan">@xcshuan</a>), Kyle Xu&nbsp;(<a href="https://github.com/kylexyxu">@kylexyxu</a>), George Zhang&nbsp;(<a href="https://github.com/odysseus0">@odysseus0</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7196">7196</a></td> <td class="title">Simple token, Simplified ERC-20</td> <td class="author">Xiang&nbsp;(<a href="https://github.com/wenzhenxiang">@wenzhenxiang</a>), Ben77&nbsp;(<a href="https://github.com/ben2077">@ben2077</a>), Mingshi S.&nbsp;(<a href="https://github.com/newnewsms">@newnewsms</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7204">7204</a></td> <td class="title">Contract wallet management token</td> <td class="author">Xiang&nbsp;(<a href="https://github.com/wenzhenxiang">@wenzhenxiang</a>), Ben77&nbsp;(<a href="https://github.com/ben2077">@ben2077</a>), Mingshi S.&nbsp;(<a href="https://github.com/newnewsms">@newnewsms</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7254">7254</a></td> <td class="title">Token Revenue Sharing</td> <td class="author">Quy Phan&nbsp;(<a href="https://github.com/quyphandang">@quyphandang</a>), Quy Phan&nbsp;&lt;<a href="mailto:quy.phan@cryptoviet.info">quy.phan@cryptoviet.info</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7272">7272</a></td> <td class="title">Ethereum Access Token</td> <td class="author">Chris Chung&nbsp;(<a href="https://github.com/0xpApaSmURf">@0xpApaSmURf</a>), Raphael Roullet&nbsp;(<a href="https://github.com/ra-phael">@ra-phael</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7280">7280</a></td> <td class="title">NFT Metadata Extension like JSON-LD</td> <td class="author">Yohei Nishikubo&nbsp;(<a href="https://github.com/yoheinishikubo">@yoheinishikubo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7303">7303</a></td> <td class="title">Token-Controlled Token Circulation</td> <td class="author">Ko Fujimura&nbsp;(<a href="https://github.com/kofujimura">@kofujimura</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7390">7390</a></td> <td class="title">Vanilla Options for ERC-20 Tokens</td> <td class="author">Ewan Humbert (@Xeway)&nbsp;&lt;<a href="mailto:xeway@protonmail.com">xeway@protonmail.com</a>&gt;, Lassi Maksimainen (@mlalma)&nbsp;&lt;<a href="mailto:lassi.maksimainen@gmail.com">lassi.maksimainen@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7405">7405</a></td> <td class="title">Portable Smart Contract Accounts</td> <td class="author">Aaron Yee&nbsp;(<a href="https://github.com/aaronyee-eth">@aaronyee-eth</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7406">7406</a></td> <td class="title">Multi-Namespace Onchain Registry</td> <td class="author">Mengshi Zhang&nbsp;(<a href="https://github.com/MengshiZhang">@MengshiZhang</a>), Zihao Chen&nbsp;(<a href="https://github.com/zihaoccc">@zihaoccc</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7410">7410</a></td> <td class="title">ERC-20 Update Allowance By Spender</td> <td class="author">Mohammad Zakeri Rad&nbsp;(<a href="https://github.com/zakrad">@zakrad</a>), Adam Boudjemaa&nbsp;(<a href="https://github.com/aboudjem">@aboudjem</a>), Mohamad Hammoud&nbsp;(<a href="https://github.com/mohamadhammoud">@mohamadhammoud</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7412">7412</a></td> <td class="title">On-Demand Off-Chain Data Retrieval</td> <td class="author">Noah Litvin&nbsp;(<a href="https://github.com/noahlitvin">@noahlitvin</a>), db&nbsp;(<a href="https://github.com/dbeal-eth">@dbeal-eth</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7425">7425</a></td> <td class="title">Tokenized Reserve</td> <td class="author">Jimmy Debe&nbsp;(<a href="https://github.com/jimstir">@jimstir</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7444">7444</a></td> <td class="title">Time Locks Maturity</td> <td class="author">Thanh Trinh (@thanhtrinh2003)&nbsp;&lt;<a href="mailto:thanh@revest.finance">thanh@revest.finance</a>&gt;, Joshua Weintraub (@jhweintraub)&nbsp;&lt;<a href="mailto:josh@revest.finance">josh@revest.finance</a>&gt;, Rob Montgomery (@RobAnon)&nbsp;&lt;<a href="mailto:rob@revest.finance">rob@revest.finance</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7484">7484</a></td> <td class="title">Registry Extension for ERC-7579</td> <td class="author">Konrad Kopp&nbsp;(<a href="https://github.com/kopy-kat">@kopy-kat</a>), zeroknots&nbsp;(<a href="https://github.com/zeroknots">@zeroknots</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7496">7496</a></td> <td class="title">NFT Dynamic Traits</td> <td class="author">Adam Montgomery&nbsp;(<a href="https://github.com/montasaurus">@montasaurus</a>), Ryan Ghods&nbsp;(<a href="https://github.com/ryanio">@ryanio</a>), 0age&nbsp;(<a href="https://github.com/0age">@0age</a>), James Wenzel&nbsp;(<a href="https://github.com/emo-eth">@emo-eth</a>), Stephan Min&nbsp;(<a href="https://github.com/stephankmin">@stephankmin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7498">7498</a></td> <td class="title">NFT Redeemables</td> <td class="author">Ryan Ghods&nbsp;(<a href="https://github.com/ryanio">@ryanio</a>), 0age&nbsp;(<a href="https://github.com/0age">@0age</a>), Adam Montgomery&nbsp;(<a href="https://github.com/montasaurus">@montasaurus</a>), Stephan Min&nbsp;(<a href="https://github.com/stephankmin">@stephankmin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7506">7506</a></td> <td class="title">Trusted Hint Registry</td> <td class="author">Philipp Bolte&nbsp;(<a href="https://github.com/strumswell">@strumswell</a>), Dennis von der Bey&nbsp;(<a href="https://github.com/DennisVonDerBey">@DennisVonDerBey</a>), Lauritz Leifermann&nbsp;(<a href="https://github.com/lleifermann">@lleifermann</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7507">7507</a></td> <td class="title">Multi-User NFT Extension</td> <td class="author">Ming Jiang&nbsp;(<a href="https://github.com/minkyn">@minkyn</a>), Zheng Han&nbsp;(<a href="https://github.com/hanbsd">@hanbsd</a>), Fan Yang&nbsp;(<a href="https://github.com/fayang">@fayang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7508">7508</a></td> <td class="title">Dynamic On-Chain Token Attributes Repository</td> <td class="author">Steven Pineda&nbsp;(<a href="https://github.com/steven2308">@steven2308</a>), Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7509">7509</a></td> <td class="title">Entity Component System</td> <td class="author">Rickey&nbsp;(<a href="https://github.com/HelloRickey">@HelloRickey</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7510">7510</a></td> <td class="title">Cross-Contract Hierarchical NFT</td> <td class="author">Ming Jiang&nbsp;(<a href="https://github.com/minkyn">@minkyn</a>), Zheng Han&nbsp;(<a href="https://github.com/hanbsd">@hanbsd</a>), Fan Yang&nbsp;(<a href="https://github.com/fayang">@fayang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7511">7511</a></td> <td class="title">Minimal Proxy Contract with PUSH0</td> <td class="author">0xAA&nbsp;(<a href="https://github.com/AmazingAng">@AmazingAng</a>), vectorized&nbsp;(<a href="https://github.com/Vectorized">@Vectorized</a>), 0age&nbsp;(<a href="https://github.com/0age">@0age</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7512">7512</a></td> <td class="title">Onchain Representation for Audits</td> <td class="author">Richard Meissner - Safe&nbsp;(<a href="https://github.com/rmeissner">@rmeissner</a>), Robert Chen - OtterSec&nbsp;(<a href="https://github.com/chen-robert">@chen-robert</a>), Matthias Egli - ChainSecurity&nbsp;(<a href="https://github.com/MatthiasEgli">@MatthiasEgli</a>), Jan Kalivoda - Ackee Blockchain&nbsp;(<a href="https://github.com/jaczkal">@jaczkal</a>), Michael Lewellen - OpenZeppelin&nbsp;(<a href="https://github.com/cylon56">@cylon56</a>), Shay Zluf - Hats Finance&nbsp;(<a href="https://github.com/shayzluf">@shayzluf</a>), Alex Papageorgiou - Omniscia&nbsp;(<a href="https://github.com/alex-ppg">@alex-ppg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7513">7513</a></td> <td class="title">Smart NFT - A Component for Intent-Centric</td> <td class="author">MJ Tseng (@TsengMJ)&nbsp;&lt;<a href="mailto:tsngmj@gmail.com">tsngmj@gmail.com</a>&gt;, Clay (@Clay2018)&nbsp;&lt;<a href="mailto:clay.uw@outlook.com">clay.uw@outlook.com</a>&gt;, Jeffery.c&nbsp;&lt;<a href="mailto:jeffery.c@a3sprotocol.xyz">jeffery.c@a3sprotocol.xyz</a>&gt;, Johnny.c&nbsp;&lt;<a href="mailto:johnny.c@a3sprotocol.xyz">johnny.c@a3sprotocol.xyz</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7517">7517</a></td> <td class="title">Content Consent for AI/ML Data Mining</td> <td class="author">Bofu Chen&nbsp;(<a href="https://github.com/bafu">@bafu</a>), Tammy Yang&nbsp;(<a href="https://github.com/tammyyang">@tammyyang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7521">7521</a></td> <td class="title">General Intents for Smart Contract Wallets</td> <td class="author">Stephen Monn&nbsp;(<a href="https://github.com/pixelcircuits">@pixelcircuits</a>), Bikem Bengisu&nbsp;(<a href="https://github.com/supiket">@supiket</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7522">7522</a></td> <td class="title">OIDC ZK Verifier for AA Account</td> <td class="author">Shu Dong (@dongshu2013)&nbsp;&lt;<a href="mailto:shu@hexlink.io">shu@hexlink.io</a>&gt;, Yudao Yan&nbsp;&lt;<a href="mailto:dean@dauth.network">dean@dauth.network</a>&gt;, Song Z&nbsp;&lt;<a href="mailto:s@misfit.id">s@misfit.id</a>&gt;, Kai Chen&nbsp;&lt;<a href="mailto:kai@dauth.network">kai@dauth.network</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7524">7524</a></td> <td class="title">PLUME Signature in Wallets</td> <td class="author">Yush G (@Divide-By-0)&nbsp;&lt;<a href="mailto:aayushg@mit.edu">aayushg@mit.edu</a>&gt;, Kobi Gurkan&nbsp;(<a href="https://github.com/kobigurk">@kobigurk</a>), Richard Liu&nbsp;(<a href="https://github.com/rrrliu">@rrrliu</a>), Vivek Bhupatiraju&nbsp;(<a href="https://github.com/vb7401">@vb7401</a>), Barry Whitehat&nbsp;(<a href="https://github.com/barryWhiteHat">@barryWhiteHat</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7527">7527</a></td> <td class="title">Token Bound Function Oracle AMM</td> <td class="author">Elaine Zhang (@lanyinzly)&nbsp;&lt;<a href="mailto:lz8aj@virginia.edu">lz8aj@virginia.edu</a>&gt;, Jerry&nbsp;&lt;<a href="mailto:jerrymindflow@gmail.com">jerrymindflow@gmail.com</a>&gt;, Amandafanny&nbsp;&lt;<a href="mailto:amandafanny200@gmail.com">amandafanny200@gmail.com</a>&gt;, Shouhao Wong (@wangshouh)&nbsp;&lt;<a href="mailto:wongshouhao@outlook.com">wongshouhao@outlook.com</a>&gt;, 0xPoet&nbsp;&lt;<a href="mailto:0xpoets@gmail.com">0xpoets@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7529">7529</a></td> <td class="title">Contract Discovery and eTLD+1 Association</td> <td class="author">Todd Chapman&nbsp;(<a href="https://github.com/tthebc01">@tthebc01</a>), Charlie Sibbach&nbsp;&lt;<a href="mailto:charlie@cwsoftware.com">charlie@cwsoftware.com</a>&gt;, Sean Sing&nbsp;(<a href="https://github.com/seansing">@seansing</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7533">7533</a></td> <td class="title">Public Cross Port</td> <td class="author">George&nbsp;(<a href="https://github.com/JXRow">@JXRow</a>), Zisu&nbsp;(<a href="https://github.com/lazy1523">@lazy1523</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7538">7538</a></td> <td class="title">Multiplicative Tokens</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7546">7546</a></td> <td class="title">Upgradeable Clone for Scalable Contracts</td> <td class="author">Shogo Ochiai (@shogochiai)&nbsp;&lt;<a href="mailto:shogo.ochiai@pm.me">shogo.ochiai@pm.me</a>&gt;, Kai Hiroi (@KaiHiroi)&nbsp;&lt;<a href="mailto:kai.hiroi@pm.me">kai.hiroi@pm.me</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7548">7548</a></td> <td class="title">Open IP Protocol built on NFTs</td> <td class="author">Combo&nbsp;&lt;<a href="mailto:combo@1combo.io">combo@1combo.io</a>&gt;, Saitama&nbsp;(<a href="https://github.com/saitama2009">@saitama2009</a>), CT29&nbsp;&lt;<a href="mailto:CT29@1combo.io">CT29@1combo.io</a>&gt;, Luigi&nbsp;&lt;<a href="mailto:luigi@1combo.io">luigi@1combo.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7555">7555</a></td> <td class="title">Single Sign-On for Account Discovery</td> <td class="author">Alexander Müller&nbsp;(<a href="https://github.com/alexmmueller">@alexmmueller</a>), Gregory Markou&nbsp;(<a href="https://github.com/GregTheGreek">@GregTheGreek</a>), Willem Olding&nbsp;(<a href="https://github.com/Wollum">@Wollum</a>), Belma Gutlic&nbsp;(<a href="https://github.com/morrigan">@morrigan</a>), Marin Petrunić&nbsp;(<a href="https://github.com/mpetrunic">@mpetrunic</a>), Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7561">7561</a></td> <td class="title">Simple NFT, Simplified ERC-721</td> <td class="author">Xiang&nbsp;(<a href="https://github.com/wenzhenxiang">@wenzhenxiang</a>), Ben77&nbsp;(<a href="https://github.com/ben2077">@ben2077</a>), Mingshi S.&nbsp;(<a href="https://github.com/newnewsms">@newnewsms</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7562">7562</a></td> <td class="title">Account Abstraction Validation Scope Rules</td> <td class="author">Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7564">7564</a></td> <td class="title">Contract wallet management NFT</td> <td class="author">Xiang&nbsp;(<a href="https://github.com/wenzhenxiang">@wenzhenxiang</a>), Ben77&nbsp;(<a href="https://github.com/ben2077">@ben2077</a>), Mingshi S.&nbsp;(<a href="https://github.com/newnewsms">@newnewsms</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7565">7565</a></td> <td class="title">Perpetual Contract NFTs as Collateral</td> <td class="author">Hyoungsung Kim (@HyoungsungKim)&nbsp;&lt;<a href="mailto:hyougnsung@keti.re.kr">hyougnsung@keti.re.kr</a>&gt;, Yong-Suk Park&nbsp;&lt;<a href="mailto:yspark@keti.re.kr">yspark@keti.re.kr</a>&gt;, Hyun-Sik Kim&nbsp;&lt;<a href="mailto:hskim@keti.re.kr">hskim@keti.re.kr</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7566">7566</a></td> <td class="title">Multiplayer Game Communication</td> <td class="author">Rickey&nbsp;(<a href="https://github.com/HelloRickey">@HelloRickey</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7572">7572</a></td> <td class="title">Contract-level metadata via `contractURI()`</td> <td class="author">Devin Finzer&nbsp;(<a href="https://github.com/dfinzer">@dfinzer</a>), Alex Atallah&nbsp;(<a href="https://github.com/alexanderatallah">@alexanderatallah</a>), Ryan Ghods&nbsp;(<a href="https://github.com/ryanio">@ryanio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7573">7573</a></td> <td class="title">Conditional-upon-Transfer-Decryption for DvP</td> <td class="author">Christian Fries&nbsp;(<a href="https://github.com/cfries">@cfries</a>), Peter Kohl-Landgraf&nbsp;(<a href="https://github.com/pekola">@pekola</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7579">7579</a></td> <td class="title">Minimal Modular Smart Accounts</td> <td class="author">zeroknots&nbsp;(<a href="https://github.com/zeroknots">@zeroknots</a>), Konrad Kopp&nbsp;(<a href="https://github.com/kopy-kat">@kopy-kat</a>), Taek Lee&nbsp;(<a href="https://github.com/leekt">@leekt</a>), Fil Makarov&nbsp;(<a href="https://github.com/filmakarov">@filmakarov</a>), Elim Poon&nbsp;(<a href="https://github.com/yaonam">@yaonam</a>), Lyu Min&nbsp;(<a href="https://github.com/rockmin216">@rockmin216</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7580">7580</a></td> <td class="title">Advertisement Tracking Interface</td> <td class="author">wart&nbsp;(<a href="https://github.com/wartstone">@wartstone</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7582">7582</a></td> <td class="title">Modular Accounts with Delegated Validation</td> <td class="author">Shivanshi Tyagi&nbsp;(<a href="https://github.com/nerderlyne">@nerderlyne</a>), Ross Campbell&nbsp;(<a href="https://github.com/z0r0z">@z0r0z</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7585">7585</a></td> <td class="title">MixHash and Public Data Storage Proofs</td> <td class="author">Liu Zhicong&nbsp;(<a href="https://github.com/waterflier">@waterflier</a>), William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>), Wei Qiushi&nbsp;(<a href="https://github.com/weiqiushi">@weiqiushi</a>), Si Changjun&nbsp;(<a href="https://github.com/photosssa">@photosssa</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7589">7589</a></td> <td class="title">Semi-Fungible Token Roles</td> <td class="author">Ernani São Thiago&nbsp;(<a href="https://github.com/ernanirst">@ernanirst</a>), Daniel Lima&nbsp;(<a href="https://github.com/karacurt">@karacurt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7595">7595</a></td> <td class="title">Collateralized NFT</td> <td class="author">571nKY&nbsp;(<a href="https://github.com/571nKY">@571nKY</a>), Cosmos&nbsp;(<a href="https://github.com/Cosmos4k">@Cosmos4k</a>), f4t50&nbsp;(<a href="https://github.com/f4t50">@f4t50</a>), Harpocrates&nbsp;(<a href="https://github.com/harpocrates555">@harpocrates555</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7597">7597</a></td> <td class="title">Signature Validation Extension for Permit</td> <td class="author">Yvonne Zhang&nbsp;(<a href="https://github.com/yvonnezhangc">@yvonnezhangc</a>), Aloysius Chan&nbsp;(<a href="https://github.com/circle-aloychan">@circle-aloychan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7598">7598</a></td> <td class="title">Use contract signature for signed transfer</td> <td class="author">Yvonne Zhang&nbsp;(<a href="https://github.com/yvonnezhangc">@yvonnezhangc</a>), Aloysius Chan&nbsp;(<a href="https://github.com/circle-aloychan">@circle-aloychan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7603">7603</a></td> <td class="title">ERC-1155 Multi-Asset extension</td> <td class="author">Haru&nbsp;(<a href="https://github.com/haruu8">@haruu8</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7604">7604</a></td> <td class="title">ERC-1155 Permit Approvals</td> <td class="author">calvbore&nbsp;(<a href="https://github.com/calvbore">@calvbore</a>), emiliolanzalaco&nbsp;(<a href="https://github.com/emiliolanzalaco">@emiliolanzalaco</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7613">7613</a></td> <td class="title">Puppet Proxy Contract</td> <td class="author">Igor Żuk&nbsp;(<a href="https://github.com/CodeSandwich">@CodeSandwich</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7615">7615</a></td> <td class="title">Atomic Push-based Data Feed Among Contracts</td> <td class="author">Elaine Zhang (@lanyinzly)&nbsp;&lt;<a href="mailto:lz8aj@virginia.edu">lz8aj@virginia.edu</a>&gt;, Jerry&nbsp;&lt;<a href="mailto:jerrymindflow@gmail.com">jerrymindflow@gmail.com</a>&gt;, Amandafanny&nbsp;&lt;<a href="mailto:amandafanny200@gmail.com">amandafanny200@gmail.com</a>&gt;, Shouhao Wong (@wangshouh)&nbsp;&lt;<a href="mailto:wongshouhao@outlook.com">wongshouhao@outlook.com</a>&gt;, Doris Che (@Cheyukj)&nbsp;&lt;<a href="mailto:dorischeyy@gmail.com">dorischeyy@gmail.com</a>&gt;, Henry Yuan (@onehumanbeing)&nbsp;&lt;<a href="mailto:hy2878@nyu.edu">hy2878@nyu.edu</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7617">7617</a></td> <td class="title">Chunk support for ERC-5219 mode in Web3 URL</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Nicolas Deschildre&nbsp;(<a href="https://github.com/nand2">@nand2</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7618">7618</a></td> <td class="title">Content encoding in ERC-5219 mode Web3 URL</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Nicolas Deschildre&nbsp;(<a href="https://github.com/nand2">@nand2</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7619">7619</a></td> <td class="title">Precompile Falcon512 generic verifier</td> <td class="author">Erick Pacheco Pedraza&nbsp;(<a href="https://github.com/eum602">@eum602</a>), Marcos Allende&nbsp;&lt;<a href="mailto:mallende@lacnet.com">mallende@lacnet.com</a>&gt;, Diego Lopez León&nbsp;&lt;<a href="mailto:dieguitoll@gmail.com">dieguitoll@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7621">7621</a></td> <td class="title">Basket Token</td> <td class="author">Dominic Ryder&nbsp;&lt;<a href="mailto:dom@alvara.xyz">dom@alvara.xyz</a>&gt;, Michael Ryder&nbsp;&lt;<a href="mailto:mike@alvara.xyz">mike@alvara.xyz</a>&gt;, Callum Mitchell-Clark (@AlvaraProtocol)&nbsp;&lt;<a href="mailto:cal@alvara.xyz">cal@alvara.xyz</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7629">7629</a></td> <td class="title">ERC-20/ERC-721 Unified Token Interface</td> <td class="author">0xZeus1111&nbsp;(<a href="https://github.com/0xZeus1111">@0xZeus1111</a>), Nvuwa&nbsp;(<a href="https://github.com/Nvuwa">@Nvuwa</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7632">7632</a></td> <td class="title">Interfaces for Named Token</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7638">7638</a></td> <td class="title">Batch Calls Encoding in SCA</td> <td class="author">George&nbsp;(<a href="https://github.com/JXRow">@JXRow</a>), Zisu&nbsp;(<a href="https://github.com/lazy1523">@lazy1523</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7641">7641</a></td> <td class="title">Intrinsic RevShare Token</td> <td class="author">Conway&nbsp;(<a href="https://github.com/0x1cc">@0x1cc</a>), Cathie So&nbsp;(<a href="https://github.com/socathie">@socathie</a>), Xiaohang Yu&nbsp;(<a href="https://github.com/xhyumiracle">@xhyumiracle</a>), Suning Yao&nbsp;(<a href="https://github.com/fewwwww">@fewwwww</a>), Kartin&nbsp;&lt;<a href="mailto:kartin@hyperoracle.io">kartin@hyperoracle.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7644">7644</a></td> <td class="title">ERC-721 Name Registry Extension</td> <td class="author">Chen Liaoyuan&nbsp;(<a href="https://github.com/chenly">@chenly</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7649">7649</a></td> <td class="title">Bonding curve-embedded liquidity for NFTs</td> <td class="author">Arif Khan&nbsp;&lt;<a href="mailto:arif@alethea.ai">arif@alethea.ai</a>&gt;, Ahmad Matyana&nbsp;&lt;<a href="mailto:ahmad@alethea.ai">ahmad@alethea.ai</a>&gt;, Basil Gorin&nbsp;(<a href="https://github.com/vgorin">@vgorin</a>), Vijay Bhayani&nbsp;(<a href="https://github.com/unblocktechie">@unblocktechie</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7651">7651</a></td> <td class="title">Fractionally Represented Non-Fungible Token</td> <td class="author">Acme&nbsp;(<a href="https://github.com/0xacme">@0xacme</a>), Calder&nbsp;(<a href="https://github.com/caldereth">@caldereth</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7652">7652</a></td> <td class="title">ERC-721 Guarantee Extension</td> <td class="author">Liu.C.Dao (@CDao)&nbsp;&lt;<a href="mailto:iunknow@163.com">iunknow@163.com</a>&gt;, Sam&nbsp;&lt;<a href="mailto:1047180870@qq.com">1047180870@qq.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7654">7654</a></td> <td class="title">Request Method Types</td> <td class="author">Rickey&nbsp;(<a href="https://github.com/HelloRickey">@HelloRickey</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7662">7662</a></td> <td class="title">AI Agent NFTs</td> <td class="author">Greg Marlin&nbsp;(<a href="https://github.com/marleymarl">@marleymarl</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7679">7679</a></td> <td class="title">UserOperation Builder</td> <td class="author">Derek Chiang&nbsp;(<a href="https://github.com/derekchiang">@derekchiang</a>), Garvit Khatri&nbsp;(<a href="https://github.com/plusminushalf">@plusminushalf</a>), Fil Makarov&nbsp;(<a href="https://github.com/filmakarov">@filmakarov</a>), Kristof Gazso&nbsp;(<a href="https://github.com/kristofgazso">@kristofgazso</a>), Derek Rein&nbsp;(<a href="https://github.com/arein">@arein</a>), Tomas Rocchi&nbsp;(<a href="https://github.com/tomiir">@tomiir</a>), bumblefudge&nbsp;(<a href="https://github.com/bumblefudge">@bumblefudge</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7681">7681</a></td> <td class="title">Dual Nature Multi Token Protocol</td> <td class="author">Sennett Lau&nbsp;(<a href="https://github.com/sennett-lau">@sennett-lau</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7682">7682</a></td> <td class="title">Auxiliary Funds Capability</td> <td class="author">Lukas Rosario&nbsp;(<a href="https://github.com/lukasrosario">@lukasrosario</a>), Wilson Cusack&nbsp;(<a href="https://github.com/wilsoncusack">@wilsoncusack</a>), Alex Donesky&nbsp;(<a href="https://github.com/adonesky1">@adonesky1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7683">7683</a></td> <td class="title">Cross Chain Intents</td> <td class="author">Mark Toda&nbsp;(<a href="https://github.com/marktoda">@marktoda</a>), Matt Rice&nbsp;(<a href="https://github.com/mrice32">@mrice32</a>), Nick Pai&nbsp;(<a href="https://github.com/nicholaspai">@nicholaspai</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7694">7694</a></td> <td class="title">Solana Storage Router</td> <td class="author">Avneet Singh&nbsp;(<a href="https://github.com/sshmatrix">@sshmatrix</a>), 0xc0de4c0ffee&nbsp;(<a href="https://github.com/0xc0de4c0ffee">@0xc0de4c0ffee</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7695">7695</a></td> <td class="title">Ownership Delegation and Context for ERC-721</td> <td class="author">Duc Tho Tran&nbsp;(<a href="https://github.com/ducthotran2010">@ducthotran2010</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7699">7699</a></td> <td class="title">ERC-20 Transfer Reference Extension</td> <td class="author">Radek Svarz&nbsp;(<a href="https://github.com/radeksvarz">@radeksvarz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7700">7700</a></td> <td class="title">Cross-chain Storage Router Protocol</td> <td class="author">Avneet Singh&nbsp;(<a href="https://github.com/sshmatrix">@sshmatrix</a>), 0xc0de4c0ffee&nbsp;(<a href="https://github.com/0xc0de4c0ffee">@0xc0de4c0ffee</a>), Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>), Makoto Inoue&nbsp;(<a href="https://github.com/makoto">@makoto</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7708">7708</a></td> <td class="title">ETH transfers and burns emit a log</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Peter Davies&nbsp;(<a href="https://github.com/petertdavies">@petertdavies</a>), Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Carson&nbsp;(<a href="https://github.com/carsons-eels">@carsons-eels</a>), Jared Wasinger&nbsp;(<a href="https://github.com/jwasinger">@jwasinger</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7710">7710</a></td> <td class="title">Smart Contract Delegation</td> <td class="author">Ryan McPeck&nbsp;(<a href="https://github.com/McOso">@McOso</a>), Dan Finlay&nbsp;(<a href="https://github.com/DanFinlay">@DanFinlay</a>), Rob Dawson&nbsp;(<a href="https://github.com/rojotek">@rojotek</a>), Derek Chiang&nbsp;(<a href="https://github.com/derekchiang">@derekchiang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7715">7715</a></td> <td class="title">Request Permissions from Wallets</td> <td class="author">Luka Isailovic&nbsp;(<a href="https://github.com/lukaisailovic">@lukaisailovic</a>), Derek Rein&nbsp;(<a href="https://github.com/arein">@arein</a>), Dan Finlay&nbsp;(<a href="https://github.com/danfinlay">@danfinlay</a>), Derek Chiang&nbsp;(<a href="https://github.com/derekchiang">@derekchiang</a>), Fil Makarov&nbsp;(<a href="https://github.com/filmakarov">@filmakarov</a>), Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>), Conner Swenberg&nbsp;(<a href="https://github.com/ilikesymmetry">@ilikesymmetry</a>), Lukas Rosario&nbsp;(<a href="https://github.com/lukasrosario">@lukasrosario</a>), Idris Bowman&nbsp;(<a href="https://github.com/V00D00-child">@V00D00-child</a>), Jeff Smale&nbsp;(<a href="https://github.com/jeffsmale90">@jeffsmale90</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7720">7720</a></td> <td class="title">Deferred Token Transfer</td> <td class="author">Chen Liaoyuan (@chenly)&nbsp;&lt;<a href="mailto:cly@kip.pro">cly@kip.pro</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7721">7721</a></td> <td class="title">Lockable Extension for ERC-1155</td> <td class="author">Piyush Chittara&nbsp;(<a href="https://github.com/piyush-chittara">@piyush-chittara</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7722">7722</a></td> <td class="title">Opaque Token</td> <td class="author">Ivica Aračić&nbsp;(<a href="https://github.com/ivica7">@ivica7</a>), Ante Bešlić&nbsp;(<a href="https://github.com/ethSplit">@ethSplit</a>), Mirko Katanić&nbsp;(<a href="https://github.com/mkatanic">@mkatanic</a>), SWIAT</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7726">7726</a></td> <td class="title">Common Quote Oracle</td> <td class="author">alcueca&nbsp;(<a href="https://github.com/alcueca">@alcueca</a>), ruvaag&nbsp;(<a href="https://github.com/ruvaag">@ruvaag</a>), totomanov&nbsp;(<a href="https://github.com/totomanov">@totomanov</a>), r0ohafza&nbsp;(<a href="https://github.com/r0ohafza">@r0ohafza</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7729">7729</a></td> <td class="title">Token with Metadata</td> <td class="author">msfew&nbsp;(<a href="https://github.com/fewwwww">@fewwwww</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7730">7730</a></td> <td class="title">Structured Data Clear Signing Format</td> <td class="author">Laurent Castillo&nbsp;(<a href="https://github.com/lcastillo-ledger">@lcastillo-ledger</a>), Derek Rein&nbsp;(<a href="https://github.com/arein">@arein</a>), Pierre Aoun&nbsp;(<a href="https://github.com/paoun-ledger">@paoun-ledger</a>), Arik Galansky&nbsp;(<a href="https://github.com/arikg">@arikg</a>), Bartosz Rozwarski&nbsp;(<a href="https://github.com/llbartekll">@llbartekll</a>), Kaan Uzdogan&nbsp;(<a href="https://github.com/kuzdogan">@kuzdogan</a>), Fredrik&nbsp;(<a href="https://github.com/Fredrik0x">@Fredrik0x</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7732">7732</a></td> <td class="title">Enshrined Proposer-Builder Separation</td> <td class="author">Francesco D'Amato&nbsp;&lt;<a href="mailto:francesco.damato@ethereum.org">francesco.damato@ethereum.org</a>&gt;, Nico Flaig&nbsp;&lt;<a href="mailto:nflaig@protonmail.com">nflaig@protonmail.com</a>&gt;, Barnabé Monnot&nbsp;&lt;<a href="mailto:barnabe.monnot@ethereum.org">barnabe.monnot@ethereum.org</a>&gt;, Michael Neuder&nbsp;&lt;<a href="mailto:michael.neuder@ethereum.org">michael.neuder@ethereum.org</a>&gt;, Potuz&nbsp;(<a href="https://github.com/potuz">@potuz</a>), Justin Traglia&nbsp;&lt;<a href="mailto:jtraglia@ethereum.org">jtraglia@ethereum.org</a>&gt;, Terence Tsao&nbsp;&lt;<a href="mailto:ttsao@offchainlabs.com">ttsao@offchainlabs.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7738">7738</a></td> <td class="title">Permissionless Script Registry</td> <td class="author">Victor Zhang&nbsp;(<a href="https://github.com/zhangzhongnan928">@zhangzhongnan928</a>), James Brown&nbsp;(<a href="https://github.com/JamesSmartCell">@JamesSmartCell</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7739">7739</a></td> <td class="title">Readable Typed Signatures for Smart Accounts</td> <td class="author">vectorized&nbsp;(<a href="https://github.com/vectorized">@vectorized</a>), Sihoon Lee&nbsp;(<a href="https://github.com/push0ebp">@push0ebp</a>), Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>), Im Juno&nbsp;(<a href="https://github.com/junomonster">@junomonster</a>), howydev&nbsp;(<a href="https://github.com/howydev">@howydev</a>), Atarpara&nbsp;(<a href="https://github.com/Atarpara">@Atarpara</a>), 0xcuriousapple&nbsp;(<a href="https://github.com/0xcuriousapple">@0xcuriousapple</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7741">7741</a></td> <td class="title">Authorize Operator</td> <td class="author">Jeroen Offerijns&nbsp;(<a href="https://github.com/hieronx">@hieronx</a>), João Martins&nbsp;(<a href="https://github.com/0xTimepunk">@0xTimepunk</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7745">7745</a></td> <td class="title">Trustless log and transaction index</td> <td class="author">Zsolt Felföldi&nbsp;(<a href="https://github.com/zsfelfoldi">@zsfelfoldi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7748">7748</a></td> <td class="title">State conversion to Verkle Tree</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Gottfried Herold&nbsp;(<a href="https://github.com/GottfriedHerold">@GottfriedHerold</a>), Jamie Lokier&nbsp;(<a href="https://github.com/jlokier">@jlokier</a>), Tanishq Jasoria&nbsp;(<a href="https://github.com/tanishqjasoria">@tanishqjasoria</a>), Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithosh">@parithosh</a>), Gabriel Rocheleau&nbsp;(<a href="https://github.com/gabrocheleau">@gabrocheleau</a>), Karim Taam&nbsp;(<a href="https://github.com/matkt">@matkt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7749">7749</a></td> <td class="title">Add wallet_signIntendedValidatorData method</td> <td class="author">Yamen Merhi&nbsp;(<a href="https://github.com/YamenMerhi">@YamenMerhi</a>), Patronum Labs&nbsp;(<a href="https://github.com/Patronum-Labs">@Patronum-Labs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7754">7754</a></td> <td class="title">Tamperproof Extension Wallets API (TWIST)</td> <td class="author">Erik Marks&nbsp;(<a href="https://github.com/remarks">@remarks</a>), Guillaume Grosbois&nbsp;(<a href="https://github.com/uni-guillaume">@uni-guillaume</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7760">7760</a></td> <td class="title">Minimal Upgradeable Proxies</td> <td class="author">Atarpara&nbsp;(<a href="https://github.com/Atarpara">@Atarpara</a>), JT Riley&nbsp;(<a href="https://github.com/jtriley-eth">@jtriley-eth</a>), Thomas&nbsp;(<a href="https://github.com/0xth0mas">@0xth0mas</a>), xiaobaiskill&nbsp;(<a href="https://github.com/xiaobaiskill">@xiaobaiskill</a>), Vectorized&nbsp;(<a href="https://github.com/Vectorized">@Vectorized</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7765">7765</a></td> <td class="title">Privileged Non-Fungible Tokens Tied To RWA</td> <td class="author">frank (@frankmint2024)&nbsp;&lt;<a href="mailto:frank@mintchain.io">frank@mintchain.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7766">7766</a></td> <td class="title">Signature Aggregation for ERC-4337</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7769">7769</a></td> <td class="title">JSON-RPC API for ERC-4337</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7770">7770</a></td> <td class="title">Fractional Reserve Token</td> <td class="author">Yaron Velner&nbsp;(<a href="https://github.com/yaronvel">@yaronvel</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7773">7773</a></td> <td class="title">Hardfork Meta - Glamsterdam</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Nixo&nbsp;(<a href="https://github.com/nixorokish">@nixorokish</a>), Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithosh">@parithosh</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7774">7774</a></td> <td class="title">Cache invalidation in ERC-5219 mode Web3 URL</td> <td class="author">Nicolas Deschildre&nbsp;(<a href="https://github.com/nand2">@nand2</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7778">7778</a></td> <td class="title">Block Gas Accounting without Refunds</td> <td class="author">Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7779">7779</a></td> <td class="title">Interoperable Delegated Accounts</td> <td class="author">David Kim&nbsp;(<a href="https://github.com/PowerStream3604">@PowerStream3604</a>), Richard Meissner&nbsp;(<a href="https://github.com/rmeissner">@rmeissner</a>), Akshay Patel&nbsp;(<a href="https://github.com/akshay-ap">@akshay-ap</a>), Joshua Kim&nbsp;(<a href="https://github.com/LightningHun">@LightningHun</a>), Fangting&nbsp;(<a href="https://github.com/trinity-0111">@trinity-0111</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7780">7780</a></td> <td class="title">Validation Module Extension for ERC-7579</td> <td class="author">zeroknots&nbsp;(<a href="https://github.com/zeroknots">@zeroknots</a>), Konrad Kopp&nbsp;(<a href="https://github.com/kopy-kat">@kopy-kat</a>), Taek Lee&nbsp;(<a href="https://github.com/leekt">@leekt</a>), Fil Makarov&nbsp;(<a href="https://github.com/filmakarov">@filmakarov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7782">7782</a></td> <td class="title">Reduce Block Latency</td> <td class="author">Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Maria Inês Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Paul Harris&nbsp;(<a href="https://github.com/rolfyone">@rolfyone</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7785">7785</a></td> <td class="title">Onchain registration of chain identifiers</td> <td class="author">Marco Stronati&nbsp;(<a href="https://github.com/paracetamolo">@paracetamolo</a>), Jeff Lau&nbsp;(<a href="https://github.com/jefflau">@jefflau</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7787">7787</a></td> <td class="title">Soulbound Degradable Governance</td> <td class="author">Guilherme Neves&nbsp;(<a href="https://github.com/0xneves">@0xneves</a>), Rafael Castaneda&nbsp;&lt;<a href="mailto:rafaelcastaneda@gmail.com">rafaelcastaneda@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7791">7791</a></td> <td class="title">GAS2ETH opcode</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), pcaversaccio&nbsp;(<a href="https://github.com/pcaversaccio">@pcaversaccio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7794">7794</a></td> <td class="title">Grant Registry</td> <td class="author">Guilherme Neves&nbsp;(<a href="https://github.com/0xneves">@0xneves</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7795">7795</a></td> <td class="title">Wallet Call Token Capabilities</td> <td class="author">Agustín Aguilar&nbsp;(<a href="https://github.com/agusx1211">@agusx1211</a>), Michael Standen&nbsp;(<a href="https://github.com/ScreamingHawk">@ScreamingHawk</a>), Peter Kieltyka&nbsp;(<a href="https://github.com/pkieltyka">@pkieltyka</a>), William Hua&nbsp;(<a href="https://github.com/attente">@attente</a>), Philippe Castonguay&nbsp;(<a href="https://github.com/PhABC">@PhABC</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7796">7796</a></td> <td class="title">Conditional send transaction RPC</td> <td class="author">Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7799">7799</a></td> <td class="title">System logs</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7801">7801</a></td> <td class="title">etha - Sharded Blocks Subprotocol</td> <td class="author">Ahmad Bitar (@smartprogrammer93)&nbsp;&lt;<a href="mailto:smartprogrammer@windowslive.com">smartprogrammer@windowslive.com</a>&gt;, Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>), Gary Schulte (@garyschulte)&nbsp;&lt;<a href="mailto:garyschulte@gmail.com">garyschulte@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7802">7802</a></td> <td class="title">Token With Mint/Burn Access Across Chains</td> <td class="author">skeletor&nbsp;(<a href="https://github.com/skeletor-spaceman">@skeletor-spaceman</a>), parti&nbsp;(<a href="https://github.com/0xParticle">@0xParticle</a>), joxes&nbsp;(<a href="https://github.com/Joxess">@Joxess</a>), ng&nbsp;(<a href="https://github.com/0xng">@0xng</a>), agus duha&nbsp;(<a href="https://github.com/agusduha">@agusduha</a>), disco&nbsp;(<a href="https://github.com/0xDiscotech">@0xDiscotech</a>), gotzen&nbsp;&lt;<a href="mailto:gotzen@defi.sucks">gotzen@defi.sucks</a>&gt;, 0age&nbsp;&lt;<a href="mailto:0age@uniswap.org">0age@uniswap.org</a>&gt;, Mark Tyneway&nbsp;&lt;<a href="mailto:mark@oplabs.co">mark@oplabs.co</a>&gt;, Zain Bacchus&nbsp;&lt;<a href="mailto:zain@oplabs.co">zain@oplabs.co</a>&gt;, Matt Solomon&nbsp;&lt;<a href="mailto:msolomon@oplabs.co">msolomon@oplabs.co</a>&gt;, Maurelian&nbsp;&lt;<a href="mailto:maurelian@protonmail.ch">maurelian@protonmail.ch</a>&gt;, Blaine Malone&nbsp;(<a href="https://github.com/blmalone">@blmalone</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7803">7803</a></td> <td class="title">EIP-712 Extensions for Account Abstraction</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7804">7804</a></td> <td class="title">Withdrawal Credential Update Request</td> <td class="author">Lucas Saldanha&nbsp;(<a href="https://github.com/lucassaldanha">@lucassaldanha</a>), Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7805">7805</a></td> <td class="title">Fork-choice enforced Inclusion Lists (FOCIL)</td> <td class="author">Thomas Thiery (@soispoke)&nbsp;&lt;<a href="mailto:thomas.thiery@ethereum.org">thomas.thiery@ethereum.org</a>&gt;, Francesco D'Amato&nbsp;&lt;<a href="mailto:francesco.damato@ethereum.org">francesco.damato@ethereum.org</a>&gt;, Julian Ma&nbsp;&lt;<a href="mailto:julian.ma@ethereum.org">julian.ma@ethereum.org</a>&gt;, Barnabé Monnot&nbsp;&lt;<a href="mailto:barnabe.monnot@ethereum.org">barnabe.monnot@ethereum.org</a>&gt;, Terence Tsao&nbsp;&lt;<a href="mailto:ttsao@offchainlabs.com">ttsao@offchainlabs.com</a>&gt;, Jacob Kaufmann&nbsp;&lt;<a href="mailto:jacob.kaufmann@ethereum.org">jacob.kaufmann@ethereum.org</a>&gt;, Jihoon Song&nbsp;&lt;<a href="mailto:jihoon.song@ethereum.org">jihoon.song@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7806">7806</a></td> <td class="title">Minimal intent-centric EOA smart account</td> <td class="author">hellohanchen&nbsp;(<a href="https://github.com/hellohanchen">@hellohanchen</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7807">7807</a></td> <td class="title">SSZ execution blocks</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7811">7811</a></td> <td class="title">Wallet Asset Discovery</td> <td class="author">Luka Isailovic&nbsp;(<a href="https://github.com/lukaisailovic">@lukaisailovic</a>), Konrad Kopp&nbsp;(<a href="https://github.com/kopy-kat">@kopy-kat</a>), Derek Rein&nbsp;(<a href="https://github.com/arein">@arein</a>), Chris Smith&nbsp;(<a href="https://github.com/chris13524">@chris13524</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7819">7819</a></td> <td class="title">SETDELEGATE instruction</td> <td class="author">Hadrien Croubois&nbsp;(<a href="https://github.com/amxx">@amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7821">7821</a></td> <td class="title">Minimal Batch Executor Interface</td> <td class="author">Vectorized&nbsp;(<a href="https://github.com/Vectorized">@Vectorized</a>), Jake Moxey&nbsp;(<a href="https://github.com/jxom">@jxom</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7827">7827</a></td> <td class="title">JSON Contract with Value Version Control</td> <td class="author">lex-clinic&nbsp;(<a href="https://github.com/lex-clinic">@lex-clinic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7831">7831</a></td> <td class="title">Multi-Chain Addressing</td> <td class="author">Sam Wilson (@SamWilsn)&nbsp;&lt;<a href="mailto:sam@binarycake.ca">sam@binarycake.ca</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7836">7836</a></td> <td class="title">Wallet Call Preparation API</td> <td class="author">Lukas Rosario&nbsp;(<a href="https://github.com/lukasrosario">@lukasrosario</a>), Conner Swenberg&nbsp;(<a href="https://github.com/ilikesymmetry">@ilikesymmetry</a>), Adam Hodges&nbsp;(<a href="https://github.com/ajhodges">@ajhodges</a>), Paaras Bhandari&nbsp;(<a href="https://github.com/paarasbhandari">@paarasbhandari</a>), Jake Moxey&nbsp;(<a href="https://github.com/jxom">@jxom</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7841">7841</a></td> <td class="title">Cross-chain Message Format and Mailbox</td> <td class="author">Ellie Davidson&nbsp;(<a href="https://github.com/elliedavidson">@elliedavidson</a>), Alex Xiong&nbsp;(<a href="https://github.com/alxiong">@alxiong</a>), Philippe Camacho&nbsp;(<a href="https://github.com/philippecamacho">@philippecamacho</a>), and Ben Fisch&nbsp;(<a href="https://github.com/benafisch">@benafisch</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7843">7843</a></td> <td class="title">SLOTNUM opcode</td> <td class="author">Marc Harvey-Hill&nbsp;(<a href="https://github.com/Marchhill">@Marchhill</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7845">7845</a></td> <td class="title">Universal Orchestrator RPC</td> <td class="author">Kieran Goodary&nbsp;(<a href="https://github.com/IAmKio">@IAmKio</a>), Pillar Wallet&nbsp;(<a href="https://github.com/pillarwallet">@pillarwallet</a>), Luke Wickens&nbsp;(<a href="https://github.com/lbw33">@lbw33</a>), Rana Khoury&nbsp;(<a href="https://github.com/RanaBug">@RanaBug</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7846">7846</a></td> <td class="title">Wallet Connection API</td> <td class="author">Conner Swenberg&nbsp;(<a href="https://github.com/ilikesymmetry">@ilikesymmetry</a>), Jake Moxey&nbsp;(<a href="https://github.com/jxom">@jxom</a>), Lukas Rosario&nbsp;(<a href="https://github.com/lukasrosario">@lukasrosario</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7847">7847</a></td> <td class="title">Social Media NFTs</td> <td class="author">Nick Juntilla (@nickjuntilla)&nbsp;&lt;<a href="mailto:nick@ownerfy.com">nick@ownerfy.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7848">7848</a></td> <td class="title">On-chain upgrade signaling</td> <td class="author">William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7851">7851</a></td> <td class="title">Deactivate a Delegated EOA&apos;s Key</td> <td class="author">Liyi Guo&nbsp;(<a href="https://github.com/colinlyguo">@colinlyguo</a>), Nicolas Consigny&nbsp;(<a href="https://github.com/nconsigny">@nconsigny</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7856">7856</a></td> <td class="title">Chain-Specific Payment Requests</td> <td class="author">Jack Chuma&nbsp;(<a href="https://github.com/jackchuma">@jackchuma</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7861">7861</a></td> <td class="title">ERC-721 Verifiable Credential Extension</td> <td class="author">Valerio Massimo Camaiani&nbsp;(<a href="https://github.com/vmc-crossmint">@vmc-crossmint</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7862">7862</a></td> <td class="title">Delayed State Root</td> <td class="author">Charlie Noyes&nbsp;&lt;<a href="mailto:charlie@paradigm.xyz">charlie@paradigm.xyz</a>&gt;, Dan Robinson&nbsp;&lt;<a href="mailto:dan@paradigm.xyz">dan@paradigm.xyz</a>&gt;, Justin Drake&nbsp;&lt;<a href="mailto:justin@ethereum.org">justin@ethereum.org</a>&gt;, Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7863">7863</a></td> <td class="title">Block-level Warming</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7864">7864</a></td> <td class="title">Ethereum state using a unified binary tree</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>), Tanishq Jasoria&nbsp;(<a href="https://github.com/tanishqjasoria">@tanishqjasoria</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>), Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>), Gottfried Herold&nbsp;(<a href="https://github.com/GottfriedHerold">@GottfriedHerold</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7871">7871</a></td> <td class="title">Wallet Signing API</td> <td class="author">Lukas Rosario&nbsp;(<a href="https://github.com/lukasrosario">@lukasrosario</a>), Jake Moxey&nbsp;(<a href="https://github.com/jxom">@jxom</a>), Cody Crozier&nbsp;(<a href="https://github.com/wcrozier12">@wcrozier12</a>), Conner Swenberg&nbsp;(<a href="https://github.com/ilikesymmetry">@ilikesymmetry</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7876">7876</a></td> <td class="title">Ethereum Network Configuration for DApps</td> <td class="author">Bogdan Gusiev&nbsp;(<a href="https://github.com/bogdan">@bogdan</a>), Sergey Bomko&nbsp;(<a href="https://github.com/aquiladev">@aquiladev</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7884">7884</a></td> <td class="title">Operation Router</td> <td class="author">Lucas Picollo&nbsp;(<a href="https://github.com/pikonha">@pikonha</a>), Alex Netto&nbsp;(<a href="https://github.com/alextnetto">@alextnetto</a>), Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7885">7885</a></td> <td class="title">Precompile for NTT operations</td> <td class="author">Renaud Dubois&nbsp;(<a href="https://github.com/rdubois-crypto">@rdubois-crypto</a>), Simon Masson&nbsp;(<a href="https://github.com/simonmasson">@simonmasson</a>), Yoon Hyoung Lee&nbsp;(<a href="https://github.com/yhl125">@yhl125</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7887">7887</a></td> <td class="title">Cancelation for ERC-7540 Tokenized Vaults</td> <td class="author">Jeroen Offerijns&nbsp;(<a href="https://github.com/hieronx">@hieronx</a>), Vikram Arun&nbsp;(<a href="https://github.com/vikramarun">@vikramarun</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7888">7888</a></td> <td class="title">Crosschain Broadcaster</td> <td class="author">Henry Arneson&nbsp;(<a href="https://github.com/godzillaba">@godzillaba</a>), Chris Buckland&nbsp;(<a href="https://github.com/yahgwai">@yahgwai</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7891">7891</a></td> <td class="title">Splitting and Merging of NFTs</td> <td class="author">Nitin Bhagat (@nitin312)&nbsp;&lt;<a href="mailto:bhagatnitin312@gmail.com">bhagatnitin312@gmail.com</a>&gt;, JongWook Bae&nbsp;&lt;<a href="mailto:bae@cwnu.ac.kr">bae@cwnu.ac.kr</a>&gt;, Su-Hyun Lee&nbsp;&lt;<a href="mailto:sleepl@changwon.ac.kr">sleepl@changwon.ac.kr</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7895">7895</a></td> <td class="title">API for Hierarchical Accounts</td> <td class="author">Wilson Cusack&nbsp;(<a href="https://github.com/wilsoncusack">@wilsoncusack</a>), Jake Feldman&nbsp;(<a href="https://github.com/jakefeldman">@jakefeldman</a>), Montana Wong&nbsp;(<a href="https://github.com/montycheese">@montycheese</a>), Felix Zhang&nbsp;(<a href="https://github.com/fan-zhang-sv">@fan-zhang-sv</a>), Jake Moxey&nbsp;(<a href="https://github.com/jxom">@jxom</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7902">7902</a></td> <td class="title">Wallet Capabilities for Account Abstraction</td> <td class="author">Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7904">7904</a></td> <td class="title">Compute Gas Cost Increase</td> <td class="author">Jacek Glen&nbsp;(<a href="https://github.com/JacekGlen">@JacekGlen</a>), Lukasz Glen&nbsp;(<a href="https://github.com/lukasz-glen">@lukasz-glen</a>), Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7906">7906</a></td> <td class="title">Transaction Assertions via State Diff Opcode</td> <td class="author">Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7907">7907</a></td> <td class="title">Meter Contract Code Size And Increase Limit</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Matt&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Dragan Rakita&nbsp;(<a href="https://github.com/rakita">@rakita</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7911">7911</a></td> <td class="title">Scaling Ethereum with a Perceptron Tree ZKP</td> <td class="author">Ryo Ha (@sopia19910)&nbsp;&lt;<a href="mailto:sopia19910@gmail.com">sopia19910@gmail.com</a>&gt;, Khajiev Nizomjon (@khajievN)&nbsp;&lt;<a href="mailto:nizom7812@gmail.com">nizom7812@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7920">7920</a></td> <td class="title">Composite EIP-712 Signatures</td> <td class="author">Sola Ogunsakin&nbsp;(<a href="https://github.com/sola92">@sola92</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7923">7923</a></td> <td class="title">Linear, Page-Based Memory Costing</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7928">7928</a></td> <td class="title">Block-Level Access Lists</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Francesco D`Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Felipe Selmo&nbsp;(<a href="https://github.com/fselmo">@fselmo</a>), Rahul&nbsp;(<a href="https://github.com/raxhvl">@raxhvl</a>), Stefan&nbsp;(<a href="https://github.com/qu0b">@qu0b</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7929">7929</a></td> <td class="title">PermaLink Asset Bound Token</td> <td class="author">Mihai Onila&nbsp;(<a href="https://github.com/MihaiORO">@MihaiORO</a>), Nick Zeman&nbsp;(<a href="https://github.com/NickZCZ">@NickZCZ</a>), Narcis Cotaie&nbsp;(<a href="https://github.com/NarcisCRO">@NarcisCRO</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7932">7932</a></td> <td class="title">Secondary Signature Algorithms</td> <td class="author">James Kempton&nbsp;(<a href="https://github.com/SirSpudlington">@SirSpudlington</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7937">7937</a></td> <td class="title">EVM64 - 64-bit mode EVM opcodes</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7940">7940</a></td> <td class="title">Ethereum Shah</td> <td class="author">Ameen Soleimani&nbsp;(<a href="https://github.com/ameensol">@ameensol</a>), Gregory Markou</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7942">7942</a></td> <td class="title">Available Attestation</td> <td class="author">Mingfei Zhang (@Mart1i1n)&nbsp;&lt;<a href="mailto:mingfei.zh@outlook.com">mingfei.zh@outlook.com</a>&gt;, Rujia Li&nbsp;&lt;<a href="mailto:rujia@tsinghua.edu.cn">rujia@tsinghua.edu.cn</a>&gt;, Xueqian Lu&nbsp;&lt;<a href="mailto:xueqian.lu@bitheart.org">xueqian.lu@bitheart.org</a>&gt;, Sisi Duan&nbsp;&lt;<a href="mailto:duansisi@tsinghua.edu.cn">duansisi@tsinghua.edu.cn</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7946">7946</a></td> <td class="title">Unidirectional Wallet Uplink aka UWULink</td> <td class="author">Moody Salem&nbsp;(<a href="https://github.com/moodysalem">@moodysalem</a>), Tina Zheng&nbsp;(<a href="https://github.com/tinaszheng">@tinaszheng</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7947">7947</a></td> <td class="title">Account Abstraction Recovery Interface</td> <td class="author">Artem Chystiakov (@arvolear)&nbsp;&lt;<a href="mailto:artem@rarilabs.com">artem@rarilabs.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7949">7949</a></td> <td class="title">Genesis File Format</td> <td class="author">Justin Florentine (@jflo)&nbsp;&lt;<a href="mailto:justin@florentine.us">justin@florentine.us</a>&gt;, Jochem Brouwer (@jochem-brouwer)&nbsp;&lt;<a href="mailto:jochem@ethereum.org">jochem@ethereum.org</a>&gt;, Barnabas Busa (@barnabasbusa)&nbsp;&lt;<a href="mailto:bbusa@ethereum.org">bbusa@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7954">7954</a></td> <td class="title">Increase Maximum Contract Size</td> <td class="author">Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7955">7955</a></td> <td class="title">Permissionless CREATE2 Factory</td> <td class="author">Nicholas Rodrigues Lordello&nbsp;(<a href="https://github.com/nlordell">@nlordell</a>), Richard Meissner&nbsp;(<a href="https://github.com/rmeissner">@rmeissner</a>), Valentin Seehausen&nbsp;(<a href="https://github.com/vseehausen">@vseehausen</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7960">7960</a></td> <td class="title">EOF - Extended types section</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7961">7961</a></td> <td class="title">EVM64 - EOF code section</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7962">7962</a></td> <td class="title">Key Hash Based Tokens</td> <td class="author">Alex Tian&nbsp;(<a href="https://github.com/dugubuyan">@dugubuyan</a>), Zhixiong Pan&nbsp;(<a href="https://github.com/nake13">@nake13</a>), Geoffrey (@stbrahms)&nbsp;&lt;<a href="mailto:geoffrey@datadance.ai">geoffrey@datadance.ai</a>&gt;, liyingxuan (@LiYingxuan)&nbsp;&lt;<a href="mailto:liyingxuan@datadance.ai">liyingxuan@datadance.ai</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7964">7964</a></td> <td class="title">Crosschain EIP-712 Signatures</td> <td class="author">Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7965">7965</a></td> <td class="title">Proof-based Broadcast in ERC-7786 Gateways</td> <td class="author">Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7966">7966</a></td> <td class="title">eth_sendRawTransactionSync Method</td> <td class="author">Sam Battenally&nbsp;(<a href="https://github.com/SmoothBot">@SmoothBot</a>), Hai Nguyen&nbsp;(<a href="https://github.com/hai-rise">@hai-rise</a>), Thanh Nguyen&nbsp;(<a href="https://github.com/LampardNguyen234">@LampardNguyen234</a>), Loc Nguyen&nbsp;(<a href="https://github.com/silver-rise">@silver-rise</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7968">7968</a></td> <td class="title">Owner-Authorized Token Transfer Protocol</td> <td class="author">Julius Lauterbach&nbsp;(<a href="https://github.com/Julius278">@Julius278</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7969">7969</a></td> <td class="title">DomainKeys Identified Mail (DKIM) Registry</td> <td class="author">Mike Fu&nbsp;(<a href="https://github.com/fumeng00mike">@fumeng00mike</a>), Matthew Yu&nbsp;(<a href="https://github.com/0xknon">@0xknon</a>), Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7971">7971</a></td> <td class="title">Hard Limits for Transient Storage</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7973">7973</a></td> <td class="title">Warm Account Write Metering</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7975">7975</a></td> <td class="title">eth/70 - partial block receipt lists</td> <td class="author">Felix Lange&nbsp;&lt;<a href="mailto:fjl@ethereum.org">fjl@ethereum.org</a>&gt;, Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7976">7976</a></td> <td class="title">Increase Calldata Floor Cost</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7979">7979</a></td> <td class="title">Call and Return Opcodes for the EVM</td> <td class="author">Greg Colvin&nbsp;(<a href="https://github.com/gcolvin">@gcolvin</a>), Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), Brooklyn Zelenka&nbsp;(<a href="https://github.com/expede">@expede</a>), John Max Skaller&nbsp;&lt;<a href="mailto:skaller@internode.on.net">skaller@internode.on.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7981">7981</a></td> <td class="title">Increase Access List Cost</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7984">7984</a></td> <td class="title">Confidential Fungible Token</td> <td class="author">Aryeh Greenberg&nbsp;(<a href="https://github.com/arr00">@arr00</a>), Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>), Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Ghazi Ben Amor&nbsp;(<a href="https://github.com/GBAZama">@GBAZama</a>), Clement Danjou&nbsp;(<a href="https://github.com/immortal-tofu">@immortal-tofu</a>), Joseph Andre Turk&nbsp;(<a href="https://github.com/jatZama">@jatZama</a>), Silas Davis&nbsp;(<a href="https://github.com/silasdavis">@silasdavis</a>), Nicolas Pasquier&nbsp;(<a href="https://github.com/npasquie">@npasquie</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7985">7985</a></td> <td class="title">Gateway Attributes for Message Control</td> <td class="author">Ernesto García&nbsp;(<a href="https://github.com/ernestognw">@ernestognw</a>), Kalman Lajko&nbsp;(<a href="https://github.com/LajkoKalman">@LajkoKalman</a>), Valera Grinenko&nbsp;(<a href="https://github.com/0xValera">@0xValera</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7988">7988</a></td> <td class="title">Minimal Avatar Smart Wallet (MASW)</td> <td class="author">0xMostafas (@MostafaS)&nbsp;&lt;<a href="mailto:0xmostafas@proton.me">0xmostafas@proton.me</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7992">7992</a></td> <td class="title">Verifiable ML Model Inference (ZKML)</td> <td class="author">Aryaethn&nbsp;(<a href="https://github.com/aryaethn">@aryaethn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7996">7996</a></td> <td class="title">Contract Feature Detection</td> <td class="author">raffy.eth&nbsp;(<a href="https://github.com/adraffy">@adraffy</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7997">7997</a></td> <td class="title">Deterministic Factory Predeploy</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7998">7998</a></td> <td class="title">Turn `randao_reveal` into a VRF</td> <td class="author">Alberto La Rocca&nbsp;(<a href="https://github.com/71104">@71104</a>), Aryaethn&nbsp;(<a href="https://github.com/aryaethn">@aryaethn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7999">7999</a></td> <td class="title">Unified multidimensional fee market</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8000">8000</a></td> <td class="title">Operator contract for non delegated EOAs</td> <td class="author">Marcelo Morgado&nbsp;(<a href="https://github.com/marcelomorgado">@marcelomorgado</a>), Manoj Patidar&nbsp;(<a href="https://github.com/patidarmanoj10">@patidarmanoj10</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8002">8002</a></td> <td class="title">Simplified Payment Verification Gateway</td> <td class="author">Artem Chystiakov&nbsp;(<a href="https://github.com/arvolear">@arvolear</a>), Oleh Komendant&nbsp;(<a href="https://github.com/Hrom131">@Hrom131</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8004">8004</a></td> <td class="title">Trustless Agents</td> <td class="author">Marco De Rossi&nbsp;(<a href="https://github.com/MarcoMetaMask">@MarcoMetaMask</a>), Davide Crapis (@dcrapis)&nbsp;&lt;<a href="mailto:davide@ethereum.org">davide@ethereum.org</a>&gt;, Jordan Ellis&nbsp;&lt;<a href="mailto:jordanellis@google.com">jordanellis@google.com</a>&gt;, Erik Reppel&nbsp;&lt;<a href="mailto:erik.reppel@coinbase.com">erik.reppel@coinbase.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8007">8007</a></td> <td class="title">Glamsterdam Gas Repricings</td> <td class="author">Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8011">8011</a></td> <td class="title">Multidimensional Gas Metering</td> <td class="author">Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Davide Crapis&nbsp;(<a href="https://github.com/dcrapis">@dcrapis</a>), Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8013">8013</a></td> <td class="title">Static relative jumps and calls for the EVM</td> <td class="author">Greg Colvin&nbsp;(<a href="https://github.com/gcolvin">@gcolvin</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8016">8016</a></td> <td class="title">SSZ CompatibleUnion</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Cayman&nbsp;(<a href="https://github.com/wemeetagain">@wemeetagain</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8017">8017</a></td> <td class="title">Payout Race</td> <td class="author">Kyle Thornton (@kyle)&nbsp;&lt;<a href="mailto:kyle@cowrie.io">kyle@cowrie.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8023">8023</a></td> <td class="title">Multi-step Contract Ownership</td> <td class="author">David Kim&nbsp;(<a href="https://github.com/PowerStream3604">@PowerStream3604</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8030">8030</a></td> <td class="title">P256 algorithm support</td> <td class="author">James Kempton&nbsp;(<a href="https://github.com/SirSpudlington">@SirSpudlington</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8032">8032</a></td> <td class="title">Size-Based Storage Gas Pricing</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Carlos Perez&nbsp;(<a href="https://github.com/CPerezz">@CPerezz</a>), Matan Prasma&nbsp;(<a href="https://github.com/KanExtension">@KanExtension</a>), Wei Han Ng&nbsp;(<a href="https://github.com/weiihann">@weiihann</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8033">8033</a></td> <td class="title">Agent Council Oracles</td> <td class="author">Rohan Parikh&nbsp;(<a href="https://github.com/phiraml">@phiraml</a>), Jon Michael Ross&nbsp;(<a href="https://github.com/jonmross">@jonmross</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8037">8037</a></td> <td class="title">State Creation Gas Cost Increase</td> <td class="author">Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Carlos Perez&nbsp;(<a href="https://github.com/CPerezz">@CPerezz</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Łukasz Rozmej&nbsp;(<a href="https://github.com/LukaszRozmej">@LukaszRozmej</a>), Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8038">8038</a></td> <td class="title">State-access gas cost update</td> <td class="author">Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Wei Han Ng&nbsp;(<a href="https://github.com/weiihann">@weiihann</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8041">8041</a></td> <td class="title">Fixed-Supply Agent NFT Collections</td> <td class="author">Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8045">8045</a></td> <td class="title">Exclude slashed validators from proposing</td> <td class="author">Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Barnabas Busa&nbsp;(<a href="https://github.com/barnabasbusa">@barnabasbusa</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8046">8046</a></td> <td class="title">Uniform price auction over inclusion lists</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8048">8048</a></td> <td class="title">Onchain Metadata for Token Registries</td> <td class="author">Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>), Rafael Abuawad&nbsp;(<a href="https://github.com/rafael-abuawad">@rafael-abuawad</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8049">8049</a></td> <td class="title">Contract-Level Onchain Metadata</td> <td class="author">Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>), Rafael Abuawad&nbsp;(<a href="https://github.com/rafael-abuawad">@rafael-abuawad</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8051">8051</a></td> <td class="title">Precompile for ML-DSA signature verification</td> <td class="author">Renaud Dubois&nbsp;(<a href="https://github.com/rdubois-crypto">@rdubois-crypto</a>), Simon Masson&nbsp;(<a href="https://github.com/simonmasson">@simonmasson</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8052">8052</a></td> <td class="title">Precompile for Falcon support</td> <td class="author">Renaud Dubois&nbsp;(<a href="https://github.com/rdubois-crypto">@rdubois-crypto</a>), Simon Masson&nbsp;(<a href="https://github.com/simonmasson">@simonmasson</a>), Antonio Sanso&nbsp;(<a href="https://github.com/asanso">@asanso</a>), Marius van der Wijden&nbsp;(<a href="https://github.com/mariusvanderwijden">@mariusvanderwijden</a>), Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>), Zhenfei Zhang&nbsp;(<a href="https://github.com/zhenfeizhang">@zhenfeizhang</a>), Nicolas Consigny&nbsp;(<a href="https://github.com/nconsigny">@nconsigny</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8053">8053</a></td> <td class="title">Milli-gas for High-precision Gas Metering</td> <td class="author">Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8056">8056</a></td> <td class="title">Scaled UI Amount Extension for ERC-20 Tokens</td> <td class="author">Chris Ridmann (@cridmann)&nbsp;&lt;<a href="mailto:chris@superstate.co">chris@superstate.co</a>&gt;, Daniel Gretzke&nbsp;(<a href="https://github.com/gretzke">@gretzke</a>), Gilbert Shih&nbsp;&lt;<a href="mailto:chung.shih@robinhood.com">chung.shih@robinhood.com</a>&gt;, Tino Martinez Molina&nbsp;(<a href="https://github.com/tinom9">@tinom9</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8057">8057</a></td> <td class="title">Inter-Block Temporal Locality Gas Discounts</td> <td class="author">Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Maria Inês Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Amirul Ashraf&nbsp;(<a href="https://github.com/asdacap">@asdacap</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8058">8058</a></td> <td class="title">Contract Bytecode Deduplication Discount</td> <td class="author">Carlos Perez&nbsp;(<a href="https://github.com/CPerezz">@CPerezz</a>), Wei Han Ng&nbsp;(<a href="https://github.com/weiihann">@weiihann</a>), Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8059">8059</a></td> <td class="title">Gas Units Rebase for High-precision Metering</td> <td class="author">Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8061">8061</a></td> <td class="title">Increase exit and consolidation churn</td> <td class="author">Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8062">8062</a></td> <td class="title">Add sweep withdrawal fee for 0x01 validators</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Maria Inês Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8065">8065</a></td> <td class="title">Zero Knowledge Token Wrapper</td> <td class="author">Jiahui Cui&nbsp;(<a href="https://github.com/doublespending">@doublespending</a>), 0xZPL&nbsp;(<a href="https://github.com/0xZPL">@0xZPL</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8066">8066</a></td> <td class="title">Upgrade Mascots</td> <td class="author">Jordan Holberg&nbsp;(<a href="https://github.com/eviljordan">@eviljordan</a>), Andrew B Coathup&nbsp;(<a href="https://github.com/abcoathup">@abcoathup</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8068">8068</a></td> <td class="title">Neutral effective balance design</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8070">8070</a></td> <td class="title">eth/72 - Sparse Blobpool</td> <td class="author">Raúl Kripalani&nbsp;(<a href="https://github.com/raulk">@raulk</a>), Bosul Mun&nbsp;(<a href="https://github.com/healthykim">@healthykim</a>), Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Csaba Kiraly&nbsp;(<a href="https://github.com/cskiraly">@cskiraly</a>), Felix Lange&nbsp;(<a href="https://github.com/fjl">@fjl</a>), Marios Ioannou&nbsp;(<a href="https://github.com/mariosioannou-create">@mariosioannou-create</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8071">8071</a></td> <td class="title">Prevent using consolidations as withdrawals</td> <td class="author">Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>), Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8072">8072</a></td> <td class="title">Transaction Inclusion Subscription</td> <td class="author">Łukasz Rozmej&nbsp;(<a href="https://github.com/LukaszRozmej">@LukaszRozmej</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8074">8074</a></td> <td class="title">Self-Describing Bytes via EIP-712 Selectors</td> <td class="author">Andrew Richardson&nbsp;(<a href="https://github.com/awrichar">@awrichar</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8075">8075</a></td> <td class="title">Adaptive state cost to cap growth &amp; scale L1</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8077">8077</a></td> <td class="title">eth/XX - announce transactions with nonce</td> <td class="author">Csaba Kiraly&nbsp;(<a href="https://github.com/cskiraly">@cskiraly</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8079">8079</a></td> <td class="title">Native rollups</td> <td class="author">Luca Donno (@lucadonnoh)&nbsp;&lt;<a href="mailto:donnoh@l2beat.com">donnoh@l2beat.com</a>&gt;, Justin Drake (@JustinDrake)&nbsp;&lt;<a href="mailto:justin@ethereum.org">justin@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8080">8080</a></td> <td class="title">Let exits use the consolidation queue</td> <td class="author">Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8081">8081</a></td> <td class="title">Hardfork Meta - Hegotá</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Nixo&nbsp;(<a href="https://github.com/nixorokish">@nixorokish</a>), Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithosh">@parithosh</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8092">8092</a></td> <td class="title">Associated Accounts</td> <td class="author">Steve Katzman&nbsp;(<a href="https://github.com/stevieraykatz">@stevieraykatz</a>), Amie Corso&nbsp;(<a href="https://github.com/amiecorso">@amiecorso</a>), Stephan Cilliers&nbsp;(<a href="https://github.com/stephancill">@stephancill</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8094">8094</a></td> <td class="title">eth/vhash - Blob-Aware Mempool</td> <td class="author">Csaba Kiraly&nbsp;(<a href="https://github.com/cskiraly">@cskiraly</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8096">8096</a></td> <td class="title">Increase Gas Cost of Point Evaluation</td> <td class="author">Marcin Sobczak&nbsp;(<a href="https://github.com/marcindsobczak">@marcindsobczak</a>), Kamil Chodoła&nbsp;(<a href="https://github.com/kamilchodola">@kamilchodola</a>), Marek Moraczyński&nbsp;(<a href="https://github.com/MarekM25">@MarekM25</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8099">8099</a></td> <td class="title">MEVless Protocol</td> <td class="author">Lawliet Chan&nbsp;(<a href="https://github.com/lawliet-chan">@lawliet-chan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8101">8101</a></td> <td class="title">Payload Chunking with Chunk Access Lists</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Milos Stankovic&nbsp;(<a href="https://github.com/morph-dev">@morph-dev</a>), Jihoon Song&nbsp;(<a href="https://github.com/jihoonsong">@jihoonsong</a>), Bharath Vedartham&nbsp;(<a href="https://github.com/bharath-123">@bharath-123</a>), Raúl Kripalani&nbsp;(<a href="https://github.com/raulk">@raulk</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8105">8105</a></td> <td class="title">Universal Enshrined Encrypted Mempool</td> <td class="author">Jannik Luhn&nbsp;(<a href="https://github.com/jannikluhn">@jannikluhn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8106">8106</a></td> <td class="title">RWA Event-based Compliance Framework</td> <td class="author">Andrew Wang (@wz14)&nbsp;&lt;<a href="mailto:zhuowangy2k@outlook.com">zhuowangy2k@outlook.com</a>&gt;, Jack Yin (@0xjackey)&nbsp;&lt;<a href="mailto:0xjackey@gmail.com">0xjackey@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8107">8107</a></td> <td class="title">ENS Trust Registry for Agent Coordination</td> <td class="author">Kwame Bryan&nbsp;(<a href="https://github.com/KBryan">@KBryan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8110">8110</a></td> <td class="title">Domain Architecture for Diamonds</td> <td class="author">Hoang&nbsp;(<a href="https://github.com/0x76agabond">@0x76agabond</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8113">8113</a></td> <td class="title">Series Accounting for Incentivized Vaults</td> <td class="author">Yash Saraswat&nbsp;(<a href="https://github.com/0xpanicError">@0xpanicError</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8115">8115</a></td> <td class="title">Batch priority fees at end of block</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8116">8116</a></td> <td class="title">Replace cumulative receipt fields</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8117">8117</a></td> <td class="title">Anti-Poisoning Compact EVM Address Format</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8119">8119</a></td> <td class="title">Parameterized Storage Keys</td> <td class="author">Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8120">8120</a></td> <td class="title">MLOAD8 and CALLDATALOAD8 Opcodes</td> <td class="author">Helkomine&nbsp;(<a href="https://github.com/Helkomine">@Helkomine</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8121">8121</a></td> <td class="title">Cross-Chain Function Calls via Hooks</td> <td class="author">Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8122">8122</a></td> <td class="title">Minimal Agent Registry</td> <td class="author">Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8123">8123</a></td> <td class="title">RPC Method for Transaction Gas Limit Cap</td> <td class="author">Paul Razvan Berg&nbsp;(<a href="https://github.com/PaulRBerg">@PaulRBerg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8125">8125</a></td> <td class="title">Temporary Contract Storage</td> <td class="author">Wei Han Ng&nbsp;(<a href="https://github.com/weiihann">@weiihann</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8127">8127</a></td> <td class="title">Human Readable Token Identifiers</td> <td class="author">Prem Makeig&nbsp;(<a href="https://github.com/nxt3d">@nxt3d</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8130">8130</a></td> <td class="title">Account Abstraction by Account Configuration</td> <td class="author">Chris Hunter (@chunter-cb)&nbsp;&lt;<a href="mailto:chris.hunter@coinbase.com">chris.hunter@coinbase.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8131">8131</a></td> <td class="title">Add Auth Data to EIP-7623 Floor</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8133">8133</a></td> <td class="title">Upgrade Nomenclature</td> <td class="author">Pooja Ranjan&nbsp;(<a href="https://github.com/poojaranjan">@poojaranjan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8136">8136</a></td> <td class="title">Cell-Level Deltas for Data Column Broadcast</td> <td class="author">Marco Munizaga (@MarcoPolo)&nbsp;&lt;<a href="mailto:git@marcopolo.io">git@marcopolo.io</a>&gt;, Daniel Knopik (@dknopik)&nbsp;&lt;<a href="mailto:daniel@dknopik.de">daniel@dknopik.de</a>&gt;, Sukun Tarachandani (@sukunrt)&nbsp;&lt;<a href="mailto:sukunrt@gmail.com">sukunrt@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8138">8138</a></td> <td class="title">Hardfork Meta - BPO3</td> <td class="author">Pooja Ranjan&nbsp;(<a href="https://github.com/poojaranjan">@poojaranjan</a>), Barnabas Busa&nbsp;(<a href="https://github.com/barnabasbusa">@barnabasbusa</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8141">8141</a></td> <td class="title">Frame Transaction</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Felix Lange&nbsp;(<a href="https://github.com/fjl">@fjl</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>), Derek Chiang&nbsp;(<a href="https://github.com/derekchiang">@derekchiang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8142">8142</a></td> <td class="title">Block-in-Blobs (BiB)</td> <td class="author">Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Jihoon Song&nbsp;&lt;<a href="mailto:jihoon.song@ethereum.org">jihoon.song@ethereum.org</a>&gt;, Francesco Risitano&nbsp;(<a href="https://github.com/frisitano">@frisitano</a>), Thomas Thiery (@soispoke)&nbsp;&lt;<a href="mailto:thomas.thiery@ethereum.org">thomas.thiery@ethereum.org</a>&gt;, Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8146">8146</a></td> <td class="title">Block Access List Sidecars</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Raúl Kripalani&nbsp;(<a href="https://github.com/raulk">@raulk</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8148">8148</a></td> <td class="title">Custom sweep threshold for validators</td> <td class="author">Dmitry Gusakov&nbsp;(<a href="https://github.com/dgusakov">@dgusakov</a>), Dmitry Chernukhin&nbsp;(<a href="https://github.com/madlabman">@madlabman</a>), Greg Koumoutsos&nbsp;(<a href="https://github.com/gkoumout">@gkoumout</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8149">8149</a></td> <td class="title">Multi KZG Point Evaluation Precompile</td> <td class="author">Chris Mata&nbsp;(<a href="https://github.com/protocolwhisper">@protocolwhisper</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8151">8151</a></td> <td class="title">Private Key Deactivation Aware ecRecover</td> <td class="author">Liyi Guo&nbsp;(<a href="https://github.com/colinlyguo">@colinlyguo</a>), Nicolas Consigny&nbsp;(<a href="https://github.com/nconsigny">@nconsigny</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8153">8153</a></td> <td class="title">Facet-Based Diamonds</td> <td class="author">Nick Mudge&nbsp;(<a href="https://github.com/mudgen">@mudgen</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8159">8159</a></td> <td class="title">eth/71 - Block Access List Exchange</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8163">8163</a></td> <td class="title">Reserve `EXTENSION (0xae)` opcode</td> <td class="author">Bruce Collie&nbsp;(<a href="https://github.com/Baltoli">@Baltoli</a>), Piotr Dobaczewski&nbsp;(<a href="https://github.com/pdobacz">@pdobacz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8164">8164</a></td> <td class="title">Native Key Delegation for EOAs</td> <td class="author">Gregory Markou (@GregTheGreek)&nbsp;&lt;<a href="mailto:gregorymarkou@gmail.com">gregorymarkou@gmail.com</a>&gt;, James Prestwich (@prestwich)&nbsp;&lt;<a href="mailto:james@prestwi.ch">james@prestwi.ch</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8173">8173</a></td> <td class="title">Foundations of EVM Control Flow</td> <td class="author">Greg Colvin&nbsp;(<a href="https://github.com/gcolvin">@gcolvin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8175">8175</a></td> <td class="title">Composable Transaction</td> <td class="author">Dragan Rakita&nbsp;(<a href="https://github.com/rakita">@rakita</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8178">8178</a></td> <td class="title">Binary SSZ Transport for the Engine API</td> <td class="author">Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8182">8182</a></td> <td class="title">Private ETH and ERC-20 Transfers</td> <td class="author">Tom Lehman&nbsp;(<a href="https://github.com/RogerPodacter">@RogerPodacter</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8183">8183</a></td> <td class="title">Agentic Commerce</td> <td class="author">Davide Crapis&nbsp;(<a href="https://github.com/dcrapis">@dcrapis</a>), Bryan Lim&nbsp;(<a href="https://github.com/ai-virtual-b">@ai-virtual-b</a>), Tay Weixiong&nbsp;(<a href="https://github.com/twx-virtuals">@twx-virtuals</a>), Chooi Zuhwa&nbsp;(<a href="https://github.com/Zuhwa">@Zuhwa</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8184">8184</a></td> <td class="title">LUCID encrypted mempool</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>), Justin Florentine&nbsp;(<a href="https://github.com/jflo">@jflo</a>), Julian Ma&nbsp;(<a href="https://github.com/ma-julian">@ma-julian</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8188">8188</a></td> <td class="title">State Tiering by Write Age</td> <td class="author">Wei Han Ng&nbsp;(<a href="https://github.com/weiihann">@weiihann</a>), Amirul Ashraf&nbsp;(<a href="https://github.com/asdacap">@asdacap</a>), Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Maria Silva&nbsp;(<a href="https://github.com/misilva73">@misilva73</a>), Gary Rong&nbsp;(<a href="https://github.com/rjl493456442">@rjl493456442</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8189">8189</a></td> <td class="title">snap/2 - BAL-Based State Healing</td> <td class="author">Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Gary Rong&nbsp;(<a href="https://github.com/rjl493456442">@rjl493456442</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8196">8196</a></td> <td class="title">AI Agent Authenticated Wallet</td> <td class="author">Leigh Cronian (@cybercentry)&nbsp;&lt;<a href="mailto:leigh.cronian@cybercentry.co.uk">leigh.cronian@cybercentry.co.uk</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8197">8197</a></td> <td class="title">Cryptographically Agile Transactions</td> <td class="author">Danno Ferrin (@shemnon)&nbsp;&lt;<a href="mailto:danno@tectonic.xyz">danno@tectonic.xyz</a>&gt;, Ron Kahat&nbsp;&lt;<a href="mailto:ron@tectonic.xyz">ron@tectonic.xyz</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8198">8198</a></td> <td class="title">Quick Slots</td> <td class="author">Carl Beekhuizen&nbsp;(<a href="https://github.com/carlbeek">@carlbeek</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8199">8199</a></td> <td class="title">Sandboxed Smart Wallet</td> <td class="author">David Kim&nbsp;(<a href="https://github.com/PowerStream3604">@PowerStream3604</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8200">8200</a></td> <td class="title">EVMification</td> <td class="author">Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8202">8202</a></td> <td class="title">Scheme-Agile Transactions</td> <td class="author">Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8205">8205</a></td> <td class="title">Withdrawal credentials preregistration</td> <td class="author">George Avsetsin&nbsp;(<a href="https://github.com/avsetsin">@avsetsin</a>), Dmitry Gusakov&nbsp;(<a href="https://github.com/dgusakov">@dgusakov</a>), Greg Koumoutsos&nbsp;(<a href="https://github.com/gkoumout">@gkoumout</a>), Eugene Mamin&nbsp;(<a href="https://github.com/TheDZhon">@TheDZhon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8209">8209</a></td> <td class="title">Commit-Reveal Transaction Frames</td> <td class="author">Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8237">8237</a></td> <td class="title">Independent CL/EL Sync</td> <td class="author">M. Kalinin&nbsp;&lt;<a href="mailto:noblesse.knight@gmail.com">noblesse.knight@gmail.com</a>&gt;, Potuz&nbsp;(<a href="https://github.com/potuz">@potuz</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8246">8246</a></td> <td class="title">Remove SELFDESTRUCT Burn</td> <td class="author">Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8255">8255</a></td> <td class="title">Expiring Token Approvals</td> <td class="author">Moody Salem (@moodysalem)&nbsp;&lt;<a href="mailto:moody.salem@gmail.com">moody.salem@gmail.com</a>&gt;</td> </tr> </table> <h2 id="stagnant">Stagnant</h2> <table class="eiptable"> <thead> <tr><th class="eipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr> </thead> <tr> <td class="eipnum"><a href="/EIPS/eip-86">86</a></td> <td class="title">Abstraction of transaction origin and signature</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-101">101</a></td> <td class="title">Serenity Currency and Crypto Abstraction</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-107">107</a></td> <td class="title">safe &quot;eth_sendTransaction&quot; authorization via html popup</td> <td class="author">Ronan Sandford&nbsp;(<a href="https://github.com/wighawag">@wighawag</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-205">205</a></td> <td class="title">ENS support for contract ABIs</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:nick@ethereum.org">nick@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-210">210</a></td> <td class="title">Blockhash refactoring</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-233">233</a></td> <td class="title">Formal process of hard forks</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-615">615</a></td> <td class="title">Subroutines and Static Jumps for the EVM</td> <td class="author">Greg Colvin&nbsp;&lt;<a href="mailto:greg@colvin.org">greg@colvin.org</a>&gt;, Brooklyn Zelenka&nbsp;(<a href="https://github.com/expede">@expede</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Christian Reitwiessner&nbsp;(<a href="https://github.com/chriseth">@chriseth</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-616">616</a></td> <td class="title">SIMD Operations for the EVM</td> <td class="author">Greg Colvin&nbsp;&lt;<a href="mailto:greg@colvin.org">greg@colvin.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-634">634</a></td> <td class="title">Storage of text records in ENS</td> <td class="author">Richard Moore&nbsp;(<a href="https://github.com/ricmoo">@ricmoo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-663">663</a></td> <td class="title">SWAPN, DUPN and EXCHANGE instructions</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-665">665</a></td> <td class="title">Add precompiled contract for Ed25519 signature verification</td> <td class="author">Tobias Oberstein&nbsp;&lt;<a href="mailto:tobias.oberstein@crossbario.com">tobias.oberstein@crossbario.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-689">689</a></td> <td class="title">Address Collision of Contract Address Causes Exceptional Halt</td> <td class="author">Yoichi Hirai&nbsp;&lt;<a href="mailto:i@yoichihirai.com">i@yoichihirai.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-698">698</a></td> <td class="title">OPCODE 0x46 BLOCKREWARD</td> <td class="author">Cody Burns&nbsp;&lt;<a href="mailto:dontPanic@codywburns.com">dontPanic@codywburns.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-758">758</a></td> <td class="title">Subscriptions and filters for completed transactions</td> <td class="author">Jack Peterson&nbsp;&lt;<a href="mailto:jack@tinybike.net">jack@tinybike.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-801">801</a></td> <td class="title">Canary Standard</td> <td class="author">ligi&nbsp;&lt;<a href="mailto:ligi@ligi.de">ligi@ligi.de</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-823">823</a></td> <td class="title">Token Exchange Standard</td> <td class="author">Kashish Khullar&nbsp;&lt;<a href="mailto:kkhullar7@gmail.com">kkhullar7@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-831">831</a></td> <td class="title">URI Format for Ethereum</td> <td class="author">ligi&nbsp;(<a href="https://github.com/ligi">@ligi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-858">858</a></td> <td class="title">Reduce block reward and delay difficulty bomb</td> <td class="author">Carl Larson&nbsp;&lt;<a href="mailto:cslarson@gmail.com">cslarson@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-867">867</a></td> <td class="title">Standardized Ethereum Recovery Proposals</td> <td class="author">Dan Phifer&nbsp;&lt;<a href="mailto:dp@musiconomi.com">dp@musiconomi.com</a>&gt;, James Levy&nbsp;&lt;<a href="mailto:james@taptrust.com">james@taptrust.com</a>&gt;, Reuben Youngblom&nbsp;&lt;<a href="mailto:reuben@taptrust.com">reuben@taptrust.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-884">884</a></td> <td class="title">DGCL Token</td> <td class="author">Dave Sag&nbsp;&lt;<a href="mailto:davesag@gmail.com">davesag@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-897">897</a></td> <td class="title">DelegateProxy</td> <td class="author">Jorge Izquierdo&nbsp;&lt;<a href="mailto:jorge@aragon.one">jorge@aragon.one</a>&gt;, Manuel Araoz&nbsp;&lt;<a href="mailto:manuel@zeppelin.solutions">manuel@zeppelin.solutions</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-900">900</a></td> <td class="title">Simple Staking Interface</td> <td class="author">Dean Eigenmann&nbsp;&lt;<a href="mailto:dean@tokenate.io">dean@tokenate.io</a>&gt;, Jorge Izquierdo&nbsp;&lt;<a href="mailto:jorge@aragon.one">jorge@aragon.one</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-902">902</a></td> <td class="title">Token Validation</td> <td class="author">Brooklyn Zelenka&nbsp;(<a href="https://github.com/expede">@expede</a>), Tom Carchrae&nbsp;(<a href="https://github.com/carchrae">@carchrae</a>), Gleb Naumenko&nbsp;(<a href="https://github.com/naumenkogs">@naumenkogs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-918">918</a></td> <td class="title">Mineable Token Standard</td> <td class="author">Jay Logelin&nbsp;&lt;<a href="mailto:jlogelin@alumni.harvard.edu">jlogelin@alumni.harvard.edu</a>&gt;, Infernal_toast&nbsp;&lt;<a href="mailto:admin@0xbitcoin.org">admin@0xbitcoin.org</a>&gt;, Michael Seiler&nbsp;&lt;<a href="mailto:mgs33@cornell.edu">mgs33@cornell.edu</a>&gt;, Brandon Grill&nbsp;&lt;<a href="mailto:bg2655@columbia.edu">bg2655@columbia.edu</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-926">926</a></td> <td class="title">Address metadata registry</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:nick@ethereum.org">nick@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-927">927</a></td> <td class="title">Generalised authorisations</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:nick@ethereum.org">nick@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-969">969</a></td> <td class="title">Modifications to ethash to invalidate existing dedicated hardware implementations</td> <td class="author">David Stanfill&nbsp;&lt;<a href="mailto:david@airsquirrels.com">david@airsquirrels.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1010">1010</a></td> <td class="title">Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c</td> <td class="author">Anderson Wesley&nbsp;(<a href="https://github.com/andywesley">@andywesley</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1011">1011</a></td> <td class="title">Hybrid Casper FFG</td> <td class="author">Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>), Chih-Cheng Liang&nbsp;(<a href="https://github.com/ChihChengLiang">@ChihChengLiang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1015">1015</a></td> <td class="title">Configurable On Chain Issuance</td> <td class="author">Alex Van de Sande&nbsp;&lt;<a href="mailto:avsa@ethereum.org">avsa@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1051">1051</a></td> <td class="title">Overflow checking for the EVM</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:arachnid@notdot.net">arachnid@notdot.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1056">1056</a></td> <td class="title">Ethereum Lightweight Identity</td> <td class="author">Pelle Braendgaard&nbsp;&lt;<a href="mailto:pelle.braendgaard@consensys.net">pelle.braendgaard@consensys.net</a>&gt;, Joel Torstensson&nbsp;&lt;<a href="mailto:oed@consensys.net">oed@consensys.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1057">1057</a></td> <td class="title">ProgPoW, a Programmatic Proof-of-Work</td> <td class="author">Greg Colvin&nbsp;&lt;<a href="mailto:greg@colvin.org">greg@colvin.org</a>&gt;, Andrea Lanfranchi&nbsp;(<a href="https://github.com/AndreaLanfranchi">@AndreaLanfranchi</a>), Michael Carter&nbsp;(<a href="https://github.com/bitsbetrippin">@bitsbetrippin</a>), IfDefElse&nbsp;&lt;<a href="mailto:ifdefelse@protonmail.com">ifdefelse@protonmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1062">1062</a></td> <td class="title">Formalize IPFS hash into ENS(Ethereum Name Service) resolver</td> <td class="author">Phyrex Tsai&nbsp;&lt;<a href="mailto:phyrex@portal.network">phyrex@portal.network</a>&gt;, Portal Network Team</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1066">1066</a></td> <td class="title">Status Codes</td> <td class="author">Brooklyn Zelenka&nbsp;(<a href="https://github.com/expede">@expede</a>), Tom Carchrae&nbsp;(<a href="https://github.com/carchrae">@carchrae</a>), Gleb Naumenko&nbsp;(<a href="https://github.com/naumenkogs">@naumenkogs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1077">1077</a></td> <td class="title">Gas relay for contract calls</td> <td class="author">Alex Van de Sande&nbsp;&lt;<a href="mailto:avsa@ethereum.org">avsa@ethereum.org</a>&gt;, Ricardo Guilherme Schmidt&nbsp;(<a href="https://github.com/3esmit">@3esmit</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1078">1078</a></td> <td class="title">Universal login / signup using ENS subdomains</td> <td class="author">Alex Van de Sande&nbsp;&lt;<a href="mailto:avsa@ethereum.org">avsa@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1080">1080</a></td> <td class="title">Recoverable Token</td> <td class="author">Bradley Leatherwood&nbsp;&lt;<a href="mailto:bradleat@inkibra.com">bradleat@inkibra.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1081">1081</a></td> <td class="title">Standard Bounties</td> <td class="author">Mark Beylin&nbsp;&lt;<a href="mailto:mark.beylin@consensys.net">mark.beylin@consensys.net</a>&gt;, Kevin Owocki&nbsp;&lt;<a href="mailto:kevin.owocki@consensys.net">kevin.owocki@consensys.net</a>&gt;, Ricardo Guilherme Schmidt&nbsp;(<a href="https://github.com/3esmit">@3esmit</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1087">1087</a></td> <td class="title">Net gas metering for SSTORE operations</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1102">1102</a></td> <td class="title">Opt-in account exposure</td> <td class="author">Paul Bouchon&nbsp;&lt;<a href="mailto:mail@bitpshr.net">mail@bitpshr.net</a>&gt;, Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1109">1109</a></td> <td class="title">PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts)</td> <td class="author">Jordi Baylina&nbsp;(<a href="https://github.com/jbaylina">@jbaylina</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1129">1129</a></td> <td class="title">Standardised DAPP announcements</td> <td class="author">Jan Turk&nbsp;(<a href="https://github.com/ThunderDeliverer">@ThunderDeliverer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1132">1132</a></td> <td class="title">Extending ERC20 with token locking capability</td> <td class="author">nitika-goel&nbsp;&lt;<a href="mailto:nitika@govblocks.io">nitika@govblocks.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1175">1175</a></td> <td class="title">Wallet &amp; shop standard for all tokens (erc20)</td> <td class="author">Jet Lim&nbsp;(<a href="https://github.com/Nitro888">@Nitro888</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1178">1178</a></td> <td class="title">Multi-class Token Standard</td> <td class="author">Albert Chon&nbsp;&lt;<a href="mailto:achon@stanford.edu">achon@stanford.edu</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1186">1186</a></td> <td class="title">RPC-Method to get Merkle Proofs - eth_getProof</td> <td class="author">Simon Jentzsch&nbsp;&lt;<a href="mailto:simon.jentzsch@slock.it">simon.jentzsch@slock.it</a>&gt;, Christoph Jentzsch&nbsp;&lt;<a href="mailto:christoph.jentzsch@slock.it">christoph.jentzsch@slock.it</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1203">1203</a></td> <td class="title">ERC-1203 Multi-Class Token Standard (ERC-20 Extension)</td> <td class="author">Jeff Huang&nbsp;&lt;<a href="mailto:jeffishjeff@gmail.com">jeffishjeff@gmail.com</a>&gt;, Min Zu&nbsp;&lt;<a href="mailto:crawlregister@gmail.com">crawlregister@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1207">1207</a></td> <td class="title">DAuth Access Delegation Standard</td> <td class="author">Xiaoyu Wang&nbsp;(<a href="https://github.com/wxygeek">@wxygeek</a>), Bicong Wang&nbsp;(<a href="https://github.com/Wangbicong">@Wangbicong</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1227">1227</a></td> <td class="title">Defuse Difficulty Bomb and Reset Block Reward</td> <td class="author">SmeargleUsedFly&nbsp;(<a href="https://github.com/SmeargleUsedFly">@SmeargleUsedFly</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1261">1261</a></td> <td class="title">Membership Verification Token (MVT)</td> <td class="author">Chaitanya Potti&nbsp;(<a href="https://github.com/chaitanyapotti">@chaitanyapotti</a>), Partha Bhattacharya&nbsp;(<a href="https://github.com/pb25193">@pb25193</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1276">1276</a></td> <td class="title">Eliminate Difficulty Bomb and Adjust Block Reward on Constantinople Shift</td> <td class="author">EOS Classic&nbsp;(<a href="https://github.com/eosclassicteam">@eosclassicteam</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1285">1285</a></td> <td class="title">Increase Gcallstipend gas in the CALL opcode</td> <td class="author">Ben Kaufman&nbsp;&lt;<a href="mailto:ben@daostack.io">ben@daostack.io</a>&gt;, Adam Levi&nbsp;&lt;<a href="mailto:adam@daostack.io">adam@daostack.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1295">1295</a></td> <td class="title">Modify Ethereum PoW Incentive Structure and Delay Difficulty Bomb</td> <td class="author">Brian Venturo&nbsp;(<a href="https://github.com/atlanticcrypto">@atlanticcrypto</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1319">1319</a></td> <td class="title">Smart Contract Package Registry Interface</td> <td class="author">Piper Merriam&nbsp;&lt;<a href="mailto:piper@ethereum.org">piper@ethereum.org</a>&gt;, Christopher Gewecke&nbsp;&lt;<a href="mailto:christophergewecke@gmail.com">christophergewecke@gmail.com</a>&gt;, g. nicholas d'andrea&nbsp;&lt;<a href="mailto:nick.dandrea@consensys.net">nick.dandrea@consensys.net</a>&gt;, Nick Gheorghita&nbsp;(<a href="https://github.com/njgheorghita">@njgheorghita</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1337">1337</a></td> <td class="title">Subscriptions on the blockchain</td> <td class="author">Kevin Owocki&nbsp;&lt;<a href="mailto:kevin@gitcoin.co">kevin@gitcoin.co</a>&gt;, Andrew Redden&nbsp;&lt;<a href="mailto:andrew@blockcrushr.com">andrew@blockcrushr.com</a>&gt;, Scott Burke&nbsp;&lt;<a href="mailto:scott@blockcrushr.com">scott@blockcrushr.com</a>&gt;, Kevin Seagraves&nbsp;&lt;<a href="mailto:k.s.seagraves@gmail.com">k.s.seagraves@gmail.com</a>&gt;, Luka Kacil&nbsp;&lt;<a href="mailto:luka.kacil@gmail.com">luka.kacil@gmail.com</a>&gt;, Štefan Šimec&nbsp;&lt;<a href="mailto:stefan.simec@gmail.com">stefan.simec@gmail.com</a>&gt;, Piotr Kosiński&nbsp;(<a href="https://github.com/kosecki123">@kosecki123</a>), ankit raj&nbsp;&lt;<a href="mailto:tradeninja7@gmail.com">tradeninja7@gmail.com</a>&gt;, John Griffin&nbsp;&lt;<a href="mailto:john@atchai.com">john@atchai.com</a>&gt;, Nathan Creswell&nbsp;&lt;<a href="mailto:nathantr@gmail.com">nathantr@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1352">1352</a></td> <td class="title">Specify restricted address range for precompiles/system contracts</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1380">1380</a></td> <td class="title">Reduced gas cost for call to self</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Jacques Wagener&nbsp;(<a href="https://github.com/jacqueswww">@jacqueswww</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1386">1386</a></td> <td class="title">Attestation management contract</td> <td class="author">Weiwu Zhang&nbsp;&lt;<a href="mailto:a@colourful.land">a@colourful.land</a>&gt;, James Sangalli&nbsp;&lt;<a href="mailto:j.l.sangalli@gmail.com">j.l.sangalli@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1387">1387</a></td> <td class="title">Merkle Tree Attestations with Privacy enabled</td> <td class="author">Weiwu Zhang&nbsp;&lt;<a href="mailto:a@colourful.land">a@colourful.land</a>&gt;, James Sangalli&nbsp;&lt;<a href="mailto:j.l.sangalli@gmail.com">j.l.sangalli@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1388">1388</a></td> <td class="title">Attestation Issuers Management List</td> <td class="author">Weiwu Zhang&nbsp;&lt;<a href="mailto:a@colourful.land">a@colourful.land</a>&gt;, James Sangalli&nbsp;&lt;<a href="mailto:j.l.sangalli@gmail.com">j.l.sangalli@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1417">1417</a></td> <td class="title">Poll Standard</td> <td class="author">Chaitanya Potti&nbsp;(<a href="https://github.com/chaitanyapotti">@chaitanyapotti</a>), Partha Bhattacharya&nbsp;(<a href="https://github.com/pb25193">@pb25193</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1418">1418</a></td> <td class="title">Blockchain Storage Rent Payment</td> <td class="author">William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1438">1438</a></td> <td class="title">dApp Components (avatar) &amp; Universal Wallet</td> <td class="author">Jet Lim&nbsp;(<a href="https://github.com/Nitro888">@Nitro888</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1444">1444</a></td> <td class="title">Localized Messaging with Signal-to-Text</td> <td class="author">Brooklyn Zelenka&nbsp;(<a href="https://github.com/expede">@expede</a>), Jennifer Cooper&nbsp;(<a href="https://github.com/jenncoop">@jenncoop</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1450">1450</a></td> <td class="title">ERC-1450 A compatible security token for issuing and trading SEC-compliant securities</td> <td class="author">John Shiple&nbsp;(<a href="https://github.com/johnshiple">@johnshiple</a>), Howard Marks&nbsp;&lt;<a href="mailto:howard@startengine.com">howard@startengine.com</a>&gt;, David Zhang&nbsp;&lt;<a href="mailto:david@startengine.com">david@startengine.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1459">1459</a></td> <td class="title">Node Discovery via DNS</td> <td class="author">Felix Lange&nbsp;(<a href="https://github.com/fjl">@fjl</a>), Péter Szilágyi&nbsp;(<a href="https://github.com/karalabe">@karalabe</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1462">1462</a></td> <td class="title">Base Security Token</td> <td class="author">Maxim Kupriianov&nbsp;&lt;<a href="mailto:mk@atlant.io">mk@atlant.io</a>&gt;, Julian Svirsky&nbsp;&lt;<a href="mailto:js@atlant.io">js@atlant.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1470">1470</a></td> <td class="title">Smart Contract Weakness Classification (SWC)</td> <td class="author">Gerhard Wagner&nbsp;(<a href="https://github.com/thec00n">@thec00n</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1474">1474</a></td> <td class="title">Remote procedure call specification</td> <td class="author">Paul Bouchon&nbsp;&lt;<a href="mailto:mail@bitpshr.net">mail@bitpshr.net</a>&gt;, Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1482">1482</a></td> <td class="title">Define a maximum block timestamp drift</td> <td class="author">Maurelian&nbsp;(<a href="https://github.com/Maurelian">@Maurelian</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1484">1484</a></td> <td class="title">Digital Identity Aggregator</td> <td class="author">Anurag Angara&nbsp;&lt;<a href="mailto:anurag.angara@gmail.com">anurag.angara@gmail.com</a>&gt;, Andy Chorlian&nbsp;&lt;<a href="mailto:andychorlian@gmail.com">andychorlian@gmail.com</a>&gt;, Shane Hampton&nbsp;&lt;<a href="mailto:shanehampton1@gmail.com">shanehampton1@gmail.com</a>&gt;, Noah Zinsmeister&nbsp;&lt;<a href="mailto:noahwz@gmail.com">noahwz@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1485">1485</a></td> <td class="title">TEthashV1</td> <td class="author">trustfarm&nbsp;&lt;<a href="mailto:trustfarm.info@gmail.com">trustfarm.info@gmail.com</a>&gt;, trustfarm&nbsp;&lt;<a href="mailto:cpplover@trustfarm.net">cpplover@trustfarm.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1491">1491</a></td> <td class="title">Human Cost Accounting Standard (Like Gas but for humans)</td> <td class="author">Iamnot Chris&nbsp;(<a href="https://github.com/cohabo">@cohabo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1504">1504</a></td> <td class="title">Upgradable Smart Contract</td> <td class="author">Kaidong Wu&nbsp;&lt;<a href="mailto:wukd94@pku.edu.cn">wukd94@pku.edu.cn</a>&gt;, Chuqiao Ren&nbsp;&lt;<a href="mailto:cr025@bucknell.edu">cr025@bucknell.edu</a>&gt;, Ruthia He&nbsp;&lt;<a href="mailto:rujiahe@gmail.com">rujiahe@gmail.com</a>&gt;, Yun Ma&nbsp;&lt;<a href="mailto:mayun@pku.edu.cn">mayun@pku.edu.cn</a>&gt;, Xuanzhe Liu&nbsp;&lt;<a href="mailto:liuxuanzhe@pku.edu.cn">liuxuanzhe@pku.edu.cn</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1523">1523</a></td> <td class="title">Standard for Insurance Policies as ERC-721 Non Fungible Tokens</td> <td class="author">Christoph Mussenbrock&nbsp;(<a href="https://github.com/christoph2806">@christoph2806</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1571">1571</a></td> <td class="title">EthereumStratum/2.0.0</td> <td class="author">Andrea Lanfranchi&nbsp;(<a href="https://github.com/AndreaLanfranchi">@AndreaLanfranchi</a>), Pawel Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Marius Van Der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1577">1577</a></td> <td class="title">contenthash field for ENS</td> <td class="author">Dean Eigenmann&nbsp;&lt;<a href="mailto:dean@ens.domains">dean@ens.domains</a>&gt;, Nick Johnson&nbsp;&lt;<a href="mailto:nick@ens.domains">nick@ens.domains</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1581">1581</a></td> <td class="title">Non-wallet usage of keys derived from BIP-32 trees</td> <td class="author">Michele Balistreri&nbsp;(<a href="https://github.com/bitgamma">@bitgamma</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1588">1588</a></td> <td class="title">Hardfork Meta: Ethereum ProgPoW</td> <td class="author">Ikmyeong Na&nbsp;(<a href="https://github.com/naikmyeong">@naikmyeong</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1592">1592</a></td> <td class="title">Address and ERC20-compliant transfer rules</td> <td class="author">Cyril Lapinte&nbsp;&lt;<a href="mailto:cyril.lapinte@mtpelerin.com">cyril.lapinte@mtpelerin.com</a>&gt;, Laurent Aapro&nbsp;&lt;<a href="mailto:laurent.aapro@mtpelerin.com">laurent.aapro@mtpelerin.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1613">1613</a></td> <td class="title">Gas stations network</td> <td class="author">Yoav Weiss&nbsp;&lt;<a href="mailto:yoav@tabookey.com">yoav@tabookey.com</a>&gt;, Dror Tirosh&nbsp;&lt;<a href="mailto:dror@tabookey.com">dror@tabookey.com</a>&gt;, Alex Forshtat&nbsp;&lt;<a href="mailto:alex@tabookey.com">alex@tabookey.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1616">1616</a></td> <td class="title">Attribute Registry Standard</td> <td class="author">0age&nbsp;(<a href="https://github.com/0age">@0age</a>), Santiago Palladino&nbsp;(<a href="https://github.com/spalladino">@spalladino</a>), Leo Arias&nbsp;(<a href="https://github.com/elopio">@elopio</a>), Alejo Salles&nbsp;(<a href="https://github.com/fiiiu">@fiiiu</a>), Stephane Gosselin&nbsp;(<a href="https://github.com/thegostep">@thegostep</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1620">1620</a></td> <td class="title">Money Streaming</td> <td class="author">Paul Berg&nbsp;(<a href="https://github.com/PaulRBerg">@PaulRBerg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1633">1633</a></td> <td class="title">Re-Fungible Token Standard (RFT)</td> <td class="author">Billy Rennekamp&nbsp;(<a href="https://github.com/okwme">@okwme</a>), Dan Long&nbsp;&lt;<a href="mailto:dan@artblx.com">dan@artblx.com</a>&gt;, Kiryl Yermakou&nbsp;&lt;<a href="mailto:kiryl@artblx.com">kiryl@artblx.com</a>&gt;, Nate van der Ende&nbsp;&lt;<a href="mailto:nate@artblx.com">nate@artblx.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1681">1681</a></td> <td class="title">Temporal Replay Protection</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1702">1702</a></td> <td class="title">Generalized Account Versioning Scheme</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1710">1710</a></td> <td class="title">URL Format for Web3 Browsers</td> <td class="author">Bruno Barbieri&nbsp;(<a href="https://github.com/brunobar79">@brunobar79</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1753">1753</a></td> <td class="title">Smart Contract Interface for Licences</td> <td class="author">Lucas Cullen&nbsp;(<a href="https://github.com/BitcoinBrisbane">@BitcoinBrisbane</a>), Kai Yeung&nbsp;(<a href="https://github.com/CivicKai">@CivicKai</a>), Anna Crowley&nbsp;&lt;<a href="mailto:annaelizabethcrowley@gmail.com">annaelizabethcrowley@gmail.com</a>&gt;, Caroline Marshall&nbsp;&lt;<a href="mailto:caroline.marshall888@gmail.com">caroline.marshall888@gmail.com</a>&gt;, Katrina Donaghy&nbsp;&lt;<a href="mailto:katrina@civicledger.com">katrina@civicledger.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1761">1761</a></td> <td class="title">Scoped Approval Interface</td> <td class="author">Witek Radomski&nbsp;&lt;<a href="mailto:witek@enjin.io">witek@enjin.io</a>&gt;, Andrew Cooke&nbsp;&lt;<a href="mailto:ac0dem0nk3y@gmail.com">ac0dem0nk3y@gmail.com</a>&gt;, James Therien&nbsp;&lt;<a href="mailto:james@enjin.io">james@enjin.io</a>&gt;, Eric Binet&nbsp;&lt;<a href="mailto:eric@enjin.io">eric@enjin.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1767">1767</a></td> <td class="title">GraphQL interface to Ethereum node data</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>), Raúl Kripalani&nbsp;(<a href="https://github.com/raulk">@raulk</a>), Kris Shinn&nbsp;(<a href="https://github.com/kshinn">@kshinn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1775">1775</a></td> <td class="title">App Keys, application specific wallet accounts</td> <td class="author">Vincent Eli&nbsp;(<a href="https://github.com/Bunjin">@Bunjin</a>), Dan Finlay&nbsp;(<a href="https://github.com/DanFinlay">@DanFinlay</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1803">1803</a></td> <td class="title">Rename opcodes for clarity</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1812">1812</a></td> <td class="title">Ethereum Verifiable Claims</td> <td class="author">Pelle Braendgaard&nbsp;(<a href="https://github.com/pelle">@pelle</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1822">1822</a></td> <td class="title">Universal Upgradeable Proxy Standard (UUPS)</td> <td class="author">Gabriel Barros&nbsp;&lt;<a href="mailto:gabriel@terminal.co">gabriel@terminal.co</a>&gt;, Patrick Gallagher&nbsp;&lt;<a href="mailto:blockchainbuddha@gmail.com">blockchainbuddha@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1829">1829</a></td> <td class="title">Precompile for Elliptic Curve Linear Combinations</td> <td class="author">Remco Bloemen&nbsp;&lt;<a href="mailto:Recmo@0x.org">Recmo@0x.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1844">1844</a></td> <td class="title">ENS Interface Discovery</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1872">1872</a></td> <td class="title">Ethereum Network Upgrade Windows</td> <td class="author">Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1895">1895</a></td> <td class="title">Support for an Elliptic Curve Cycle</td> <td class="author">Alexandre Belling&nbsp;&lt;<a href="mailto:alexandrebelling8@gmail.com">alexandrebelling8@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1900">1900</a></td> <td class="title">dType - Decentralized Type System for EVM</td> <td class="author">Loredana Cirstea&nbsp;(<a href="https://github.com/loredanacirstea">@loredanacirstea</a>), Christian Tzurcanu&nbsp;(<a href="https://github.com/ctzurcanu">@ctzurcanu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1901">1901</a></td> <td class="title">Add OpenRPC Service Discovery To JSON-RPC Services</td> <td class="author">Shane Jonas&nbsp;(<a href="https://github.com/shanejonas">@shanejonas</a>), Zachary Belford&nbsp;(<a href="https://github.com/belfordz">@belfordz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1921">1921</a></td> <td class="title">dType Functions Extension</td> <td class="author">Loredana Cirstea&nbsp;(<a href="https://github.com/loredanacirstea">@loredanacirstea</a>), Christian Tzurcanu&nbsp;(<a href="https://github.com/ctzurcanu">@ctzurcanu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1922">1922</a></td> <td class="title">zk-SNARK Verifier Standard</td> <td class="author">Michael Connor&nbsp;&lt;<a href="mailto:michael.connor@uk.ey.com">michael.connor@uk.ey.com</a>&gt;, Chaitanya Konda&nbsp;&lt;<a href="mailto:chaitanya.konda@uk.ey.com">chaitanya.konda@uk.ey.com</a>&gt;, Duncan Westland&nbsp;&lt;<a href="mailto:duncan.westland@uk.ey.com">duncan.westland@uk.ey.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1923">1923</a></td> <td class="title">zk-SNARK Verifier Registry Standard</td> <td class="author">Michael Connor&nbsp;&lt;<a href="mailto:michael.connor@uk.ey.com">michael.connor@uk.ey.com</a>&gt;, Chaitanya Konda&nbsp;&lt;<a href="mailto:chaitanya.konda@uk.ey.com">chaitanya.konda@uk.ey.com</a>&gt;, Duncan Westland&nbsp;&lt;<a href="mailto:duncan.westland@uk.ey.com">duncan.westland@uk.ey.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1930">1930</a></td> <td class="title">CALLs with strict gas semantic. Revert if not enough gas available.</td> <td class="author">Ronan Sandford&nbsp;(<a href="https://github.com/wighawag">@wighawag</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1948">1948</a></td> <td class="title">Non-fungible Data Token</td> <td class="author">Johann Barbie&nbsp;(<a href="https://github.com/johannbarbie">@johannbarbie</a>), Ben Bollen&nbsp;&lt;<a href="mailto:ben@ost.com">ben@ost.com</a>&gt;, pinkiebell&nbsp;(<a href="https://github.com/pinkiebell">@pinkiebell</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1959">1959</a></td> <td class="title">New Opcode to check if a chainID is part of the history of chainIDs</td> <td class="author">Ronan Sandford&nbsp;(<a href="https://github.com/wighawag">@wighawag</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1962">1962</a></td> <td class="title">EC arithmetic and pairings with runtime definitions</td> <td class="author">Alex Vlasov&nbsp;(<a href="https://github.com/shamatar">@shamatar</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1965">1965</a></td> <td class="title">Method to check if a chainID is valid at a specific block Number</td> <td class="author">Ronan Sandford&nbsp;(<a href="https://github.com/wighawag">@wighawag</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1973">1973</a></td> <td class="title">Scalable Rewards</td> <td class="author">Lee Raj&nbsp;(<a href="https://github.com/lerajk">@lerajk</a>), Qin Jian&nbsp;(<a href="https://github.com/qinjian">@qinjian</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1985">1985</a></td> <td class="title">Sane limits for certain EVM parameters</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1996">1996</a></td> <td class="title">Holdable Token</td> <td class="author">Julio Faura&nbsp;&lt;<a href="mailto:julio@adhara.io">julio@adhara.io</a>&gt;, Fernando Paris&nbsp;&lt;<a href="mailto:fer@io.builders">fer@io.builders</a>&gt;, Daniel Lehrner&nbsp;&lt;<a href="mailto:daniel@io.builders">daniel@io.builders</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2003">2003</a></td> <td class="title">EVMC modules for implementations of precompiled contracts</td> <td class="author">Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2009">2009</a></td> <td class="title">Compliance Service</td> <td class="author">Daniel Lehrner&nbsp;&lt;<a href="mailto:daniel@io.builders">daniel@io.builders</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2014">2014</a></td> <td class="title">Extended State Oracle</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2015">2015</a></td> <td class="title">wallet_updateEthereumChain RPC Method</td> <td class="author">Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>), Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>), Pandapip1&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2018">2018</a></td> <td class="title">Clearable Token</td> <td class="author">Julio Faura&nbsp;&lt;<a href="mailto:julio@adhara.io">julio@adhara.io</a>&gt;, Fernando Paris&nbsp;&lt;<a href="mailto:fer@io.builders">fer@io.builders</a>&gt;, Daniel Lehrner&nbsp;&lt;<a href="mailto:daniel@io.builders">daniel@io.builders</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2019">2019</a></td> <td class="title">Fundable Token</td> <td class="author">Fernando Paris&nbsp;&lt;<a href="mailto:fer@io.builders">fer@io.builders</a>&gt;, Julio Faura&nbsp;&lt;<a href="mailto:julio@adhara.io">julio@adhara.io</a>&gt;, Daniel Lehrner&nbsp;&lt;<a href="mailto:daniel@io.builders">daniel@io.builders</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2020">2020</a></td> <td class="title">E-Money Standard Token</td> <td class="author">Julio Faura&nbsp;&lt;<a href="mailto:julio@adhara.io">julio@adhara.io</a>&gt;, Fernando Paris&nbsp;&lt;<a href="mailto:fer@io.builders">fer@io.builders</a>&gt;, Daniel Lehrner&nbsp;&lt;<a href="mailto:daniel@io.builders">daniel@io.builders</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2021">2021</a></td> <td class="title">Payoutable Token</td> <td class="author">Fernando Paris&nbsp;&lt;<a href="mailto:fer@io.builders">fer@io.builders</a>&gt;, Julio Faura&nbsp;&lt;<a href="mailto:julio@adhara.io">julio@adhara.io</a>&gt;, Daniel Lehrner&nbsp;&lt;<a href="mailto:daniel@io.builders">daniel@io.builders</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2026">2026</a></td> <td class="title">State Rent H - Fixed Prepayment for accounts</td> <td class="author">Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2027">2027</a></td> <td class="title">State Rent C - Net contract size accounting</td> <td class="author">Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2029">2029</a></td> <td class="title">State Rent A - State counters contract</td> <td class="author">Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2031">2031</a></td> <td class="title">State Rent B - Net transaction counter</td> <td class="author">Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2035">2035</a></td> <td class="title">Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs</td> <td class="author">Alexey Akhunov&nbsp;(<a href="https://github.com/AlexeyAkhunov">@AlexeyAkhunov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2045">2045</a></td> <td class="title">Particle gas costs for EVM opcodes</td> <td class="author">Casey Detrio&nbsp;(<a href="https://github.com/cdetrio">@cdetrio</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2046">2046</a></td> <td class="title">Reduced gas cost for static calls made to precompiles</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2069">2069</a></td> <td class="title">Recommendation for using YAML ABI in ERCs/EIPs</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2157">2157</a></td> <td class="title">dType Storage Extension - Decentralized Type System for EVM</td> <td class="author">Loredana Cirstea&nbsp;(<a href="https://github.com/loredanacirstea">@loredanacirstea</a>), Christian Tzurcanu&nbsp;(<a href="https://github.com/ctzurcanu">@ctzurcanu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2193">2193</a></td> <td class="title">dType Alias Extension - Decentralized Type System</td> <td class="author">Loredana Cirstea&nbsp;(<a href="https://github.com/loredanacirstea">@loredanacirstea</a>), Christian Tzurcanu&nbsp;(<a href="https://github.com/ctzurcanu">@ctzurcanu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2242">2242</a></td> <td class="title">Transaction Postdata</td> <td class="author">John Adler&nbsp;(<a href="https://github.com/adlerjohn">@adlerjohn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2256">2256</a></td> <td class="title">wallet_getOwnedAssets JSON-RPC Method</td> <td class="author">Loredana Cirstea&nbsp;(<a href="https://github.com/loredanacirstea">@loredanacirstea</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2294">2294</a></td> <td class="title">Explicit bound to Chain ID size</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Bryant Eisenbach&nbsp;(<a href="https://github.com/fubuloubu">@fubuloubu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2304">2304</a></td> <td class="title">Multichain address resolution for ENS</td> <td class="author">Nick Johnson&nbsp;&lt;<a href="mailto:nick@ens.domains">nick@ens.domains</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2327">2327</a></td> <td class="title">BEGINDATA opcode</td> <td class="author">Martin Lundfall&nbsp;(<a href="https://github.com/MrChico">@MrChico</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2330">2330</a></td> <td class="title">EXTSLOAD opcode</td> <td class="author">Dominic Letz&nbsp;(<a href="https://github.com/dominicletz">@dominicletz</a>), Santiago Palladino&nbsp;(<a href="https://github.com/spalladino">@spalladino</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2378">2378</a></td> <td class="title">EIPs Eligible for Inclusion</td> <td class="author">James Hancock&nbsp;(<a href="https://github.com/MadeofTin">@MadeofTin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2386">2386</a></td> <td class="title">Ethereum 2 Hierarchical Deterministic Walletstore</td> <td class="author">Jim McDonald&nbsp;&lt;<a href="mailto:Jim@mcdee.net">Jim@mcdee.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2390">2390</a></td> <td class="title">Geo-ENS</td> <td class="author">James Choncholas&nbsp;(<a href="https://github.com/james-choncholas">@james-choncholas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2400">2400</a></td> <td class="title">Transaction Receipt URI</td> <td class="author">Ricardo Guilherme Schmidt&nbsp;(<a href="https://github.com/3esmit">@3esmit</a>), Eric Dvorsak&nbsp;(<a href="https://github.com/yenda">@yenda</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2470">2470</a></td> <td class="title">Singleton Factory</td> <td class="author">Ricardo Guilherme Schmidt&nbsp;(<a href="https://github.com/3esmit">@3esmit</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2474">2474</a></td> <td class="title">Coinbase calls</td> <td class="author">Ricardo Guilherme Schmidt&nbsp;(<a href="https://github.com/3esmit">@3esmit</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2477">2477</a></td> <td class="title">Token Metadata Integrity</td> <td class="author">Kristijan Sedlak&nbsp;(<a href="https://github.com/xpepermint">@xpepermint</a>), William Entriken&nbsp;&lt;<a href="mailto:github.com@phor.net">github.com@phor.net</a>&gt;, Witek Radomski&nbsp;&lt;<a href="mailto:witek@enjin.io">witek@enjin.io</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2488">2488</a></td> <td class="title">Deprecate the CALLCODE opcode</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2494">2494</a></td> <td class="title">Baby Jubjub Elliptic Curve</td> <td class="author">Barry WhiteHat&nbsp;(<a href="https://github.com/barryWhiteHat">@barryWhiteHat</a>), Marta Bellés&nbsp;(<a href="https://github.com/bellesmarta">@bellesmarta</a>), Jordi Baylina&nbsp;(<a href="https://github.com/jbaylina">@jbaylina</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2515">2515</a></td> <td class="title">Implement Difficulty Freeze</td> <td class="author">James Hancock&nbsp;(<a href="https://github.com/madeoftin">@madeoftin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2520">2520</a></td> <td class="title">Multiple contenthash records for ENS</td> <td class="author">Filip Štamcar&nbsp;(<a href="https://github.com/filips123">@filips123</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2525">2525</a></td> <td class="title">ENSLogin</td> <td class="author">Hadrien Croubois&nbsp;(<a href="https://github.com/amxx">@amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2539">2539</a></td> <td class="title">BLS12-377 curve operations</td> <td class="author">Alex Vlasov&nbsp;(<a href="https://github.com/shamatar">@shamatar</a>), hujw77&nbsp;(<a href="https://github.com/hujw77">@hujw77</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2542">2542</a></td> <td class="title">New opcodes TXGASLIMIT and CALLGASLIMIT</td> <td class="author">Alex Forshtat&nbsp;&lt;<a href="mailto:forshtat1@gmail.com">forshtat1@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2544">2544</a></td> <td class="title">ENS Wildcard Resolution</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>), 0age&nbsp;(<a href="https://github.com/0age">@0age</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2566">2566</a></td> <td class="title">Human Readable Parameters for Contract Function Execution</td> <td class="author">Joseph Stockermans&nbsp;(<a href="https://github.com/jstoxrocky">@jstoxrocky</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2569">2569</a></td> <td class="title">Saving and Displaying Image Onchain for Universal Tokens</td> <td class="author">Hua Zhang&nbsp;(<a href="https://github.com/dgczhh">@dgczhh</a>), Yuefei Tan&nbsp;(<a href="https://github.com/whtyfhas">@whtyfhas</a>), Derek Zhou&nbsp;(<a href="https://github.com/zhous">@zhous</a>), Ran Xing&nbsp;(<a href="https://github.com/lemontreeran">@lemontreeran</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2583">2583</a></td> <td class="title">Penalty for account trie misses</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2584">2584</a></td> <td class="title">Trie format transition with overlay trees</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2593">2593</a></td> <td class="title">Escalator fee market change for ETH 1.0 chain</td> <td class="author">Dan Finlay&nbsp;&lt;<a href="mailto:dan@danfinlay.com">dan@danfinlay.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2615">2615</a></td> <td class="title">Non-Fungible Token with mortgage and rental functions</td> <td class="author">Kohshi Shiba&nbsp;&lt;<a href="mailto:kohshi.shiba@gmail.com">kohshi.shiba@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2645">2645</a></td> <td class="title">Hierarchical Deterministic Wallet for Layer-2</td> <td class="author">Tom Brand&nbsp;&lt;<a href="mailto:tom@starkware.co">tom@starkware.co</a>&gt;, Louis Guthmann&nbsp;&lt;<a href="mailto:louis@starkware.co">louis@starkware.co</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2657">2657</a></td> <td class="title">Ephemeral Testnet Yolo</td> <td class="author">James Hancock&nbsp;(<a href="https://github.com/madeoftin">@madeoftin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2666">2666</a></td> <td class="title">Repricing of precompiles and Keccak256 function</td> <td class="author">Alex Vlasov&nbsp;(<a href="https://github.com/shamatar">@shamatar</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2680">2680</a></td> <td class="title">Ethereum 2 wallet layout</td> <td class="author">Jim McDonald&nbsp;&lt;<a href="mailto:Jim@mcdee.net">Jim@mcdee.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2746">2746</a></td> <td class="title">Rules Engine Standard</td> <td class="author">Aaron Kendall&nbsp;(<a href="https://github.com/jaerith">@jaerith</a>), Juan Blanco&nbsp;(<a href="https://github.com/juanfranblanco">@juanfranblanco</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2767">2767</a></td> <td class="title">Contract Ownership Governance</td> <td class="author">Soham Zemse&nbsp;(<a href="https://github.com/zemse">@zemse</a>), Nick Mudge&nbsp;(<a href="https://github.com/mudgen">@mudgen</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2770">2770</a></td> <td class="title">Meta-Transactions Forwarder Contract</td> <td class="author">Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2803">2803</a></td> <td class="title">Rich Transactions</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2831">2831</a></td> <td class="title">Transaction Replacement Message Type</td> <td class="author">Gregory Markou&nbsp;(<a href="https://github.com/GregTheGreek">@GregTheGreek</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2844">2844</a></td> <td class="title">Add DID related methods to the JSON-RPC</td> <td class="author">Joel Thorstensson&nbsp;(<a href="https://github.com/oed">@oed</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2848">2848</a></td> <td class="title">My Own Messages (MOM)</td> <td class="author">Giuseppe Bertone&nbsp;(<a href="https://github.com/Neurone">@Neurone</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2876">2876</a></td> <td class="title">Deposit contract and address standard</td> <td class="author">Jonathan Underwood&nbsp;(<a href="https://github.com/junderw">@junderw</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2917">2917</a></td> <td class="title">Staking Reward Calculation</td> <td class="author">Tony Carson&nbsp;&lt;<a href="mailto:tony.carsonn@gmail.com">tony.carsonn@gmail.com</a>&gt;, Mehmet Sabir Kiraz&nbsp;&lt;<a href="mailto:m.kiraz@gmail.com">m.kiraz@gmail.com</a>&gt;, Süleyman Kardaş&nbsp;&lt;<a href="mailto:skardas@gmail.com">skardas@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2936">2936</a></td> <td class="title">EXTCLEAR Opcode For SELFDESTRUCTed contracts</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2937">2937</a></td> <td class="title">SET_INDESTRUCTIBLE opcode</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2942">2942</a></td> <td class="title">EthPM URI Specification</td> <td class="author">Nick Gheorghita&nbsp;(<a href="https://github.com/njgheorghita">@njgheorghita</a>), Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>), g. nicholas d'andrea&nbsp;(<a href="https://github.com/gnidan">@gnidan</a>), Benjamin Hauser&nbsp;(<a href="https://github.com/iamdefinitelyahuman">@iamdefinitelyahuman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2970">2970</a></td> <td class="title">IS_STATIC opcode</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2980">2980</a></td> <td class="title">Swiss Compliant Asset Token</td> <td class="author">Gianluca Perletti&nbsp;(<a href="https://github.com/Perlets9">@Perlets9</a>), Alan Scarpellini&nbsp;(<a href="https://github.com/alanscarpellini">@alanscarpellini</a>), Roberto Gorini&nbsp;(<a href="https://github.com/robertogorini">@robertogorini</a>), Manuel Olivi&nbsp;(<a href="https://github.com/manvel79">@manvel79</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2997">2997</a></td> <td class="title">IMPERSONATECALL Opcode</td> <td class="author">Sergio Demian Lerner&nbsp;(<a href="https://github.com/SergioDemianLerner">@SergioDemianLerner</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3000">3000</a></td> <td class="title">Optimistic enactment governance standard</td> <td class="author">Jorge Izquierdo&nbsp;(<a href="https://github.com/izqui">@izqui</a>), Fabien Marino&nbsp;(<a href="https://github.com/bonustrack">@bonustrack</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3005">3005</a></td> <td class="title">Batched meta transactions</td> <td class="author">Matt&nbsp;(<a href="https://github.com/defifuture">@defifuture</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3014">3014</a></td> <td class="title">eth_symbol JSON-RPC method</td> <td class="author">Peter Grassberger&nbsp;(<a href="https://github.com/PeterTheOne">@PeterTheOne</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3026">3026</a></td> <td class="title">BW6-761 curve operations</td> <td class="author">Youssef El Housni&nbsp;(<a href="https://github.com/yelhousni">@yelhousni</a>), Michael Connor&nbsp;(<a href="https://github.com/iAmMichaelConnor">@iAmMichaelConnor</a>), Aurore Guillevic&nbsp;&lt;<a href="mailto:aurore.guillevic@inria.fr">aurore.guillevic@inria.fr</a>&gt;, hujw77&nbsp;(<a href="https://github.com/hujw77">@hujw77</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3030">3030</a></td> <td class="title">BLS Remote Signer HTTP API</td> <td class="author">Herman Junge&nbsp;(<a href="https://github.com/hermanjunge">@hermanjunge</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3041">3041</a></td> <td class="title">Adds `baseFee` to `eth_getBlockByHash`</td> <td class="author">Abdelhamid Bakhta&nbsp;(<a href="https://github.com/abdelhamidbakhta">@abdelhamidbakhta</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3044">3044</a></td> <td class="title">Adds `baseFee` to `eth_getBlockByNumber`</td> <td class="author">Abdelhamid Bakhta&nbsp;(<a href="https://github.com/abdelhamidbakhta">@abdelhamidbakhta</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3045">3045</a></td> <td class="title">Adds `baseFee` to `eth_getUncleByBlockHashAndIndex`</td> <td class="author">Abdelhamid Bakhta&nbsp;(<a href="https://github.com/abdelhamidbakhta">@abdelhamidbakhta</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3046">3046</a></td> <td class="title">Adds `baseFee` to `eth_getUncleByBlockNumberAndIndex`</td> <td class="author">Abdelhamid Bakhta&nbsp;(<a href="https://github.com/abdelhamidbakhta">@abdelhamidbakhta</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3068">3068</a></td> <td class="title">Precompile for BN256 HashToCurve Algorithms</td> <td class="author">Dr. Christopher Gorman&nbsp;(<a href="https://github.com/chgormanMH">@chgormanMH</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3085">3085</a></td> <td class="title">wallet_addEthereumChain RPC Method</td> <td class="author">Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>), Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>), Pandapip1&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3091">3091</a></td> <td class="title">Block Explorer API Routes</td> <td class="author">Pedro Gomes&nbsp;(<a href="https://github.com/pedrouid">@pedrouid</a>), ligi&nbsp;(<a href="https://github.com/ligi">@ligi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3102">3102</a></td> <td class="title">Binary trie structure</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3135">3135</a></td> <td class="title">Exclusive Claimable Token</td> <td class="author">Zhenyu Sun&nbsp;(<a href="https://github.com/Ungigdu">@Ungigdu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3143">3143</a></td> <td class="title">Increase block rewards to 5 ETH</td> <td class="author">Ben Tinner&nbsp;(<a href="https://github.com/Terra854">@Terra854</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3220">3220</a></td> <td class="title">Crosschain Identifier Specification</td> <td class="author">Weijia Zhang&nbsp;(<a href="https://github.com/weijia31415">@weijia31415</a>), Peter Robinson&nbsp;(<a href="https://github.com/drinkcoffee">@drinkcoffee</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3224">3224</a></td> <td class="title">Described Data</td> <td class="author">Richard Moore&nbsp;(<a href="https://github.com/ricmoo">@ricmoo</a>), Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3234">3234</a></td> <td class="title">Batch Flash Loans</td> <td class="author">Alberto Cuesta Cañada&nbsp;(<a href="https://github.com/albertocuestacanada">@albertocuestacanada</a>), Fiona Kobayashi&nbsp;(<a href="https://github.com/fifikobayashi">@fifikobayashi</a>), fubuloubu&nbsp;(<a href="https://github.com/fubuloubu">@fubuloubu</a>), Austin Williams&nbsp;(<a href="https://github.com/onewayfunction">@onewayfunction</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3238">3238</a></td> <td class="title">Difficulty Bomb Delay to Q2/2022</td> <td class="author">Afri Schoedon&nbsp;(<a href="https://github.com/q9f">@q9f</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3267">3267</a></td> <td class="title">Giving Ethereum fees to Future Salaries</td> <td class="author">Victor Porton&nbsp;(<a href="https://github.com/vporton">@vporton</a>), Victor Porton&nbsp;&lt;<a href="mailto:porton@narod.ru">porton@narod.ru</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3298">3298</a></td> <td class="title">Removal of refunds</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Martin Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3300">3300</a></td> <td class="title">Phase out refunds</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3322">3322</a></td> <td class="title">Account gas storage opcodes</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3326">3326</a></td> <td class="title">Wallet Switch Ethereum Chain RPC Method (`wallet_switchEthereumChain`)</td> <td class="author">Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3336">3336</a></td> <td class="title">Paged memory allocation for the EVM</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3337">3337</a></td> <td class="title">Frame pointer support for memory load and store operations</td> <td class="author">Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3368">3368</a></td> <td class="title">Increase block rewards to 3 ETH, with 2 Year Decay to 1 ETH Scheduled</td> <td class="author">Michael D. Carter&nbsp;(<a href="https://github.com/BitsBeTrippin">@BitsBeTrippin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3372">3372</a></td> <td class="title">5 FNV primes for ethash</td> <td class="author">mineruniter969&nbsp;(<a href="https://github.com/mineruniter969">@mineruniter969</a>), mineruniter969&nbsp;&lt;<a href="mailto:mineruniter969@tutanota.com">mineruniter969@tutanota.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3386">3386</a></td> <td class="title">ERC-721 and ERC-1155 to ERC-20 Wrapper</td> <td class="author">Calvin Koder&nbsp;(<a href="https://github.com/ashrowz">@ashrowz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3403">3403</a></td> <td class="title">Partial removal of refunds</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Martin Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3416">3416</a></td> <td class="title">Median Gas Premium</td> <td class="author">HexZorro&nbsp;(<a href="https://github.com/hexzorro">@hexzorro</a>), Mojtaba Tefagh&nbsp;(<a href="https://github.com/mtefagh">@mtefagh</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3436">3436</a></td> <td class="title">Expanded Clique Block Choice Rule</td> <td class="author">Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3440">3440</a></td> <td class="title">ERC-721 Editions Standard</td> <td class="author">Nathan Ginnever&nbsp;(<a href="https://github.com/nginnever">@nginnever</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3450">3450</a></td> <td class="title">Standardized Shamir Secret Sharing Scheme for BIP-39 Mnemonics</td> <td class="author">Daniel Streit&nbsp;(<a href="https://github.com/danielstreit">@danielstreit</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3455">3455</a></td> <td class="title">SUDO Opcode</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>), Baptiste Vauthey&nbsp;(<a href="https://github.com/thabaptiser">@thabaptiser</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3508">3508</a></td> <td class="title">Transaction Data Opcodes</td> <td class="author">Alex Papageorgiou&nbsp;(<a href="https://github.com/alex-ppg">@alex-ppg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3520">3520</a></td> <td class="title">Transaction Destination Opcode</td> <td class="author">Alex Papageorgiou&nbsp;(<a href="https://github.com/alex-ppg">@alex-ppg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3521">3521</a></td> <td class="title">Reduce access list cost</td> <td class="author">Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3534">3534</a></td> <td class="title">Restricted Chain Context Type Transactions</td> <td class="author">Isaac Ardis&nbsp;(<a href="https://github.com/whilei">@whilei</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3540">3540</a></td> <td class="title">EOF - EVM Object Format v1</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Piotr Dobaczewski&nbsp;(<a href="https://github.com/pdobacz">@pdobacz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3561">3561</a></td> <td class="title">Trust Minimized Upgradeability Proxy</td> <td class="author">Sam Porter&nbsp;(<a href="https://github.com/SamPorter1984">@SamPorter1984</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3569">3569</a></td> <td class="title">Sealed NFT Metadata Standard</td> <td class="author">Sean Papanikolas&nbsp;(<a href="https://github.com/pizzarob">@pizzarob</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3584">3584</a></td> <td class="title">Block Access List</td> <td class="author">Gajinder Singh&nbsp;(<a href="https://github.com/g11in">@g11in</a>), Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3589">3589</a></td> <td class="title">Assemble assets into NFTs</td> <td class="author">Zhenyu Sun&nbsp;(<a href="https://github.com/Ungigdu">@Ungigdu</a>), Xinqi Yang&nbsp;(<a href="https://github.com/xinqiyang">@xinqiyang</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3670">3670</a></td> <td class="title">EOF - Code Validation</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3690">3690</a></td> <td class="title">EOF - JUMPDEST Table</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3709">3709</a></td> <td class="title">Remove Support for Type 1 Transactions</td> <td class="author">Gregory Markou&nbsp;(<a href="https://github.com/GregTheGreek">@GregTheGreek</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3722">3722</a></td> <td class="title">Poster</td> <td class="author">Auryn Macmillan&nbsp;(<a href="https://github.com/auryn-macmillan">@auryn-macmillan</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3754">3754</a></td> <td class="title">A Vanilla Non-Fungible Token Standard</td> <td class="author">Simon Tian&nbsp;(<a href="https://github.com/simontianx">@simontianx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3756">3756</a></td> <td class="title">Gas Limit Cap</td> <td class="author">lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3772">3772</a></td> <td class="title">Compressed Integers</td> <td class="author">Soham Zemse&nbsp;(<a href="https://github.com/zemse">@zemse</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3788">3788</a></td> <td class="title">Strict enforcement of chainId</td> <td class="author">Gregory Markou&nbsp;(<a href="https://github.com/GregTheGreek">@GregTheGreek</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3978">3978</a></td> <td class="title">Gas refunds on reverts</td> <td class="author">Anton Bukov&nbsp;(<a href="https://github.com/k06a">@k06a</a>), Mikhail Melnik&nbsp;(<a href="https://github.com/ZumZoom">@ZumZoom</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4200">4200</a></td> <td class="title">EOF - Static relative jumps</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4341">4341</a></td> <td class="title">Ordered NFT Batch Standard</td> <td class="author">Simon Tian&nbsp;(<a href="https://github.com/simontianx">@simontianx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4353">4353</a></td> <td class="title">Interface for Staked Tokens in NFTs</td> <td class="author">Rex Creed&nbsp;(<a href="https://github.com/aug2uag">@aug2uag</a>), Dane Scarborough&nbsp;&lt;<a href="mailto:dane@nftapps.us">dane@nftapps.us</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4393">4393</a></td> <td class="title">Micropayments for NFTs and Multi Tokens</td> <td class="author">Jules Lai&nbsp;(<a href="https://github.com/julesl23">@julesl23</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4396">4396</a></td> <td class="title">Time-Aware Base Fee Calculation</td> <td class="author">Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4430">4430</a></td> <td class="title">Described Transactions</td> <td class="author">Richard Moore&nbsp;(<a href="https://github.com/ricmoo">@ricmoo</a>), Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4444">4444</a></td> <td class="title">Bound Historical Data in Execution Clients</td> <td class="author">George Kadianakis&nbsp;(<a href="https://github.com/asn-d6">@asn-d6</a>), lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4488">4488</a></td> <td class="title">Transaction calldata gas cost reduction with total calldata limit</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4494">4494</a></td> <td class="title">Permit for ERC-721 NFTs</td> <td class="author">Simon Fremaux&nbsp;(<a href="https://github.com/dievardump">@dievardump</a>), William Schwab&nbsp;(<a href="https://github.com/wschwab">@wschwab</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4520">4520</a></td> <td class="title">Multi-byte opcodes prefixed by EB and EC.</td> <td class="author">Brayton Goodall&nbsp;(<a href="https://github.com/Spore-Druid-Bray">@Spore-Druid-Bray</a>), Mihir Faujdar&nbsp;(<a href="https://github.com/uink45">@uink45</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4521">4521</a></td> <td class="title">721/20-compatible transfer</td> <td class="author">Ross Campbell&nbsp;(<a href="https://github.com/z0r0z">@z0r0z</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4524">4524</a></td> <td class="title">Safer ERC-20</td> <td class="author">William Schwab&nbsp;(<a href="https://github.com/wschwab">@wschwab</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4527">4527</a></td> <td class="title">QR Code transmission protocol for wallets</td> <td class="author">Aaron Chen&nbsp;(<a href="https://github.com/aaronisme">@aaronisme</a>), Sora Lee&nbsp;(<a href="https://github.com/soralit">@soralit</a>), ligi&nbsp;(<a href="https://github.com/ligi">@ligi</a>), Dan Miller&nbsp;(<a href="https://github.com/danjm">@danjm</a>), AndreasGassmann&nbsp;(<a href="https://github.com/andreasgassmann">@andreasgassmann</a>), xardass&nbsp;(<a href="https://github.com/xardass">@xardass</a>), Lixin Liu&nbsp;(<a href="https://github.com/BitcoinLixin">@BitcoinLixin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4546">4546</a></td> <td class="title">Wrapped Deposits</td> <td class="author">Justice Hudson&nbsp;(<a href="https://github.com/jchancehud">@jchancehud</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4573">4573</a></td> <td class="title">Procedures for the EVM</td> <td class="author">Greg Colvin&nbsp;(<a href="https://github.com/gcolvin">@gcolvin</a>), Greg Colvin&nbsp;&lt;<a href="mailto:greg@colvin.org">greg@colvin.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4671">4671</a></td> <td class="title">Non-Tradable Tokens Standard</td> <td class="author">Omar Aflak&nbsp;(<a href="https://github.com/omaraflak">@omaraflak</a>), Pol-Malo Le Bris, Marvin Martin&nbsp;(<a href="https://github.com/MarvinMartin24">@MarvinMartin24</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4675">4675</a></td> <td class="title">Multi-Fractional Non-Fungible Tokens</td> <td class="author">David Kim&nbsp;(<a href="https://github.com/powerstream3604">@powerstream3604</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4747">4747</a></td> <td class="title">Simplify EIP-161</td> <td class="author">Peter Davies&nbsp;(<a href="https://github.com/petertdavies">@petertdavies</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4750">4750</a></td> <td class="title">EOF - Functions</td> <td class="author">Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4758">4758</a></td> <td class="title">Deactivate SELFDESTRUCT</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4760">4760</a></td> <td class="title">SELFDESTRUCT bomb</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4799">4799</a></td> <td class="title">Non-Fungible Token Ownership Designation Standard</td> <td class="author">David Buckman&nbsp;(<a href="https://github.com/davidbuckman">@davidbuckman</a>), Isaac Buckman&nbsp;(<a href="https://github.com/isaacbuckman">@isaacbuckman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4803">4803</a></td> <td class="title">Limit transaction gas to a maximum of 2^63-1</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4863">4863</a></td> <td class="title">Beacon chain push withdrawals</td> <td class="author">Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4885">4885</a></td> <td class="title">Subscription NFTs and Multi Tokens</td> <td class="author">Jules Lai&nbsp;(<a href="https://github.com/julesl23">@julesl23</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4886">4886</a></td> <td class="title">Proxy Ownership Register</td> <td class="author">Omnus Sunmo&nbsp;(<a href="https://github.com/omnus">@omnus</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4931">4931</a></td> <td class="title">Generic Token Upgrade Standard</td> <td class="author">John Peterson&nbsp;(<a href="https://github.com/John-peterson-coinbase">@John-peterson-coinbase</a>), Roberto Bayardo&nbsp;(<a href="https://github.com/roberto-bayardo">@roberto-bayardo</a>), David Núñez&nbsp;(<a href="https://github.com/cygnusv">@cygnusv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4944">4944</a></td> <td class="title">Contract with Exactly One Non-fungible Token</td> <td class="author">Víctor Muñoz&nbsp;(<a href="https://github.com/victormunoz">@victormunoz</a>), Josep Lluis de la Rosa&nbsp;(<a href="https://github.com/peplluis7">@peplluis7</a>), Andres El-Fakdi&nbsp;(<a href="https://github.com/Bluezfish">@Bluezfish</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4950">4950</a></td> <td class="title">Entangled Tokens</td> <td class="author">Víctor Muñoz&nbsp;(<a href="https://github.com/victormunoz">@victormunoz</a>), Josep Lluis de la Rosa&nbsp;(<a href="https://github.com/peplluis7">@peplluis7</a>), Easy Innova&nbsp;(<a href="https://github.com/easyinnova">@easyinnova</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4974">4974</a></td> <td class="title">Ratings</td> <td class="author">Daniel Tedesco&nbsp;(<a href="https://github.com/dtedesco1">@dtedesco1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-4987">4987</a></td> <td class="title">Held token interface</td> <td class="author">Devin Conley&nbsp;(<a href="https://github.com/devinaconley">@devinaconley</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5000">5000</a></td> <td class="title">MULDIV instruction</td> <td class="author">Harikrishnan Mulackal&nbsp;(<a href="https://github.com/hrkrshnn">@hrkrshnn</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5005">5005</a></td> <td class="title">Zodiac Modular Accounts</td> <td class="author">Auryn Macmillan&nbsp;(<a href="https://github.com/auryn-macmillan">@auryn-macmillan</a>), Kei Kreutler&nbsp;(<a href="https://github.com/keikreutler">@keikreutler</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5018">5018</a></td> <td class="title">Filesystem-like Interface for Contracts</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5022">5022</a></td> <td class="title">Increase price of SSTORE from zero to non-zero to 40k gas</td> <td class="author">Green&nbsp;(<a href="https://github.com/greenlucid">@greenlucid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5027">5027</a></td> <td class="title">Remove the limit on contract code size</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5050">5050</a></td> <td class="title">Interactive NFTs with Modular Environments</td> <td class="author">Alexi&nbsp;(<a href="https://github.com/alexi">@alexi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5058">5058</a></td> <td class="title">Lockable Non-Fungible Tokens</td> <td class="author">Tyler&nbsp;(<a href="https://github.com/radiocaca">@radiocaca</a>), Alex&nbsp;(<a href="https://github.com/gojazdev">@gojazdev</a>), John&nbsp;(<a href="https://github.com/sfumato00">@sfumato00</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5065">5065</a></td> <td class="title">Instruction for transferring ether</td> <td class="author">Mudit Gupta&nbsp;(<a href="https://github.com/maxsam4">@maxsam4</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5081">5081</a></td> <td class="title">Expirable Transaction</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>), Nick Johnson&nbsp;(<a href="https://github.com/Arachnid">@Arachnid</a>), Konrad Feldmeier&nbsp;&lt;<a href="mailto:konrad@brainbot.com">konrad@brainbot.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5094">5094</a></td> <td class="title">URL Format for Ethereum Network Switching</td> <td class="author">Luc van Kampen&nbsp;(<a href="https://github.com/lucemans">@lucemans</a>), Jakob Helgesson&nbsp;(<a href="https://github.com/svemat01">@svemat01</a>), Joshua Hendrix&nbsp;(<a href="https://github.com/thejoshuahendrix">@thejoshuahendrix</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5095">5095</a></td> <td class="title">Principal Token</td> <td class="author">Julian Traversa&nbsp;(<a href="https://github.com/JTraversa">@JTraversa</a>), Robert Robbins&nbsp;(<a href="https://github.com/robrobbins">@robrobbins</a>), Alberto Cuesta Cañada&nbsp;(<a href="https://github.com/alcueca">@alcueca</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5131">5131</a></td> <td class="title">SAFE Authentication For ENS</td> <td class="author">Wilkins Chung (@wwhchung)&nbsp;&lt;<a href="mailto:wilkins@manifold.xyz">wilkins@manifold.xyz</a>&gt;, Jalil Wahdatehagh&nbsp;(<a href="https://github.com/jwahdatehagh">@jwahdatehagh</a>), Cry&nbsp;(<a href="https://github.com/crydoteth">@crydoteth</a>), Sillytuna&nbsp;(<a href="https://github.com/sillytuna">@sillytuna</a>), Cyberpnk&nbsp;(<a href="https://github.com/CyberpnkWin">@CyberpnkWin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5139">5139</a></td> <td class="title">Remote Procedure Call Provider Lists</td> <td class="author">Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5143">5143</a></td> <td class="title">Slippage Protection for Tokenized Vault</td> <td class="author">Hadrien Croubois&nbsp;(<a href="https://github.com/amxx">@amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5185">5185</a></td> <td class="title">NFT Updatable Metadata Extension</td> <td class="author">Christophe Le Bars&nbsp;(<a href="https://github.com/clbrge">@clbrge</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5187">5187</a></td> <td class="title">Extend EIP-1155 with rentable usage rights</td> <td class="author">DerivStudio&nbsp;(<a href="https://github.com/DerivStudio">@DerivStudio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5218">5218</a></td> <td class="title">NFT Rights Management</td> <td class="author">James Grimmelmann&nbsp;(<a href="https://github.com/grimmelm">@grimmelm</a>), Yan Ji&nbsp;(<a href="https://github.com/iseriohn">@iseriohn</a>), Tyler Kell&nbsp;(<a href="https://github.com/relyt29">@relyt29</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5252">5252</a></td> <td class="title">Account-bound Finance</td> <td class="author">Hyungsuk Kang&nbsp;(<a href="https://github.com/hskang9">@hskang9</a>), Viktor Pernjek&nbsp;(<a href="https://github.com/smuxx">@smuxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5283">5283</a></td> <td class="title">Semaphore for Reentrancy Protection</td> <td class="author">Sergio D. Lerner&nbsp;(<a href="https://github.com/SergioDemianLerner">@SergioDemianLerner</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5298">5298</a></td> <td class="title">ENS Trust to hold NFTs under ENS name</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5334">5334</a></td> <td class="title">EIP-721 User And Expires And Level Extension</td> <td class="author">Yan&nbsp;(<a href="https://github.com/yan253319066">@yan253319066</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5345">5345</a></td> <td class="title">Silent Signing Extension for JSON-RPC</td> <td class="author">Stanley Wu&nbsp;(<a href="https://github.com/fruit37">@fruit37</a>), Mücahit Büyükyılmaz&nbsp;(<a href="https://github.com/anndro">@anndro</a>), Muhammed Emin Aydın&nbsp;(<a href="https://github.com/muhammedea">@muhammedea</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5409">5409</a></td> <td class="title">EIP-1155 Non-Fungible Token extension</td> <td class="author">Ronan Sandford&nbsp;(<a href="https://github.com/wighawag">@wighawag</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5437">5437</a></td> <td class="title">Security Contact Interface</td> <td class="author">Zainan Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5450">5450</a></td> <td class="title">EOF - Stack Validation</td> <td class="author">Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5478">5478</a></td> <td class="title">CREATE2COPY Opcode</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5501">5501</a></td> <td class="title">Rental &amp; Delegation NFT - EIP-721 Extension</td> <td class="author">Jan Smrža&nbsp;(<a href="https://github.com/smrza">@smrza</a>), David Rábel&nbsp;(<a href="https://github.com/rabeles11">@rabeles11</a>), Tomáš Janča&nbsp;&lt;<a href="mailto:tomas.janca@jtbstorage.eu">tomas.janca@jtbstorage.eu</a>&gt;, Jan Bureš&nbsp;(<a href="https://github.com/JohnyX89">@JohnyX89</a>), DOBBYLABS&nbsp;(<a href="https://github.com/DOBBYLABS">@DOBBYLABS</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5505">5505</a></td> <td class="title">EIP-1155 asset backed NFT extension</td> <td class="author">liszechung&nbsp;(<a href="https://github.com/liszechung">@liszechung</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5539">5539</a></td> <td class="title">Revocation List Registry</td> <td class="author">Philipp Bolte&nbsp;(<a href="https://github.com/strumswell">@strumswell</a>), Lauritz Leifermann&nbsp;(<a href="https://github.com/lleifermann">@lleifermann</a>), Dennis von der Bey&nbsp;(<a href="https://github.com/DennisVonDerBey">@DennisVonDerBey</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5553">5553</a></td> <td class="title">Representing IP and its Royalty Structure</td> <td class="author">Roy Osherove&nbsp;(<a href="https://github.com/royosherove">@royosherove</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5554">5554</a></td> <td class="title">NFT Legal Use, Repurposing, and Remixing</td> <td class="author">Isaac Patka&nbsp;(<a href="https://github.com/ipatka">@ipatka</a>), COALA Licensing Taskforce&nbsp;&lt;<a href="mailto:info@coala.org">info@coala.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5559">5559</a></td> <td class="title">Cross Chain Write Deferral Protocol</td> <td class="author">Paul Gauvreau&nbsp;(<a href="https://github.com/0xpaulio">@0xpaulio</a>), Nick Johnson&nbsp;(<a href="https://github.com/arachnid">@arachnid</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5560">5560</a></td> <td class="title">Redeemable NFTs</td> <td class="author">Olivier Fernandez&nbsp;(<a href="https://github.com/fernandezOli">@fernandezOli</a>), Frédéric Le Coidic&nbsp;(<a href="https://github.com/FredLC29">@FredLC29</a>), Julien Béranger&nbsp;(<a href="https://github.com/julienbrg">@julienbrg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5593">5593</a></td> <td class="title">Restrict Ethereum Provider API Injection</td> <td class="author">Yan Zhu&nbsp;(<a href="https://github.com/diracdeltas">@diracdeltas</a>), Brian R. Bondy&nbsp;(<a href="https://github.com/bbondy">@bbondy</a>), Andrea Brancaleoni&nbsp;(<a href="https://github.com/thypon">@thypon</a>), Kyle Den Hartog&nbsp;(<a href="https://github.com/kdenhartog">@kdenhartog</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5633">5633</a></td> <td class="title">Composable Soulbound NFT, EIP-1155 Extension</td> <td class="author">HonorLabs&nbsp;(<a href="https://github.com/honorworldio">@honorworldio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5635">5635</a></td> <td class="title">NFT Licensing Agreements</td> <td class="author">Timi&nbsp;(<a href="https://github.com/0xTimi">@0xTimi</a>), 0xTriple7&nbsp;(<a href="https://github.com/ysqi">@ysqi</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5643">5643</a></td> <td class="title">Subscription NFTs</td> <td class="author">cygaar&nbsp;(<a href="https://github.com/cygaar">@cygaar</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5719">5719</a></td> <td class="title">Signature replacement interface</td> <td class="author">Agustin Aguilar&nbsp;(<a href="https://github.com/Agusx1211">@Agusx1211</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5744">5744</a></td> <td class="title">Latent Fungible Token</td> <td class="author">Cozy Finance&nbsp;(<a href="https://github.com/cozyfinance">@cozyfinance</a>), Tony Sheng&nbsp;(<a href="https://github.com/tonysheng">@tonysheng</a>), Matt Solomon&nbsp;(<a href="https://github.com/mds1">@mds1</a>), David Laprade&nbsp;(<a href="https://github.com/davidlaprade">@davidlaprade</a>), Payom Dousti&nbsp;(<a href="https://github.com/payomdousti">@payomdousti</a>), Chad Fleming&nbsp;(<a href="https://github.com/chad-js">@chad-js</a>), Franz Chen&nbsp;(<a href="https://github.com/Dendrimer">@Dendrimer</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5753">5753</a></td> <td class="title">Lockable Extension for EIP-721</td> <td class="author">Filipp Makarov&nbsp;(<a href="https://github.com/filmakarov">@filmakarov</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5805">5805</a></td> <td class="title">Voting with delegation</td> <td class="author">Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>), Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5806">5806</a></td> <td class="title">Delegate transaction</td> <td class="author">Hadrien Croubois&nbsp;(<a href="https://github.com/Amxx">@Amxx</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5827">5827</a></td> <td class="title">Auto-renewable allowance extension</td> <td class="author">zlace&nbsp;(<a href="https://github.com/zlace0x">@zlace0x</a>), zhongfu&nbsp;(<a href="https://github.com/zhongfu">@zhongfu</a>), edison0xyz&nbsp;(<a href="https://github.com/edison0xyz">@edison0xyz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5850">5850</a></td> <td class="title">Complex Numbers stored in `bytes32` types</td> <td class="author">Paul Edge&nbsp;(<a href="https://github.com/genkifs">@genkifs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5851">5851</a></td> <td class="title">On-Chain Verifiable Credentials</td> <td class="author">Yu Liu&nbsp;(<a href="https://github.com/yuliu-debond">@yuliu-debond</a>), Junyi Zhong&nbsp;(<a href="https://github.com/Jooeys">@Jooeys</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5883">5883</a></td> <td class="title">Token Transfer by Social Recovery</td> <td class="author">Erhard Dinhobl&nbsp;(<a href="https://github.com/mrqc">@mrqc</a>), Kevin Riedl&nbsp;(<a href="https://github.com/wsdt">@wsdt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5902">5902</a></td> <td class="title">Smart Contract Event Hooks</td> <td class="author">Simon Brown&nbsp;(<a href="https://github.com/orbmis">@orbmis</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5920">5920</a></td> <td class="title">PAY opcode</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>), Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5988">5988</a></td> <td class="title">Add Poseidon hash function precompile</td> <td class="author">Abdelhamid Bakhta&nbsp;(<a href="https://github.com/abdelhamidbakhta">@abdelhamidbakhta</a>), Eli Ben Sasson&nbsp;(<a href="https://github.com/Elistark">@Elistark</a>), Avihu Levy&nbsp;(<a href="https://github.com/avihu28">@avihu28</a>), David Levit Gurevich&nbsp;(<a href="https://github.com/DavidLevitGurevich">@DavidLevitGurevich</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6046">6046</a></td> <td class="title">Replace SELFDESTRUCT with DEACTIVATE</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6047">6047</a></td> <td class="title">ERC-721 Balance indexing via Transfer event</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6051">6051</a></td> <td class="title">Private Key Encapsulation</td> <td class="author">Base Labs&nbsp;(<a href="https://github.com/Base-Labs">@Base-Labs</a>), Weiji Guo&nbsp;(<a href="https://github.com/weiji-cryptonatty">@weiji-cryptonatty</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6188">6188</a></td> <td class="title">Nonce Cap</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6189">6189</a></td> <td class="title">Alias Contracts</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6190">6190</a></td> <td class="title">Verkle-compatible SELFDESTRUCT</td> <td class="author">Gavin John&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6206">6206</a></td> <td class="title">EOF - JUMPF and non-returning functions</td> <td class="author">Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6268">6268</a></td> <td class="title">Untransferability Indicator for EIP-1155</td> <td class="author">Yuki Aoki&nbsp;(<a href="https://github.com/yuki-js">@yuki-js</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6353">6353</a></td> <td class="title">Charity token</td> <td class="author">Aubay&nbsp;&lt;<a href="mailto:blockchain-team@aubay.com">blockchain-team@aubay.com</a>&gt;, BOCA Jeabby&nbsp;(<a href="https://github.com/bjeabby1507">@bjeabby1507</a>), EL MERSHATI Laith&nbsp;(<a href="https://github.com/lth-elm">@lth-elm</a>), KEMP Elia&nbsp;(<a href="https://github.com/eliakemp">@eliakemp</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6384">6384</a></td> <td class="title">Human-readable offline signatures</td> <td class="author">Tal Be'ery&nbsp;&lt;<a href="mailto:tal@zengo.com">tal@zengo.com</a>&gt;, RoiV&nbsp;(<a href="https://github.com/DeVaz1">@DeVaz1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6464">6464</a></td> <td class="title">Multi-operator, per-token ERC-721 approvals.</td> <td class="author">Cristian Espinoza&nbsp;(<a href="https://github.com/crisgarner">@crisgarner</a>), Simon Fremaux&nbsp;(<a href="https://github.com/dievardump">@dievardump</a>), David Huber&nbsp;(<a href="https://github.com/cxkoda">@cxkoda</a>), and Arran Schlosberg&nbsp;(<a href="https://github.com/aschlosberg">@aschlosberg</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6475">6475</a></td> <td class="title">SSZ Optional</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Zahary Karadjov&nbsp;(<a href="https://github.com/zah">@zah</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6506">6506</a></td> <td class="title">P2P Escrowed Governance Incentives</td> <td class="author">Josh Weintraub&nbsp;(<a href="https://github.com/jhweintraub">@jhweintraub</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6690">6690</a></td> <td class="title">EVM Modular Arithmetic Extensions</td> <td class="author">Jared Wasinger&nbsp;(<a href="https://github.com/jwasinger">@jwasinger</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Radosław Zagórowicz&nbsp;(<a href="https://github.com/rodiazet">@rodiazet</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6789">6789</a></td> <td class="title">Rename gas to mana</td> <td class="author">pcaversaccio&nbsp;(<a href="https://github.com/pcaversaccio">@pcaversaccio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6800">6800</a></td> <td class="title">Ethereum state using a unified verkle tree</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>), Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>), Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>), Gottfried Herold&nbsp;(<a href="https://github.com/GottfriedHerold">@GottfriedHerold</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Tanishq Jasoria&nbsp;(<a href="https://github.com/tanishqjasoria">@tanishqjasoria</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6810">6810</a></td> <td class="title">Ex Post Facto Cascading Revert</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6811">6811</a></td> <td class="title">To The Moon—10 Minute Blocks</td> <td class="author">Pandapip1&nbsp;(<a href="https://github.com/Pandapip1">@Pandapip1</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6873">6873</a></td> <td class="title">Preimage retention</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6888">6888</a></td> <td class="title">Arithmetic verification at EVM level</td> <td class="author">Renan Rodrigues de Souza&nbsp;(<a href="https://github.com/RenanSouza2">@RenanSouza2</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6914">6914</a></td> <td class="title">Reuse Withdrawn Validator Indices</td> <td class="author">Lion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6968">6968</a></td> <td class="title">Contract Secured Revenue on an EVM based L2</td> <td class="author">Zak Cole&nbsp;&lt;<a href="mailto:zak@numbergroup.xyz">zak@numbergroup.xyz</a>&gt;, Zak Cole&nbsp;(<a href="https://github.com/zscole">@zscole</a>), Kevin Owocki&nbsp;&lt;<a href="mailto:kevin@supermodular.xyz">kevin@supermodular.xyz</a>&gt;, lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6988">6988</a></td> <td class="title">Elected block proposer has not been slashed</td> <td class="author">Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7039">7039</a></td> <td class="title">Scheme-Handler Discovery Option for Wallets</td> <td class="author">Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7069">7069</a></td> <td class="title">Revamped CALL instructions</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7266">7266</a></td> <td class="title">Remove BLAKE2 compression precompile</td> <td class="author">pcaversaccio&nbsp;(<a href="https://github.com/pcaversaccio">@pcaversaccio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7377">7377</a></td> <td class="title">Migration Transaction</td> <td class="author">lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Sam Wilson&nbsp;(<a href="https://github.com/samwilsn">@samwilsn</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7378">7378</a></td> <td class="title">Add time-weighted averaging to the base fee</td> <td class="author">Guy Goren (@guy-goren)&nbsp;&lt;<a href="mailto:guy.nahsholim@gmail.com">guy.nahsholim@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7441">7441</a></td> <td class="title">Upgrade block proposer election to Whisk</td> <td class="author">George Kadianakis&nbsp;(<a href="https://github.com/asn-d6">@asn-d6</a>), Justin Drake&nbsp;(<a href="https://github.com/JustinDrake">@JustinDrake</a>), dapplion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7480">7480</a></td> <td class="title">EOF - Data section access instructions</td> <td class="author">Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7503">7503</a></td> <td class="title">Zero-Knowledge Wormholes</td> <td class="author">Keyvan Kambakhsh&nbsp;(<a href="https://github.com/keyvank">@keyvank</a>), Hamid Bateni&nbsp;(<a href="https://github.com/irnb">@irnb</a>), Amir Kahoori&nbsp;&lt;<a href="mailto:a.kahoorizadeh@gmail.com">a.kahoorizadeh@gmail.com</a>&gt;, Nobitex Labs&nbsp;&lt;<a href="mailto:labs@nobitex.ir">labs@nobitex.ir</a>&gt;, 0xwormhole&nbsp;(<a href="https://github.com/0xwormhole">@0xwormhole</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7519">7519</a></td> <td class="title">Atomic Storage Operations SCREDIT and SDEBIT</td> <td class="author">Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7543">7543</a></td> <td class="title">EVM arbitrary precision decimal math</td> <td class="author">1m1&nbsp;(<a href="https://github.com/1m1-github">@1m1-github</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7545">7545</a></td> <td class="title">Verkle proof verification precompile</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Diederik Loerakker&nbsp;(<a href="https://github.com/protolambda">@protolambda</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7547">7547</a></td> <td class="title">Inclusion lists</td> <td class="author">mike&nbsp;(<a href="https://github.com/michaelneuder">@michaelneuder</a>), Vitalik&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Francesco&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Terence&nbsp;(<a href="https://github.com/terencechain">@terencechain</a>), potuz&nbsp;(<a href="https://github.com/potuz">@potuz</a>), Manav&nbsp;(<a href="https://github.com/manav2401">@manav2401</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7557">7557</a></td> <td class="title">Block-level Warming with fair cost savings</td> <td class="author">Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7577">7577</a></td> <td class="title">Versioning Scheme for EIPs</td> <td class="author">danceratopz&nbsp;(<a href="https://github.com/danceratopz">@danceratopz</a>), Ahmad Bitar&nbsp;(<a href="https://github.com/smartprogrammer93">@smartprogrammer93</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7591">7591</a></td> <td class="title">BLS signed transactions</td> <td class="author">Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7609">7609</a></td> <td class="title">Decrease base cost of TLOAD/TSTORE</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>), James Prestwich&nbsp;(<a href="https://github.com/prestwich">@prestwich</a>), brockelmore&nbsp;(<a href="https://github.com/brockelmore">@brockelmore</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7612">7612</a></td> <td class="title">Verkle state transition via an overlay tree</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Gottfried Herold&nbsp;(<a href="https://github.com/GottfriedHerold">@GottfriedHerold</a>), Jamie Lokier&nbsp;(<a href="https://github.com/jlokier">@jlokier</a>), Tanishq Jasoria&nbsp;(<a href="https://github.com/tanishqjasoria">@tanishqjasoria</a>), Parithosh Jayanthi&nbsp;(<a href="https://github.com/parithosh">@parithosh</a>), Gabriel Rocheleau&nbsp;(<a href="https://github.com/gabrocheleau">@gabrocheleau</a>), Karim Taam&nbsp;(<a href="https://github.com/matkt">@matkt</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7620">7620</a></td> <td class="title">EOF Contract Creation</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Piotr Dobaczewski&nbsp;(<a href="https://github.com/pdobacz">@pdobacz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7637">7637</a></td> <td class="title">Optimize EOA EXTCODEHASH</td> <td class="author">Jame&nbsp;(<a href="https://github.com/ZWJKFLC">@ZWJKFLC</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7639">7639</a></td> <td class="title">eth/70 - Cease serving history before PoS</td> <td class="author">lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7643">7643</a></td> <td class="title">History accumulator for pre-PoS data</td> <td class="author">lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), kdeme&nbsp;(<a href="https://github.com/kdeme">@kdeme</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7645">7645</a></td> <td class="title">Alias ORIGIN to SENDER</td> <td class="author">Cyrus Adkisson&nbsp;(<a href="https://github.com/cyrusadkisson">@cyrusadkisson</a>), Eirik Ulversøy&nbsp;(<a href="https://github.com/EirikUlversoy">@EirikUlversoy</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7650">7650</a></td> <td class="title">Programmable access lists</td> <td class="author">Qi Zhou&nbsp;(<a href="https://github.com/qizhou">@qizhou</a>), Zhiqiang Xu&nbsp;(<a href="https://github.com/zhiqiangxu">@zhiqiangxu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7657">7657</a></td> <td class="title">Sync committee slashings</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7658">7658</a></td> <td class="title">Light client data backfill</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7666">7666</a></td> <td class="title">EVM-ify the identity precompile</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7667">7667</a></td> <td class="title">Raise gas costs of hash functions</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7668">7668</a></td> <td class="title">Remove bloom filters</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7676">7676</a></td> <td class="title">EOF - Prepare for Address Space Extension</td> <td class="author">Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7684">7684</a></td> <td class="title">Return deposits for distinct credentials</td> <td class="author">Lion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7686">7686</a></td> <td class="title">Linear EVM memory limits</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7692">7692</a></td> <td class="title">EVM Object Format (EOFv1) Meta</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Piotr Dobaczewski&nbsp;(<a href="https://github.com/pdobacz">@pdobacz</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7698">7698</a></td> <td class="title">EOF - Creation transaction</td> <td class="author">Piotr Dobaczewski&nbsp;(<a href="https://github.com/pdobacz">@pdobacz</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7701">7701</a></td> <td class="title">Native Account Abstraction</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>), Dror Tirosh&nbsp;(<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson&nbsp;(<a href="https://github.com/shahafn">@shahafn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7703">7703</a></td> <td class="title">Increase calldata cost</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7705">7705</a></td> <td class="title">NONREENTRANT and REENTRANT opcodes</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7706">7706</a></td> <td class="title">Separate gas type for calldata</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7707">7707</a></td> <td class="title">Incentivize Access List Provisioning</td> <td class="author">Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>), Oleg Iakushkin&nbsp;(<a href="https://github.com/OlegJakushkin">@OlegJakushkin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7709">7709</a></td> <td class="title">Read BLOCKHASH from storage and update cost</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Tomasz Stanczak&nbsp;(<a href="https://github.com/tkstanczak">@tkstanczak</a>), Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Tanishq Jasoria&nbsp;(<a href="https://github.com/tanishqjasoria">@tanishqjasoria</a>), Ignacio Hagopian&nbsp;(<a href="https://github.com/jsign">@jsign</a>), Jochem Brouwer&nbsp;(<a href="https://github.com/jochem-brouwer">@jochem-brouwer</a>), Gabriel Rocheleau&nbsp;(<a href="https://github.com/gabrocheleau">@gabrocheleau</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7713">7713</a></td> <td class="title">Box type for EIP-712 messages</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7716">7716</a></td> <td class="title">Anti-correlation attestation penalties</td> <td class="author">dapplion&nbsp;(<a href="https://github.com/dapplion">@dapplion</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7727">7727</a></td> <td class="title">EVM Transaction Bundles</td> <td class="author">Lily Johnson&nbsp;(<a href="https://github.com/lilyjjo">@lilyjjo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7736">7736</a></td> <td class="title">Leaf-level state expiry in verkle trees</td> <td class="author">Guillaume Ballet&nbsp;(<a href="https://github.com/gballet">@gballet</a>), Wei Han Ng&nbsp;(<a href="https://github.com/weiihann">@weiihann</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7742">7742</a></td> <td class="title">Uncouple blob count between CL and EL</td> <td class="author">Alex Stokes&nbsp;(<a href="https://github.com/ralexstokes">@ralexstokes</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7756">7756</a></td> <td class="title">EOF/EVM Trace Specification</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), Marius van der Wijden&nbsp;(<a href="https://github.com/MariusVanDerWijden">@MariusVanDerWijden</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7761">7761</a></td> <td class="title">EXTCODETYPE instruction</td> <td class="author">Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Piotr Dobaczewski&nbsp;(<a href="https://github.com/pdobacz">@pdobacz</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7762">7762</a></td> <td class="title">Increase MIN_BASE_FEE_PER_BLOB_GAS</td> <td class="author">Max Resnick&nbsp;(<a href="https://github.com/MaxResnick">@MaxResnick</a>), Davide Crapis&nbsp;(<a href="https://github.com/dcrapis">@dcrapis</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7768">7768</a></td> <td class="title">No-Ether transactions with free-for-all tips</td> <td class="author">William Entriken&nbsp;(<a href="https://github.com/fulldecent">@fulldecent</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7775">7775</a></td> <td class="title">BURN opcode</td> <td class="author">Dev Bear&nbsp;(<a href="https://github.com/itsdevbear">@itsdevbear</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7783">7783</a></td> <td class="title">Add Controlled Gas Limit Increase Strategy</td> <td class="author">Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7784">7784</a></td> <td class="title">GETCONTRACT opcode</td> <td class="author">Tim Pechersky&nbsp;(<a href="https://github.com/peersky">@peersky</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7790">7790</a></td> <td class="title">Controlled Gas Limit Increase Guidelines</td> <td class="author">Giulio Rebuffo&nbsp;(<a href="https://github.com/Giulio2002">@Giulio2002</a>), Ben Adams&nbsp;(<a href="https://github.com/benaadams">@benaadams</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7792">7792</a></td> <td class="title">Verifiable logs</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>), Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7793">7793</a></td> <td class="title">Conditional Transactions</td> <td class="author">Marc Harvey-Hill&nbsp;(<a href="https://github.com/Marchhill">@Marchhill</a>), Ahmad Bitar&nbsp;(<a href="https://github.com/smartprogrammer93">@smartprogrammer93</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7797">7797</a></td> <td class="title">Double speed for hash_tree_root</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7808">7808</a></td> <td class="title">Reserve Tx-Type Range for RIPs</td> <td class="author">Carl Beekhuizen&nbsp;(<a href="https://github.com/carlbeek">@carlbeek</a>), Yoav Weiss&nbsp;(<a href="https://github.com/yoavw">@yoavw</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7830">7830</a></td> <td class="title">Contract size limit increase for EOF</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7833">7833</a></td> <td class="title">Scheduled function calls</td> <td class="author">Keyvan Kambakhsh&nbsp;(<a href="https://github.com/keyvank">@keyvank</a>), Nobitex Labs&nbsp;&lt;<a href="mailto:labs@nobitex.ir">labs@nobitex.ir</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7867">7867</a></td> <td class="title">Flow Control Wallet Call Capability</td> <td class="author">Sam Wilson (@SamWilsn)&nbsp;&lt;<a href="mailto:sam@binarycake.ca">sam@binarycake.ca</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7873">7873</a></td> <td class="title">EOF - TXCREATE and InitcodeTransaction type</td> <td class="author">Piotr Dobaczewski&nbsp;(<a href="https://github.com/pdobacz">@pdobacz</a>), Andrei Maiboroda&nbsp;(<a href="https://github.com/gumb0">@gumb0</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>), Danno Ferrin&nbsp;(<a href="https://github.com/shemnon">@shemnon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7877">7877</a></td> <td class="title">Enhanced RETURN opcodes</td> <td class="author">Josh Weintraub&nbsp;(<a href="https://github.com/jhweintraub">@jhweintraub</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7886">7886</a></td> <td class="title">Delayed execution</td> <td class="author">Francesco D'Amato&nbsp;(<a href="https://github.com/fradamt">@fradamt</a>), Toni Wahrstätter&nbsp;(<a href="https://github.com/nerolation">@nerolation</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7889">7889</a></td> <td class="title">Emit log on revert</td> <td class="author">Shoham Chakraborty&nbsp;(<a href="https://github.com/shohamc1">@shohamc1</a>), Alex Forshtat&nbsp;(<a href="https://github.com/forshtat">@forshtat</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7896">7896</a></td> <td class="title">ABI attachment in `wallet_sendCalls`</td> <td class="author">Francisco Giordano&nbsp;(<a href="https://github.com/frangio">@frangio</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7898">7898</a></td> <td class="title">Uncouple execution payload from beacon block</td> <td class="author">Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7903">7903</a></td> <td class="title">Remove Initcode Size Limit</td> <td class="author">Charles Cooper&nbsp;(<a href="https://github.com/charles-cooper">@charles-cooper</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7912">7912</a></td> <td class="title">Pragmatic stack manipulation tools</td> <td class="author">lightclient&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7915">7915</a></td> <td class="title">Adaptive mean reversion blob pricing</td> <td class="author">Anders Elowsson&nbsp;(<a href="https://github.com/anderselowsson">@anderselowsson</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7919">7919</a></td> <td class="title">Pureth Meta</td> <td class="author">Etan Kissling&nbsp;(<a href="https://github.com/etan-status">@etan-status</a>), Gajinder Singh&nbsp;(<a href="https://github.com/g11tech">@g11tech</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7921">7921</a></td> <td class="title">Skip `JUMPDEST` immediate argument check</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7922">7922</a></td> <td class="title">Dynamic exit queue rate limit</td> <td class="author">Mikhail Kalinin&nbsp;(<a href="https://github.com/mkalinin">@mkalinin</a>), Mike Neuder&nbsp;(<a href="https://github.com/michaelneuder">@michaelneuder</a>), Mallesh Pai&nbsp;(<a href="https://github.com/Mmp610">@Mmp610</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7927">7927</a></td> <td class="title">History Expiry Meta</td> <td class="author">Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7938">7938</a></td> <td class="title">Exponential Gas Limit Increase</td> <td class="author">Dankrad Feist&nbsp;(<a href="https://github.com/dankrad">@dankrad</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7956">7956</a></td> <td class="title">Tx Ordering via Block-level Randomness</td> <td class="author">Aryaethn&nbsp;(<a href="https://github.com/aryaethn">@aryaethn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7957">7957</a></td> <td class="title">EVM64 - EOF support</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7958">7958</a></td> <td class="title">EVM64 - Little endian opcodes</td> <td class="author">Wei Tang&nbsp;(<a href="https://github.com/sorpaas">@sorpaas</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8012">8012</a></td> <td class="title">Generalized consolidation requests</td> <td class="author">Potuz&nbsp;(<a href="https://github.com/potuz">@potuz</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8015">8015</a></td> <td class="title">Remove `deposit` and `eth1data` fields</td> <td class="author">Terence&nbsp;(<a href="https://github.com/terencechain">@terencechain</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8025">8025</a></td> <td class="title">Optional Execution Proofs</td> <td class="author">Kevaundray Wedderburn&nbsp;(<a href="https://github.com/kevaundray">@kevaundray</a>), Justin Drake (@JustinDrake)&nbsp;&lt;<a href="mailto:justin@ethereum.org">justin@ethereum.org</a>&gt;</td> </tr> </table> <h2 id="withdrawn">Withdrawn</h2> <table class="eiptable"> <thead> <tr> <th class="eipnum">Number</th><th class="withdrawn-reason">Withdrawn Reason</th><th class="title">Title</th><th class="author">Author</th></tr> </thead> <tr> <td class="eipnum"><a href="/EIPS/eip-3">3</a></td> <td class="withdrawn-reason"></td> <td class="title">Addition of CALLDEPTH opcode</td> <td class="author">Martin Holst Swende&nbsp;&lt;<a href="mailto:martin@swende.se">martin@swende.se</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-67">67</a></td> <td class="withdrawn-reason">Superseded by EIP-681</td> <td class="title">URI Scheme with Metadata, Value and Bytecode</td> <td class="author">Alex Van de Sande&nbsp;(<a href="https://github.com/alexvansande">@alexvansande</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-875">875</a></td> <td class="withdrawn-reason"></td> <td class="title">Simpler NFT standard with batching and native atomic swaps</td> <td class="author">Weiwu Zhang&nbsp;&lt;<a href="mailto:a@colourful.land">a@colourful.land</a>&gt;, James Sangalli&nbsp;&lt;<a href="mailto:j.l.sangalli@gmail.com">j.l.sangalli@gmail.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-908">908</a></td> <td class="withdrawn-reason"></td> <td class="title">Reward clients for a sustainable network</td> <td class="author">James Ray&nbsp;(<a href="https://github.com/jamesray1">@jamesray1</a>), Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-999">999</a></td> <td class="withdrawn-reason"></td> <td class="title">Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</td> <td class="author">Afri Schoedon&nbsp;(<a href="https://github.com/5chdn">@5chdn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1123">1123</a></td> <td class="withdrawn-reason"></td> <td class="title">Revised Ethereum Smart Contract Packaging Standard</td> <td class="author">g. nicholas d’andrea&nbsp;(<a href="https://github.com/gnidan">@gnidan</a>), Piper Merriam&nbsp;(<a href="https://github.com/pipermerriam">@pipermerriam</a>), Nick Gheorghita&nbsp;(<a href="https://github.com/njgheorghita">@njgheorghita</a>), Danny Ryan&nbsp;(<a href="https://github.com/djrtwo">@djrtwo</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1154">1154</a></td> <td class="withdrawn-reason"></td> <td class="title">Oracle Interface</td> <td class="author">Alan Lu&nbsp;(<a href="https://github.com/cag">@cag</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1240">1240</a></td> <td class="withdrawn-reason"></td> <td class="title">Remove Difficulty Bomb</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1355">1355</a></td> <td class="withdrawn-reason"></td> <td class="title">Ethash 1a</td> <td class="author">Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Jean M. Cyr&nbsp;(<a href="https://github.com/jean-m-cyr">@jean-m-cyr</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1538">1538</a></td> <td class="withdrawn-reason"></td> <td class="title">Transparent Contract Standard</td> <td class="author">Nick Mudge&nbsp;&lt;<a href="mailto:nick@perfectabstractions.com">nick@perfectabstractions.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1682">1682</a></td> <td class="withdrawn-reason"></td> <td class="title">Storage Rent</td> <td class="author">Felix J Lange&nbsp;(<a href="https://github.com/fjl">@fjl</a>), Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1706">1706</a></td> <td class="withdrawn-reason">The authors prefer [EIP-2200](./eip-2200.md)</td> <td class="title">Disable SSTORE with gasleft lower than call stipend</td> <td class="author">Alex Forshtat&nbsp;&lt;<a href="mailto:alex@tabookey.com">alex@tabookey.com</a>&gt;, Yoav Weiss&nbsp;&lt;<a href="mailto:yoav@tabookey.com">yoav@tabookey.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-1890">1890</a></td> <td class="withdrawn-reason"></td> <td class="title">Commitment to Sustainable Ecosystem Funding</td> <td class="author">Gregory Markou&nbsp;&lt;<a href="mailto:greg@chainsafe.io">greg@chainsafe.io</a>&gt;, Kevin Owocki&nbsp;&lt;<a href="mailto:kevin@gitcoin.co">kevin@gitcoin.co</a>&gt;, Lane Rettig&nbsp;&lt;<a href="mailto:lane@ethereum.org">lane@ethereum.org</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2025">2025</a></td> <td class="withdrawn-reason"></td> <td class="title">Block Rewards Proposal for funding Eth1.x</td> <td class="author">James Hancock&nbsp;(<a href="https://github.com/madeoftin">@madeoftin</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2070">2070</a></td> <td class="withdrawn-reason"></td> <td class="title">Hardfork Meta: Berlin</td> <td class="author">Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2315">2315</a></td> <td class="withdrawn-reason">This proposal has been superseded by the EOF proposals.</td> <td class="title">Simple Subroutines for the EVM</td> <td class="author">Greg Colvin&nbsp;(<a href="https://github.com/gcolvin">@gcolvin</a>), Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), Brooklyn Zelenka&nbsp;(<a href="https://github.com/expede">@expede</a>), John Max Skaller&nbsp;&lt;<a href="mailto:skaller@internode.on.net">skaller@internode.on.net</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2458">2458</a></td> <td class="withdrawn-reason"></td> <td class="title">Updates and Updated-by Header</td> <td class="author">Edson Ayllon&nbsp;(<a href="https://github.com/edsonayllon">@edsonayllon</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2677">2677</a></td> <td class="withdrawn-reason">Replaced by EIP-3860.</td> <td class="title">Limit size of `initcode`</td> <td class="author">Martin Holst Swende&nbsp;(<a href="https://github.com/holiman">@holiman</a>), Paweł Bylica&nbsp;(<a href="https://github.com/chfast">@chfast</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2711">2711</a></td> <td class="withdrawn-reason"></td> <td class="title">Sponsored, expiring and batch transactions.</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2733">2733</a></td> <td class="withdrawn-reason">I have decided to pursue EIP-3074 as the preferred solution to transaction packages.</td> <td class="title">Transaction Package</td> <td class="author">Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2786">2786</a></td> <td class="withdrawn-reason"></td> <td class="title">Ethereum Provider Connect/Disconnect Events</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>), Erik Marks&nbsp;(<a href="https://github.com/rekmarks">@rekmarks</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2938">2938</a></td> <td class="withdrawn-reason">Very out of date; needs rewrite.</td> <td class="title">Account Abstraction</td> <td class="author">Vitalik Buterin&nbsp;(<a href="https://github.com/vbuterin">@vbuterin</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Will Villanueva&nbsp;(<a href="https://github.com/villanuevawill">@villanuevawill</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-2972">2972</a></td> <td class="withdrawn-reason"></td> <td class="title">Wrapped Legacy Transactions</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3074">3074</a></td> <td class="withdrawn-reason">Superseded by EIP-7702</td> <td class="title">AUTH and AUTHCALL opcodes</td> <td class="author">Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>), Ansgar Dietrichs&nbsp;(<a href="https://github.com/adietrichs">@adietrichs</a>), Matt Garnett&nbsp;(<a href="https://github.com/lightclient">@lightclient</a>), Micah Zoltu&nbsp;(<a href="https://github.com/micahzoltu">@micahzoltu</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3332">3332</a></td> <td class="withdrawn-reason"></td> <td class="title">MEDGASPRICE Opcode</td> <td class="author">Justice Hudson&nbsp;(<a href="https://github.com/jchancehud">@jchancehud</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3338">3338</a></td> <td class="withdrawn-reason">Withdrawn in favor of [EIP-2681](./eip-2681.md)</td> <td class="title">Limit account nonce to 2^52</td> <td class="author">Micah Zoltu&nbsp;(<a href="https://github.com/MicahZoltu">@MicahZoltu</a>), Alex Beregszaszi&nbsp;(<a href="https://github.com/axic">@axic</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3374">3374</a></td> <td class="withdrawn-reason"></td> <td class="title">Predictable Proof-of-Work (POW) Sunsetting</td> <td class="author">Query0x&nbsp;(<a href="https://github.com/Query0x">@Query0x</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3382">3382</a></td> <td class="withdrawn-reason">The author prefers [EIP-3756](./eip-3756.md)</td> <td class="title">Hardcoded Block Gas Limit</td> <td class="author">Philippe Castonguay&nbsp;(<a href="https://github.com/PhABC">@PhABC</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-3779">3779</a></td> <td class="withdrawn-reason">material moved to EIP-2315</td> <td class="title">Safer Control Flow for the EVM</td> <td class="author">Greg Colvin&nbsp;(<a href="https://github.com/gcolvin">@gcolvin</a>), Greg Colvin&nbsp;&lt;<a href="mailto:greg@colvin.org">greg@colvin.org</a>&gt;, Brooklyn Zelenka&nbsp;(<a href="https://github.com/expede">@expede</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-5003">5003</a></td> <td class="withdrawn-reason">Superseded by EIP-7702.</td> <td class="title">Insert Code into EOAs with AUTHUSURP</td> <td class="author">Dan Finlay&nbsp;(<a href="https://github.com/danfinlay">@danfinlay</a>), Sam Wilson&nbsp;(<a href="https://github.com/SamWilsn">@SamWilsn</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-6913">6913</a></td> <td class="withdrawn-reason">The author prefers EIP-7702</td> <td class="title">SETCODE instruction</td> <td class="author">William Morriss&nbsp;(<a href="https://github.com/wjmelements">@wjmelements</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7199">7199</a></td> <td class="withdrawn-reason">Policy is documented in EIP-1 and EIP-5069.</td> <td class="title">Linter Scope</td> <td class="author">Zainan Victor Zhou&nbsp;(<a href="https://github.com/xinbenlv">@xinbenlv</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7542">7542</a></td> <td class="withdrawn-reason"></td> <td class="title">eth/70 - available-blocks-extended protocol</td> <td class="author">Ahmad Bitar (@smartprogrammer93)&nbsp;&lt;<a href="mailto:smartprogrammer@windowslive.com">smartprogrammer@windowslive.com</a>&gt;</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7636">7636</a></td> <td class="withdrawn-reason">Lack of use and conflicts with some client developers regarding its practicality</td> <td class="title">Extension of EIP-778 for &quot;client&quot; ENR Entry</td> <td class="author">James Kempton&nbsp;(<a href="https://github.com/SirSpudlington">@SirSpudlington</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7664">7664</a></td> <td class="withdrawn-reason">Niche use-case, better implemented with EIP-7702.</td> <td class="title">Access-Key opcode</td> <td class="author">Diederik Loerakker&nbsp;(<a href="https://github.com/protolambda">@protolambda</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7675">7675</a></td> <td class="withdrawn-reason">Is a list of EIPs that will never move to Final.</td> <td class="title">Retroactively Included EIPs</td> <td class="author">Tim Beiko&nbsp;(<a href="https://github.com/timbeiko">@timbeiko</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7788">7788</a></td> <td class="withdrawn-reason"></td> <td class="title">Dynamic target blob count</td> <td class="author">Marc Harvey-Hill&nbsp;(<a href="https://github.com/Marchhill">@Marchhill</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7897">7897</a></td> <td class="withdrawn-reason"></td> <td class="title">Wallet-Linked Services for Smart Accounts</td> <td class="author">Francesco Sullo&nbsp;(<a href="https://github.com/sullof">@sullof</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-7980">7980</a></td> <td class="withdrawn-reason">Decision to use P256 as the test algorithm to reduce implementation burden</td> <td class="title">Ed25519 transaction support</td> <td class="author">James Kempton&nbsp;(<a href="https://github.com/SirSpudlington">@SirSpudlington</a>)</td> </tr> <tr> <td class="eipnum"><a href="/EIPS/eip-8109">8109</a></td> <td class="withdrawn-reason">Superseded by EIP-8153</td> <td class="title">Diamonds, Simplified</td> <td class="author">Nick Mudge&nbsp;(<a href="https://github.com/mudgen">@mudgen</a>)</td> </tr> </table> https://eips.ethereum.org/all https://eips.ethereum.org/all / <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Ethereum EIPs</title> <description>A feed of all EIPs</description> <link>{{ site.url }}</link> <atom:link href="{{ site.url }}/all.xml" rel="self" type="application/rss+xml" /> <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate> {% assign eips = site.pages | sort: 'eip' %} {% for eip in eips %} <item> <title>{{ eip.title | xml_escape }}</title> <category>{{ eip.type | xml_escape }}/{{ eip.category | xml_escape }}</category> {% if eip.discussions-to %} <comments>{{ eip.discussions-to | xml_escape }}</comments> {% endif %} <description>{{ eip.content | xml_escape }}</description> <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate> <link>{{ site.url }}{{ eip.url }}</link> <guid isPermaLink="true">{{ site.url }}{{ eip.url }}</guid> </item> {% endfor %} </channel> </rss> https://eips.ethereum.org/rss/all.xml https://eips.ethereum.org/rss/all.xml Core / {% assign eips=site.pages|where:"type","Standards Track"|where:"category","Core" %} {% include eiptable.html eips=eips %} https://eips.ethereum.org/core https://eips.ethereum.org/core / <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Ethereum EIPs - Last Call Review</title> <description>All EIPs which are in the "last call" status, please help review these and provide your feedback!</description> <link>{{ site.url }}</link> <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" /> <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate> {% assign eips = site.pages | sort: 'eip' %} {% for eip in eips %} {% if eip.category == "ERC" %} {% if eip.status == "Last Call" %} {% capture description %} <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p> {% if eip.discussions-to %} <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p> {% endif %} <hr /> {{ eip.content }} {% endcapture %} <item> <title>{{ eip.title | xml_escape }}</title> <description>{{ description | xml_escape }}</description> <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate> <link>{{ site.url }}/{{ eip.url }}</link> <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid> </item> {% endif %} {% endif %} {% endfor %} </channel> </rss> https://eips.ethereum.org/rss/erc-last-call.xml https://eips.ethereum.org/rss/erc-last-call.xml ERC / {% assign eips=site.pages|where:"type","Standards Track"|where:"category","ERC" %} {% include eiptable.html eips=eips %} https://eips.ethereum.org/erc https://eips.ethereum.org/erc / <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Ethereum ERCs</title> <description>All updates for ERCs</description> <link>{{ site.url }}</link> <atom:link href="{{ site.url }}/rss/erc.xml" rel="self" type="application/rss+xml" /> <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate> {% assign eips = site.pages | sort: 'eip' %} {% for eip in eips %} {% if eip.category == "ERC" %} {% capture description %} <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in the {{ eip.category }} category of type {{ eip.type }} and was just updated.</p> {% if eip.discussions-to %} <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p> {% endif %} <hr /> {{ eip.content }} {% endcapture %} <item> <title>{{ eip.title | xml_escape }}</title> <description>{{ description | xml_escape }}</description> <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate> <link>{{ site.url }}/{{ eip.url }}</link> <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid> </item> {% endif %} {% endfor %} </channel> </rss> https://eips.ethereum.org/rss/erc.xml https://eips.ethereum.org/rss/erc.xml Home / <h1 class="page-heading">EIPs <a href="https://discord.gg/Nz6rtfJ8Cu"><img src="https://dcbadge.limes.pink/api/server/Nz6rtfJ8Cu?style=flat" alt="Discord channel for ECH eip-editer"></a> <a href="https://discord.gg/EVTQ9crVgQ"><img src="https://dcbadge.limes.pink/api/server/EVTQ9crVgQ?style=flat" alt="Discord channel for Eth R&D eip-editing"></a> <a href="https://discord.gg/mRzPXmmYEA"><img src="https://dcbadge.limes.pink/api/server/mRzPXmmYEA?style=flat" alt="Discord server for discussions about proposals that impact Ethereum wallets"></a> <a href="rss/all.xml"><img src="https://img.shields.io/badge/rss-Everything-red.svg" alt="RSS"></a> <a href="rss/last-call.xml"><img src="https://img.shields.io/badge/rss-Last Calls-red.svg" alt="RSS"></a> <a href="rss/nonerc.xml"><img src="https://img.shields.io/badge/rss-All except ERC-red.svg" alt="RSS"></a> <a href="https://eepurl.com/ikqNIP"><img src="https://img.shields.io/badge/-email%20alerts-red.svg" alt="RSS"></a> </h1> <p>Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the <a target="_blank" href="https://github.com/ethereum/pm/">Ethereum Project Management</a> repository.</p> <h2>Contributing</h2> <p>First review <a href="EIPS/eip-1">EIP-1</a>. Then clone the repository and add your EIP to it. There is a <a href="https://github.com/ethereum/EIPs/blob/master/eip-template.md?plain=1">template EIP here</a>. Then submit a Pull Request to Ethereum's <a href="https://github.com/ethereum/EIPs">EIPs repository</a>.</p> <h2>EIP status terms</h2> <ul> <li><strong>Idea</strong> - An idea that is pre-draft. This is not tracked within the EIP Repository. <li><strong>Draft</strong> - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.</li> <li><strong>Review</strong> - An EIP Author marks an EIP as ready for and requesting Peer Review.</li> <li><strong>Last Call</strong> - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.</li> <li><strong>Final</strong> - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.</li> <li><strong>Stagnant</strong> - Any EIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft.</li> <li><strong>Withdrawn</strong> - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.</li> <li><strong>Living</strong> - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.</li> </ul> <h2>EIP Types</h2> <p>EIPs are separated into a number of types, and each has its own list of EIPs.</p> <h3>Standards Track ({{site.pages|where:"type","Standards Track"|size}})</h3> <p>Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.</p> <h4><a href="{{"core"|relative_url}}">Core</a> ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})</h4> <p>Improvements requiring a consensus fork (e.g. <a href="./EIPS/eip-5">EIP-5</a>, <a href="./EIPS/eip-211">EIP-211</a>), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in <a href="./EIPS/eip-225">EIP-225</a>).</p> <h4><a href="{{"networking"|relative_url}}">Networking</a> ({{site.pages|where:"type","Standards Track"|where:"category","Networking"|size}})</h4> <p>Includes improvements around devp2p (<a href="./EIPS/eip-8">EIP-8</a>) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.</p> <h4><a href="{{"interface"|relative_url}}">Interface</a> ({{site.pages|where:"type","Standards Track"|where:"category","Interface"|size}})</h4> <p>Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (<a href="./EIPS/eip-6">EIP-6</a>) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.</p> <h4><a href="{{"erc"|relative_url}}">ERC</a> ({{site.pages|where:"type","Standards Track"|where:"category","ERC"|size}})</h4> <p>Application-level standards and conventions, including contract standards such as token standards (<a href="./EIPS/eip-20">EIP-20</a>), name registries (<a href="./EIPS/eip-137">EIP-137</a>), URI schemes (<a href="./EIPS/eip-681">EIP-681</a>), library/package formats (<a href="./EIPS/eip-190">EIP-190</a>), and account abstraction (<a href="./EIPS/eip-4337">EIP-4337</a>).</p> <h3><a href="{{"meta"|relative_url}}">Meta</a> ({{site.pages|where:"type","Meta"|size}})</h3> <p>Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.</p> <h3><a href="{{"informational"|relative_url}}">Informational</a> ({{site.pages|where:"type","Informational"|size}})</h3> <p>Describes a Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.</p> https://eips.ethereum.org/ https://eips.ethereum.org/ Informational / {% assign eips=site.pages|where:"type","Informational" %} {% include eiptable.html eips=eips %} https://eips.ethereum.org/informational https://eips.ethereum.org/informational Interface / {% assign eips=site.pages|where:"type","Standards Track"|where:"category","Interface" %} {% include eiptable.html eips=eips %} https://eips.ethereum.org/interface https://eips.ethereum.org/interface / <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Ethereum EIPs - Last Call Review</title> <description>All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!</description> <link>{{ site.url }}</link> <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" /> <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate> {% assign eips = site.pages | sort: 'eip' %} {% for eip in eips %} {% if eip.status == "Last Call" %} {% capture description %} <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p> {% if eip.discussions-to %} <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p> {% endif %} <hr /> {{ eip.content }} {% endcapture %} <item> <title>{{ eip.title | xml_escape }}</title> <description>{{ description | xml_escape }}</description> <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate> <link>{{ site.url }}/{{ eip.url }}</link> <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid> </item> {% endif %} {% endfor %} </channel> </rss> https://eips.ethereum.org/rss/last-call.xml https://eips.ethereum.org/rss/last-call.xml Meta / {% assign eips=site.pages|where:"type","Meta" %} {% include eiptable.html eips=eips %} https://eips.ethereum.org/meta https://eips.ethereum.org/meta Networking / {% assign eips=site.pages|where:"type","Standards Track"|where:"category","Networking" %} {% include eiptable.html eips=eips %} https://eips.ethereum.org/networking https://eips.ethereum.org/networking / <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Ethereum EIPs - Last Call Review</title> <description>All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!</description> <link>{{ site.url }}</link> <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" /> <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate> {% assign eips = site.pages | sort: 'eip' %} {% for eip in eips %} {% unless eip.category == "ERC" %} {% if eip.status == "Last Call" %} {% capture description %} <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p> {% if eip.discussions-to %} <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p> {% endif %} <hr /> {{ eip.content }} {% endcapture %} <item> <title>{{ eip.title | xml_escape }}</title> <description>{{ description | xml_escape }}</description> <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate> <link>{{ site.url }}/{{ eip.url }}</link> <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid> </item> {% endif %} {% endunless %} {% endfor %} </channel> </rss> https://eips.ethereum.org/rss/nonerc-last-call.xml https://eips.ethereum.org/rss/nonerc-last-call.xml / <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Ethereum EIPs</title> <description>All EIPs that are not ERCs</description> <link>{{ site.url }}</link> <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" /> <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate> {% assign eips = site.pages | sort: 'eip' %} {% for eip in eips %} {% unless eip.category == "ERC" %} {% if eip.status == "Last Call" %} {% capture description %} <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p> {% if eip.discussions-to %} <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p> {% endif %} <hr /> {{ eip.content }} {% endcapture %} <item> <title>{{ eip.title | xml_escape }}</title> <description>{{ description | xml_escape }}</description> <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate> <link>{{ site.url }}/{{ eip.url }}</link> <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid> </item> {% endif %} {% endunless %} {% endfor %} </channel> </rss> https://eips.ethereum.org/rss/nonerc.xml https://eips.ethereum.org/rss/nonerc.xml / $content-width: 1152px; @import 'minima'; .site-header { .wrapper { display: flex; flex-direction: column; align-items: center; } } .page-content { a.anchor-link { width: 16px; height: 16px; display: inline-block; margin-left: -22px; &:hover { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' class='anchor-link-icon' viewBox='0 0 16 16' version='1.1' width='16' height='16' aria-hidden='true'%3E%3Cpath fill-rule='evenodd' d='M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z'%3E%3C/path%3E%3C/svg%3E"); } } } .footer-col-wrapper { color: #111; } .table-borderless, .table-borderless * { border-style : hidden !important; // !important To override Jekyll styling background-color: rgba(0,0,0,0) !important; } table.preamble > tbody > tr > :not(:first-child) { width: 100%; } table.preamble > tbody > tr > :first-child { white-space: nowrap; } a, a:link { color: #726E97; text-decoration: none; } a:visited { color: #8E6680; } a:hover, a:active { color: #7F557D; text-decoration: underline; } .site-footer, .site-footer * { box-sizing: content-box !important; // !important To override bootstrap styling } .no-underline { text-decoration: none !important; // !important To override previous <a> styling } .badge:hover { filter: brightness(75%); transition: all 0.25s ease; } h1 { vertical-align: middle; } h1 a { height: 1em; display: inline-block; vertical-align: baseline; } .inline-svg { display: inline-block; vertical-align: bottom; fill: currentColor; width: 1.5ex; height: 100%; object-fit: cover; } @media print { header, footer { display: none; } } // This will make ALL tables scrollable .page-content table { display: inline-block; width: auto !important; /* shrink-to-fit its contents */ max-width: 100%; /* never exceed the width of its container */ overflow-x: auto; -webkit-overflow-scrolling: touch; } // Fix text overflow in EIP content .home { max-width: 100%; overflow-x: hidden; // Target all content that could overflow p, li, td, div { word-wrap: break-word; overflow-wrap: break-word; word-break: break-word; } // Specifically handle URLs in links a { word-wrap: break-word; overflow-wrap: break-word; word-break: break-all; display: inline-block; max-width: 100%; } // Handle code blocks that might contain long strings pre { overflow-x: auto; max-width: 100%; } // Inline code should wrap code { word-wrap: break-word; overflow-wrap: break-word; } } // Specifically target lists (where references usually are) .home ul, .home ol { max-width: 100%; padding-right: 20px; // Give some breathing room li { word-wrap: break-word; overflow-wrap: break-word; word-break: break-word; // Extra aggressive breaking for URLs a { word-break: break-all; hyphens: auto; } } } // makes an exception to code inside tables allowing them to expand the table's width since it has overflow scrolling .page-content table code { white-space: nowrap; word-break: normal; overflow-wrap: normal; } https://eips.ethereum.org/assets/css/style.css https://eips.ethereum.org/assets/css/style.css Example EIP to add generic algorithm as an algorithmic type Standards Track/Core fakeurl ## Abstract This example EIP adds generic algorithm as an algorithmic type. ## Motivation Generic algorithm has a good reason to be in Ethereum, therefore it should be. ## Specification This EIP defines a new [EIP-7932](/EIPS/eip-7932) algorithmic type with the following parameters. ```python ALG_TYPE = 0xFA SIZE = 128 def gas_cost(signing_data: Bytes) -> Uint64: return Uint64(128 + len(signing_data)) def validate(signature: Bytes) -> None | Error: # ... # Simple cryptography here # ... return None def verify(signature: Bytes, signing_data: Bytes) -> Bytes | Error: # ... # Complicated cryptography here # ... return public_key def merge_detached_signature(detached_signature: bytes, public_key: bytes) -> bytes: # ... # Either concatenation or a no-op here # ... return detached_signature + public_key ``` ## Rationale Generic algorithm has a good reason to be in Ethereum, therefore it should be. ## Backwards Compatibility No backward compatibility issues found. ## Security Considerations Needs discussion. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 12 Apr 2025 00:00:00 +0000 https://eips.ethereum.org/assets/eip-7932/template-eip https://eips.ethereum.org/assets/eip-7932/template-eip / --- - deposit_data: pubkey: "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x97af5a5e14a033c35ec6489c585df8975026af431b2c5e9e3e6fd66089575bdffaf41c0a196d9b2ef822226c49d16214146f8a79b6ffa400109cd6c63c73afc7649d25533a3619547bc333b0cb3f303432fcd4951333b656d64d7b46a7ba764f" deposit_data_root: "0x7af7da533b0dc64b690cb0604f5a81e40ed83796dd14037ea3a55383b8f0976a" eth1_data: deposit_root: "0x253f73460b66ba0b490a8f17029566b03c0690a584e262acc2be97c969bc65a6" deposit_count: "1" block_hash: "0xab6f0411b911f0d66539663dc6b41ed58bb4870cd3ae879e25c7bee8cd6d6f22" block_height: 2 snapshot: finalized: - "0x7af7da533b0dc64b690cb0604f5a81e40ed83796dd14037ea3a55383b8f0976a" deposit_root: "0x253f73460b66ba0b490a8f17029566b03c0690a584e262acc2be97c969bc65a6" deposit_count: 1 execution_block_hash: "0xab6f0411b911f0d66539663dc6b41ed58bb4870cd3ae879e25c7bee8cd6d6f22" execution_block_height: 2 - deposit_data: pubkey: "0xb89bebc699769726a318c8e9971bd3171297c61aea4a6578a7a4f94b547dcba5bac16a89108b6b6a1fe3695d1a874a0b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb24d74bd23b52c41567305b6aecdc73dd53aea59fa997c0d6205531ce70cc32282dbf9963dde89297522fdc2c541eb0909472145805953a2298aa56160784c23b3905ed0ec17c4775b61cecb922a0d0e5241521387fc38184afe735c2ce399ad" deposit_data_root: "0xb7dfec33825ba4dd8f6f8c2498c7202f07cbcf995a6de4b0abc71f1b1c46b2b2" eth1_data: deposit_root: "0x072080f22bf66504d6aa2b978c581e34637912ac191442af4f090dc5773d8936" deposit_count: "2" block_hash: "0x4e41a313cb3461e3154e76f87ec1bda35a48876529eaf3b99e335f43280c8d66" block_height: 3 snapshot: finalized: - "0xb6a04fb079b0153e6e555fd79bb89187c9386b2230f4020bd81558feca702982" deposit_root: "0x072080f22bf66504d6aa2b978c581e34637912ac191442af4f090dc5773d8936" deposit_count: 2 execution_block_hash: "0x4e41a313cb3461e3154e76f87ec1bda35a48876529eaf3b99e335f43280c8d66" execution_block_height: 3 - deposit_data: pubkey: "0xa3a32b0f8b4ddb83f1a0a853d81dd725dfe577d4f4c3db8ece52ce2b026eca84815c1a7e8e92a4de3d755733bf7e4a9b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xae64ef1d479919aa5cbd146559f366877298757843112239646d75658dc89d066e401be202a3198ffb7261b393b7f8c01901e36e3bfa17f7ae2620d5e44750fd983e3b97d9c44248689f81d6a0508501f2dadfbbc1c7ddcec307a4d6da42c59f" deposit_data_root: "0x7b14766c0e7eddb146fc2a5bfd91e6d358d71995d2dc3c60d0c326607e39f7f2" eth1_data: deposit_root: "0x5e493befc0eb8dd0162eb48e5c3430882eefae51cb3fa757f11853b28387acdb" deposit_count: "3" block_hash: "0xb06534c2390ed7d7ec1d2630c6e8a340570a1a63df72c5cb81bb6ad65dce0692" block_height: 4 snapshot: finalized: - "0xb6a04fb079b0153e6e555fd79bb89187c9386b2230f4020bd81558feca702982" - "0x7b14766c0e7eddb146fc2a5bfd91e6d358d71995d2dc3c60d0c326607e39f7f2" deposit_root: "0x5e493befc0eb8dd0162eb48e5c3430882eefae51cb3fa757f11853b28387acdb" deposit_count: 3 execution_block_hash: "0xb06534c2390ed7d7ec1d2630c6e8a340570a1a63df72c5cb81bb6ad65dce0692" execution_block_height: 4 - deposit_data: pubkey: "0x88c141df77cd9d8d7a71a75c826c41a9c9f03c6ee1b180f3e7852f6a280099ded351b58d66e653af8e42816a4d8f532e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa0b938a2e4cd395ca6f24b410ac60af8af115f93d869839d76d8ef5aaeee52350636d72ef264c25b20442a55b24cc82d09a21d416a3e957bb0d35baf53efb18ac274e2e744644d42fa8f17beb7b2b6baae5342fa06eb394da73dd45b1643f3e2" deposit_data_root: "0x4760922c3a4ed6d321fc97355c4e8f7b7aa9e9771cb258095e52702c40170337" eth1_data: deposit_root: "0xe7d648159438c55bd12bbfea58ae16b9f9692d3fb05b0eac1729c67687dabe11" deposit_count: "4" block_hash: "0x63289eb1794f3ccd7536ce19023625e04777f84bd147c72b70eafcc6131b2f03" block_height: 5 snapshot: finalized: - "0x33ac367f73d5318defd4d79d1b16c69046401691739f1aac0753a84e0ea28d22" deposit_root: "0xe7d648159438c55bd12bbfea58ae16b9f9692d3fb05b0eac1729c67687dabe11" deposit_count: 4 execution_block_hash: "0x63289eb1794f3ccd7536ce19023625e04777f84bd147c72b70eafcc6131b2f03" execution_block_height: 5 - deposit_data: pubkey: "0x81283b7a20e1ca460ebd9bbd77005d557370cabb1f9a44f530c4c4c66230f675f8df8b4c2818851aa7d77a80ca5a4a5e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaee3bec0f7786baae3a143131ea26d8ef62a8e17f7fade7355e42fb40a2717355d180c895f4de195523d3002d33ed60d10ba3b4285e8e712eb1612298051bdda70650966db509a104f374f45b16dfe06b21e6c385f0ff7d9c275b69dd193eef3" deposit_data_root: "0xfba947b41bd711feba3294ddaf1a6a87b888472f08a6c06d48afa702881409cd" eth1_data: deposit_root: "0x1004652bf7077a95c5a7ad7f2abd71565b750dcfbb1748d9489f3cae54c961fb" deposit_count: "5" block_hash: "0xc6aab9995fee61fde7d100a4f3aea2e8c9091501179943781dd50049ba57723d" block_height: 6 snapshot: finalized: - "0x33ac367f73d5318defd4d79d1b16c69046401691739f1aac0753a84e0ea28d22" - "0xfba947b41bd711feba3294ddaf1a6a87b888472f08a6c06d48afa702881409cd" deposit_root: "0x1004652bf7077a95c5a7ad7f2abd71565b750dcfbb1748d9489f3cae54c961fb" deposit_count: 5 execution_block_hash: "0xc6aab9995fee61fde7d100a4f3aea2e8c9091501179943781dd50049ba57723d" execution_block_height: 6 - deposit_data: pubkey: "0xab0bdda0f85f842f431beaccf1250bf1fd7ba51b4100fd64364b6401fda85bb0069b3e715b58819684e7fc0b10a72a34" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa28c8ad9d6cece980f888fe350f28ca3a4163f67f84c46053290e91134598fcba9fa7f4797c6cecdd435f44f65870e950a3b14c1d2ae162ee7958be3104e0489dd1a2f92482e30541abbd660e95d6476ad1373c19a64281b4057efdf36679758" deposit_data_root: "0x277ce49d97fb149180999892fe334e8d4701430aa5e76b7539e9593edc74209d" eth1_data: deposit_root: "0x82219812154553443de49dc85542aad6702f3b7ddb12e12be143a83028a5254a" deposit_count: "6" block_hash: "0x9ea53b7ec3ca5c5668b6b100e4463b93bd76d888ca846fbbb08d8db9596a3bf3" block_height: 7 snapshot: finalized: - "0x33ac367f73d5318defd4d79d1b16c69046401691739f1aac0753a84e0ea28d22" - "0x9c8cf1935559cf32ca28a3677d41dea8cbc511ba16d99d7b5ab5610ee22c9eb2" deposit_root: "0x82219812154553443de49dc85542aad6702f3b7ddb12e12be143a83028a5254a" deposit_count: 6 execution_block_hash: "0x9ea53b7ec3ca5c5668b6b100e4463b93bd76d888ca846fbbb08d8db9596a3bf3" execution_block_height: 7 - deposit_data: pubkey: "0x9977f1c8b731a8d5558146bfb86caea26434f3c5878b589bf280a42c9159e700e9df0e4086296c20b011d2e78c27d373" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x91d3bbe5ec01f47565f1b62e93b78fe084216a875154a6cb21cc521be15a548d3e28446c82fcf7214f484433abb2a0bb07c951cd3af2e2849e9e2456b4e53afbc122016e9f87a76269d307e02c495ef189a9bb48bf8a042a3a06676f82689000" deposit_data_root: "0x7d552eeb22d6a4fa593784ebc22fbd2c400d922dc806def9d8899c06b301125d" eth1_data: deposit_root: "0x2e079bcdc6905fcdf19041d355d17dd5a74f0749ac2cb178e81b648aafef3908" deposit_count: "7" block_hash: "0x8b5a2c44e11f46011c61e43cd768efbfc5610381caea1968397dc3ef50e83d9f" block_height: 8 snapshot: finalized: - "0x33ac367f73d5318defd4d79d1b16c69046401691739f1aac0753a84e0ea28d22" - "0x9c8cf1935559cf32ca28a3677d41dea8cbc511ba16d99d7b5ab5610ee22c9eb2" - "0x7d552eeb22d6a4fa593784ebc22fbd2c400d922dc806def9d8899c06b301125d" deposit_root: "0x2e079bcdc6905fcdf19041d355d17dd5a74f0749ac2cb178e81b648aafef3908" deposit_count: 7 execution_block_hash: "0x8b5a2c44e11f46011c61e43cd768efbfc5610381caea1968397dc3ef50e83d9f" execution_block_height: 8 - deposit_data: pubkey: "0xa8d4c7c27795a725961317ef5953a7032ed6d83739db8b0e8a72353d1b8b4439427f7efa2c89caa03cc9f28f8cbab8ac" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb3f76d7804668895192dd3fae3ccf101aa077da7c2678aefb8e92764e3bb0a32ef4592a62d8083aa0ca91f4cdefc745a0187fabd0f48fffc3213ccb9fca432a5c9c190d0d30f7c32f45e0ec4578eafad9a3f40e9a927e6cc1e0b5547cb54c0dc" deposit_data_root: "0xad041a1626deaccb4f11900595eaaab0f5b35d3ad16c3f1e5155181421348c11" eth1_data: deposit_root: "0xdd303f6f720a21ca45aebdaaf06a051ef6ad0b86b786b8a671e67652f5b32846" deposit_count: "8" block_hash: "0xe736c69176be57cfecb91f6e5c56fd5ed0b1537a9cac8229e30eb1b86abac543" block_height: 9 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" deposit_root: "0xdd303f6f720a21ca45aebdaaf06a051ef6ad0b86b786b8a671e67652f5b32846" deposit_count: 8 execution_block_hash: "0xe736c69176be57cfecb91f6e5c56fd5ed0b1537a9cac8229e30eb1b86abac543" execution_block_height: 9 - deposit_data: pubkey: "0xa6d310dbbfab9a22450f59993f87a4ce5db6223f3b5f1f30d2c4ec718922d400e0b3c7741de8e59960f72411a0ee10a7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8be64cfe0334b009be7c2d7c601e561976c201551d27b79747fc11fcbee6b22b9bd87552f8d492ec383e8bec11045b8f0c91ac28995f5c4b1c56b4953bb7fa0144d32f2464e8990342c907a42221b2a5ff69b8301259fa87e0bcb5f4bdaa16de" deposit_data_root: "0x9fb936887340fdde0663bc9811bc80c8939d4f1fda005a3d8d4d1e5803c65d43" eth1_data: deposit_root: "0x03d7883c2e63951bb4df714a7a0ceb389441999562dfa1fa98818b5791cf4c16" deposit_count: "9" block_hash: "0x597ffaa8cce4435d23a8f9dc28500422ce3d0e68fd5be5989eb032fb276b8293" block_height: 10 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" - "0x9fb936887340fdde0663bc9811bc80c8939d4f1fda005a3d8d4d1e5803c65d43" deposit_root: "0x03d7883c2e63951bb4df714a7a0ceb389441999562dfa1fa98818b5791cf4c16" deposit_count: 9 execution_block_hash: "0x597ffaa8cce4435d23a8f9dc28500422ce3d0e68fd5be5989eb032fb276b8293" execution_block_height: 10 - deposit_data: pubkey: "0x9893413c00283a3f9ed9fd9845dda1cea38228d22567f9541dccc357e54a2d6a6e204103c92564cbc05f4905ac7c493a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x938c03a718bf6e456ec84d88a118939dec03dbdce3697b8ef0f52208835d3221b4a103997264e064b13ecb05bb4b8ef910f4f3446a3b1524549f53ed9e744c41c3bf0350c4bc9b29f2b223ab1a91abe1a153d80bda8cee1b4f2f8fe3e6409ff9" deposit_data_root: "0xb6855e0bdbf1972d7a4571e6259cd589fe1baa3fa7ef569b9554c8e293b553dd" eth1_data: deposit_root: "0x2bba0e22d698d0e3cfa8374379f6c1a031a2aa0554cff8fa752936bc2ab8cdfd" deposit_count: "10" block_hash: "0x2e783a4e0b676caf552408ed8faf35f9e3e68dd2d82f71538ecf5c067dab6107" block_height: 11 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" - "0x30a5058eb6db4b120d6c07b995376d1e1f013ccd24d52b1327d7528d2e50c970" deposit_root: "0x2bba0e22d698d0e3cfa8374379f6c1a031a2aa0554cff8fa752936bc2ab8cdfd" deposit_count: 10 execution_block_hash: "0x2e783a4e0b676caf552408ed8faf35f9e3e68dd2d82f71538ecf5c067dab6107" execution_block_height: 11 - deposit_data: pubkey: "0x876dd4705157eb66dc71bc2e07fb151ea53e1a62a0bb980a7ce72d15f58944a8a3752d754f52f4a60dbfc7b18169f268" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb7bffc1c83d9294af5df83f9889bd9c8d60f020b87d2a2a4235e8b0385b11b42a61432817210f7ca05cdfa074989fb57181a5a63b899402822c9f5dd33d1f199f441886cd6b753ff9fa87b72146f05c51b20d39c31a666dfdd00ea961accf1a3" deposit_data_root: "0xc27c2db393fa0a74669bb5d2148ead286bec2fffc8c993e24a1c633221b0a91a" eth1_data: deposit_root: "0x697b75797e3f93acb334632bcd4af10979b12e10fa3f1b2dd7813bc31963f2aa" deposit_count: "11" block_hash: "0x3b9b8b3100433523f9b04ad853d9772795403b9610f58c71746f18280e7f1c97" block_height: 12 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" - "0x30a5058eb6db4b120d6c07b995376d1e1f013ccd24d52b1327d7528d2e50c970" - "0xc27c2db393fa0a74669bb5d2148ead286bec2fffc8c993e24a1c633221b0a91a" deposit_root: "0x697b75797e3f93acb334632bcd4af10979b12e10fa3f1b2dd7813bc31963f2aa" deposit_count: 11 execution_block_hash: "0x3b9b8b3100433523f9b04ad853d9772795403b9610f58c71746f18280e7f1c97" execution_block_height: 12 - deposit_data: pubkey: "0xaec922bd7a9b7b1dc21993133b586b0c3041c1e2e04b513e862227b9d7aecaf9444222f7e78282a449622ffc6278915d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8f2128ebe0cfc2ca5b6df5071b2960717a0b068dc4694d697af2589307ff0c4502e9faa5f7c5093ab8c214bce4f820db12336ea8853704fa050442ed6b513d68c6c18a33734d558658662c39174bb69be31b78d87eea4602292cda97fc2651ea" deposit_data_root: "0x9ce8e449715c5c2b4f0d7da4de574f18ce429f44c4b1f648e23b8ece0c24bcc8" eth1_data: deposit_root: "0xa990ca5f9f41f0b305051de710d8b2fe78f63e369f408977a2cf19dcee718b60" deposit_count: "12" block_hash: "0xcec38f21aef8ce25842b3db7e9f5cb708a1aa9b3bad17c04f31ef963657f81b5" block_height: 13 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" - "0x660335330368071f958f6fa763caa16650c7e3051733f84ce6bfa410f2052bf9" deposit_root: "0xa990ca5f9f41f0b305051de710d8b2fe78f63e369f408977a2cf19dcee718b60" deposit_count: 12 execution_block_hash: "0xcec38f21aef8ce25842b3db7e9f5cb708a1aa9b3bad17c04f31ef963657f81b5" execution_block_height: 13 - deposit_data: pubkey: "0x9314c6de0386635e2799af798884c2ea09c63b9f079e572acc00b06a7faccce501ea4dfc0b1a23b8603680a5e3481327" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xac36c7e15cd45f9f7c0e2672286513e03de301aff537460351bc1ccfa777139bfce29c6f441df8d7cbee4fdaea159cda1309a563ef28e9630ce1d022f8378046978fbb55e2f67dc708aa923e86bbfbd2487bf9f7b537a23ee1fd6c30043b6270" deposit_data_root: "0x079946bfcb7488e966144acd500b247b685896812cdb13c138742dfaad33ce88" eth1_data: deposit_root: "0x96906b941533a885ac57be9f765f90b0c880174286913c515552167b0154a116" deposit_count: "13" block_hash: "0xe9ebca52836019409c578724469684df7ddbf2a3f1a106c66e3af1dae3b24ad8" block_height: 14 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" - "0x660335330368071f958f6fa763caa16650c7e3051733f84ce6bfa410f2052bf9" - "0x079946bfcb7488e966144acd500b247b685896812cdb13c138742dfaad33ce88" deposit_root: "0x96906b941533a885ac57be9f765f90b0c880174286913c515552167b0154a116" deposit_count: 13 execution_block_hash: "0xe9ebca52836019409c578724469684df7ddbf2a3f1a106c66e3af1dae3b24ad8" execution_block_height: 14 - deposit_data: pubkey: "0x903e2989e7442ee0a8958d020507a8bd985d3974f5e8273093be00db3935f0500e141b252bd09e3728892c7a8443863c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x86c8283b6c4c8c6f01ff005c62d0199583c99a81ca9207f3a539b63f1732a06eae9e16e601ebf7ac0ac6cb0c0d0f147d0e10c8a3f7877814ac6291ee8fe4c83591dc2a82680bcce53c09b0c41b71fa84be2f799257c020ae2c41c801953345db" deposit_data_root: "0x8fe2405c8ed0d927f7c71d710879a4037b27409d0939074d040e88153245c1ad" eth1_data: deposit_root: "0x5d9c3452b70ec17728332003cf3d2e11d4f16151aef226ed799a837f4453e7a9" deposit_count: "14" block_hash: "0xa868c9bc5ac184f30ac39df5e5a5fdf0778575aad44b10e835968170c2183b7d" block_height: 15 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" - "0x660335330368071f958f6fa763caa16650c7e3051733f84ce6bfa410f2052bf9" - "0xb9d45d47c8373b0a9a2fe9c21bca36bf2a5fa9609c22e7699107a7d4fe8d39f1" deposit_root: "0x5d9c3452b70ec17728332003cf3d2e11d4f16151aef226ed799a837f4453e7a9" deposit_count: 14 execution_block_hash: "0xa868c9bc5ac184f30ac39df5e5a5fdf0778575aad44b10e835968170c2183b7d" execution_block_height: 15 - deposit_data: pubkey: "0x84398f539a64cbe01cfcd8c485ea51cd6657b94df93ee9b5dc61e1f18f69da6ca9d4dba63c956a81c68d5d4d4277a60f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8268676a3c7170a291d346859266a729b205077f7bd6c3b73d32ef63e420422aff7137abd008b22ae77db39803ff1c2a16990fd382d9ac7ea535daf73510fb9ad7b11c678bbec586a01ab0072ec47abc5adb498e1e8bf7bd957184b2c73d2a95" deposit_data_root: "0x22d0b48ba191226ea3c0a8eb8f05dcc26a66678bd7b2e8f90e43b0a6afd57ab3" eth1_data: deposit_root: "0x17b149f19cec86287f4b6ff785698cc55366b29e5a3042df3548a6cc4b9256f8" deposit_count: "15" block_hash: "0xda2b6d573ca1a9f707971321b1a1c65ab93916f4b984d621f4368302e94ab102" block_height: 16 snapshot: finalized: - "0x24b5bc14c80886b849880b846493fef7c12b8eb723461442d52129ffdf7af6a1" - "0x660335330368071f958f6fa763caa16650c7e3051733f84ce6bfa410f2052bf9" - "0xb9d45d47c8373b0a9a2fe9c21bca36bf2a5fa9609c22e7699107a7d4fe8d39f1" - "0x22d0b48ba191226ea3c0a8eb8f05dcc26a66678bd7b2e8f90e43b0a6afd57ab3" deposit_root: "0x17b149f19cec86287f4b6ff785698cc55366b29e5a3042df3548a6cc4b9256f8" deposit_count: 15 execution_block_hash: "0xda2b6d573ca1a9f707971321b1a1c65ab93916f4b984d621f4368302e94ab102" execution_block_height: 16 - deposit_data: pubkey: "0x872c61b4a7f8510ec809e5b023f5fdda2105d024c470ddbbeca4bc74e8280af0d178d749853e8f6a841083ac1b4db98f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9939cc7ccebfe4172d92680c74859e3f1d8de2e2a9bb494e9bec8306a5fb492bdab09f136f8f174d0bd5680991dc61970b5b7651ec3ffebe439b03df13e9259760bcfb1896795645796362856cd241b077d4d5e578bed13f7833cdee6135a7ce" deposit_data_root: "0x72d791ecc2dc99d82f29f4cebc5df93a493091b4cd6d6b92b31fc92cac128bad" eth1_data: deposit_root: "0x1eceb67da690c4ae9c9664c51630c2094e3dc517c7473f2659babbe496366483" deposit_count: "16" block_hash: "0x0698420ee3e7ac4f8c314c740c2df8ddd50e3de679bd57b55e62c53b1d00bbe6" block_height: 17 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" deposit_root: "0x1eceb67da690c4ae9c9664c51630c2094e3dc517c7473f2659babbe496366483" deposit_count: 16 execution_block_hash: "0x0698420ee3e7ac4f8c314c740c2df8ddd50e3de679bd57b55e62c53b1d00bbe6" execution_block_height: 17 - deposit_data: pubkey: "0x8f467e5723deac7659e1ca273e28410cbaa6d495ab66ae77014f4cd21c64b6b5ab9987c9b5537fe0279bd063fe609be7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x95c61f4b48792bf54197d2f5db308ae3315901f4419b5a1823784fc85190adf17824aa80d884b1813a1ca3792d55612d04e28951014e7e573b0baf51fe7c956c8c6e37e25d353187a1c8633c37cb1d91bf0a90544c26fe5bf562dc99f1a52bb2" deposit_data_root: "0x8df60288a3a0e60180b6026dcf71a62c5f88ae0714b433026155c49ab9f9a2b3" eth1_data: deposit_root: "0x6e612e99981156dbcf528144f5a661a3fec2092d32cf8276174a9f112d6f2694" deposit_count: "17" block_hash: "0x78f5fafef1f3dbc6ccde8362063b0ee74528976ef4f57407dbd3606fc87fa592" block_height: 18 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0x8df60288a3a0e60180b6026dcf71a62c5f88ae0714b433026155c49ab9f9a2b3" deposit_root: "0x6e612e99981156dbcf528144f5a661a3fec2092d32cf8276174a9f112d6f2694" deposit_count: 17 execution_block_hash: "0x78f5fafef1f3dbc6ccde8362063b0ee74528976ef4f57407dbd3606fc87fa592" execution_block_height: 18 - deposit_data: pubkey: "0x8dde8306920812b32def3b663f7c540b49180345d3bcb8d3770790b7dc80030ebc06497feebd1bcf017d918f00bfa88f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa055036c86894b46ef0ef8e734b0a93cbeae393db9de264e57f03766ac1126ce21371a49dbb3d19c1da17e4f1c80eb1103e48c4ad44b778991ade181955b39928ca274a0625fe21bdb1ac79d8046a37a6066afc2e1fad405271efb80c4cec998" deposit_data_root: "0x822c94e13fb37ecca034fabe44e24e06fd5e14685ffc98fc01dfb5d1b2ae8634" eth1_data: deposit_root: "0x4da8765913d4a494b45f34c4a4cc928e2be2e7e9c41dc13d69f5c0581f5bc628" deposit_count: "18" block_hash: "0xfdf087208f15f7cfbd0e777ee67d5a1224210c7095ec5a93201d1a042db10d27" block_height: 19 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xd834f7120ed8a3f465b6484186992815aef250168d7c624b508c177ecbddb102" deposit_root: "0x4da8765913d4a494b45f34c4a4cc928e2be2e7e9c41dc13d69f5c0581f5bc628" deposit_count: 18 execution_block_hash: "0xfdf087208f15f7cfbd0e777ee67d5a1224210c7095ec5a93201d1a042db10d27" execution_block_height: 19 - deposit_data: pubkey: "0xab8d3a9bcc160e518fac0756d3e192c74789588ed4a2b1debf0c78f78479ca8edb05b12ce21103076df6af4eb8756ff9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x923fcfc77cf65ae29aa7771f9152140af8dfdf7301889aa52d5f1221b3ef8e7186b3dce969db0b6824308c657978952f01a4b2193d385fdd42ed107332b6714e4e10f70ad07919aadbf51d4f50ce0da40317bf8bc5d55b7d2e1bd8a77ff24a67" deposit_data_root: "0x89be43c5944c2e25e15e930dd1c4572501359f2ae617eb829e96b83890517ae9" eth1_data: deposit_root: "0x2da633fb33c672f3348e994d49a8637935c8bf5db9c8e4524a19625f5c9bdb0f" deposit_count: "19" block_hash: "0x9b0e02e7dc57fb2c4178c55aa82cddd698a9eb91690a4ce1ce3508a3cb2589c0" block_height: 20 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xd834f7120ed8a3f465b6484186992815aef250168d7c624b508c177ecbddb102" - "0x89be43c5944c2e25e15e930dd1c4572501359f2ae617eb829e96b83890517ae9" deposit_root: "0x2da633fb33c672f3348e994d49a8637935c8bf5db9c8e4524a19625f5c9bdb0f" deposit_count: 19 execution_block_hash: "0x9b0e02e7dc57fb2c4178c55aa82cddd698a9eb91690a4ce1ce3508a3cb2589c0" execution_block_height: 20 - deposit_data: pubkey: "0x8d5d3672a233db513df7ad1e8beafeae99a9f0199ed4d949bbedbb6f394030c0416bd99b910e14f73c65b6a11fe6b62e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c0b2b26e5d9672cc95c0fa6d23ca6aa02a7163054a5492b95d5f4470083e4c2aca64e5d38972e13dceeea88996a1fca196e7e540fc05c96c195b3f27b421b38efa3c24f4fe6905c40eab900552531063f00b45718660179d36fa1daeb7e08e0" deposit_data_root: "0x8c75a76c9c9892a587d7b0bc8c224d8a6e49d0513ee7f65f59b668d9108deca3" eth1_data: deposit_root: "0x6dee02182764197fb5be9df0535dbe15ca556b26e628d5aba8b080de4b92049b" deposit_count: "20" block_hash: "0xf32ee96bf62b97336de0e8846fc0d5ad58cf5b5cf899790859545d40644d00c4" block_height: 21 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0x0e15a983c4aaa8cb3676b532c0dae58a86e1a329e2be55baa4e9bf8728bf7698" deposit_root: "0x6dee02182764197fb5be9df0535dbe15ca556b26e628d5aba8b080de4b92049b" deposit_count: 20 execution_block_hash: "0xf32ee96bf62b97336de0e8846fc0d5ad58cf5b5cf899790859545d40644d00c4" execution_block_height: 21 - deposit_data: pubkey: "0xa1c76af1545d7901214bb6be06be5d9e458f8e989c19373a920f0018327c83982f6a2ac138260b8def732cb366411ddc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9072a23d7159f70dcf6cda33337ded68b59d1caaa9b94b708d06736a8bdf9d414d126ccd9c53aa8baf5c3aa22163a1b013874c29db01d164c3a3632dc7ce73fdbd5d43ca64646418f4412f6d462122c115468faa4371836fcd43150daa696e1e" deposit_data_root: "0x428fe5a8d16366f972a52daa8e2eba40bedf30360ecfa2d81efc2d68ee21c80d" eth1_data: deposit_root: "0x46ffc1bb9ee82fcf871ecdd525f8db26a0616c46644a150ef293d3a969af249f" deposit_count: "21" block_hash: "0x551285bb963663cc97445ab83591ca6e33d02ae26092c1897804438be2afa704" block_height: 22 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0x0e15a983c4aaa8cb3676b532c0dae58a86e1a329e2be55baa4e9bf8728bf7698" - "0x428fe5a8d16366f972a52daa8e2eba40bedf30360ecfa2d81efc2d68ee21c80d" deposit_root: "0x46ffc1bb9ee82fcf871ecdd525f8db26a0616c46644a150ef293d3a969af249f" deposit_count: 21 execution_block_hash: "0x551285bb963663cc97445ab83591ca6e33d02ae26092c1897804438be2afa704" execution_block_height: 22 - deposit_data: pubkey: "0x8dd74e1bb5228fc1fca274fda02b971c1003a4f409bbdfbcfec6426bf2f52addcbbebccdbf45eee6ae11eb5b5ee7244d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8bc79ba412ff7d26f58dcfa5b7f6c2b05570e1ac9c3671a9e2f22f11615b9fa5658a4532a35f5c42b5ffa136f796e04218d279e01990d6591daac0b7cb1481b5c7efe1264f39919dcf56e4b155ba162b7096ba9dd44805868793ab8440eac0a7" deposit_data_root: "0x2862ae99f44e6fdb1d9ea652c10832e10334563e8873cc92af000703ee501849" eth1_data: deposit_root: "0xbb0311909b43eb5cc96107607d54315d84d24a552a27569a0992384417314e30" deposit_count: "22" block_hash: "0xd903cd669f26d87ed4d754ad13d3e8426505180dd67d9c3b44c3341fd2d33d8c" block_height: 23 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0x0e15a983c4aaa8cb3676b532c0dae58a86e1a329e2be55baa4e9bf8728bf7698" - "0xdf659f3a3a39eda83bcbebb3a7ce225bda424b28d47ad4fd78a187e94150474e" deposit_root: "0xbb0311909b43eb5cc96107607d54315d84d24a552a27569a0992384417314e30" deposit_count: 22 execution_block_hash: "0xd903cd669f26d87ed4d754ad13d3e8426505180dd67d9c3b44c3341fd2d33d8c" execution_block_height: 23 - deposit_data: pubkey: "0x954eb88ed1207f891dc3c28fa6cfdf8f53bf0ed3d838f3476c0900a61314d22d4f0a300da3cd010444dd5183e35a593c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x942f0eacead041b7fb92f1917f46e3a884beded26a90aed33b571ea20a88a2b6c2b3bfb39bb961e8d5a9003ae9f95d0e00f5c405ede3135de09749dae540fbd5bc3c89ff1c3494676298caca4a29277aa3f3633fa827fa3b32f3ce9fb71b2486" deposit_data_root: "0x171d4e93ba95da64b2a59446bcba72a5af8cb33cd002d8db1774111b851b4c2f" eth1_data: deposit_root: "0xe1367c132b2c346fb43358ed1d2c392c535070c065450c8cc45c387ba99eeb6a" deposit_count: "23" block_hash: "0x457a64cc460ff02516925473033c4f5a16a0be8c98f5db1c6cfd4aa9001ebaa9" block_height: 24 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0x0e15a983c4aaa8cb3676b532c0dae58a86e1a329e2be55baa4e9bf8728bf7698" - "0xdf659f3a3a39eda83bcbebb3a7ce225bda424b28d47ad4fd78a187e94150474e" - "0x171d4e93ba95da64b2a59446bcba72a5af8cb33cd002d8db1774111b851b4c2f" deposit_root: "0xe1367c132b2c346fb43358ed1d2c392c535070c065450c8cc45c387ba99eeb6a" deposit_count: 23 execution_block_hash: "0x457a64cc460ff02516925473033c4f5a16a0be8c98f5db1c6cfd4aa9001ebaa9" execution_block_height: 24 - deposit_data: pubkey: "0xaf344fce60dbd5fb850070e6e76a065e1a32485245ef4f413135a86ae703da88407c5d01c71f6bb06a151ff96cca7191" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x968b1f4d64fbec9c8b5599eb9f3ebf64ea9f5cda3cde3c463cd714022efad0653563a2f24581f2f6c019567abd4801400b79d097b925d363aed6e995f9d1869dbd4ae52ea3542a6a2258094867c767c7e9951e80df872dce35904b6d8eb13c49" deposit_data_root: "0x4f24e0bcfcbf2a0e0828b5b63fed6f175c939c6332d622d5959b683ff5a986ba" eth1_data: deposit_root: "0x75580add56b9161b8747e19faba42030d70994396de5ab95b6b86f61262d86ae" deposit_count: "24" block_hash: "0x8d44620a0a0ff3d00477c7735e28cfb742a10619664a017f8800ea13dcdcef9a" block_height: 25 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" deposit_root: "0x75580add56b9161b8747e19faba42030d70994396de5ab95b6b86f61262d86ae" deposit_count: 24 execution_block_hash: "0x8d44620a0a0ff3d00477c7735e28cfb742a10619664a017f8800ea13dcdcef9a" execution_block_height: 25 - deposit_data: pubkey: "0xae241af60691fda1cf8ca44d49573c55818c53b6141800cca2d488b9a3fba71c0f869179fff50c084657831fbeb42bf4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa439766948de7ba95f03ae54671d0c71bf34538405554f9a6b52e4b3672ab8f8b484841844652fa2573a3473fbd6d5d2046f6776ae161384da704df0b0dd8d800b4b0179e88ce193f84bf022fb81490bb4697f331eebdbfcab1c09b76c5f798a" deposit_data_root: "0x98c8fddae908c9740b1e57526c08791223bf0fa2d03cee0855a62ba3af995483" eth1_data: deposit_root: "0x17ab1dfcb9c9438066726df5d532f91d74290292887618fdb5392f7a4da88d3f" deposit_count: "25" block_hash: "0x0d92259ff68bc51a4dad01a711927f941fcde206c05ef405d37f44e602ca0513" block_height: 26 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" - "0x98c8fddae908c9740b1e57526c08791223bf0fa2d03cee0855a62ba3af995483" deposit_root: "0x17ab1dfcb9c9438066726df5d532f91d74290292887618fdb5392f7a4da88d3f" deposit_count: 25 execution_block_hash: "0x0d92259ff68bc51a4dad01a711927f941fcde206c05ef405d37f44e602ca0513" execution_block_height: 26 - deposit_data: pubkey: "0x96746aaba64dc87835ba709332f4d5d7837ada092b439c49d251aecf92aab5dc132e917bf6f59799bc093f976a7bc021" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa147ee89efcadbe1c8ae5dd2309b9153966d57d0c69b47f33f1a2a0bfa47821956ea5b20ffdfd77602509e7c92b4cf70ac7e16593c9325e41869af6e6844a09f20273001cbd00f413690c913b8c61390e40181c3c78d0605db457b17165535b" deposit_data_root: "0xc220f1e62f775aa20f6783a08ede02364bb656aa3aea8a53b566cc3f5780ce20" eth1_data: deposit_root: "0x28533734876a9a4da9bc4518a561f124e9c09a3c52e727707cbbb2bae1a8afd4" deposit_count: "26" block_hash: "0xc11cc9313a9f6f28d1f4b6f06a0f4871efcc548df79c90c77b10b6bd6af073b7" block_height: 27 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" - "0x16bdf648ff50bb5f33cab70a7cff595ba63caaff4fcb670610e802cc344dffc2" deposit_root: "0x28533734876a9a4da9bc4518a561f124e9c09a3c52e727707cbbb2bae1a8afd4" deposit_count: 26 execution_block_hash: "0xc11cc9313a9f6f28d1f4b6f06a0f4871efcc548df79c90c77b10b6bd6af073b7" execution_block_height: 27 - deposit_data: pubkey: "0xb9d1d914df3d4565465c3fd52b5b96e637f9980570cabf5b5d4aadf5a329ac36ad672819d997e735f5052e28b1f0c104" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2a21801a7ddd00d4b1df1c571b74b95b7cb92d484712349c612438183e4d486113f51e356343be7835a0f6c88e7de5a0978cb3815b3ca044fe741c25b02eade6fb36500b2264305b5954cc4f5ad451c6f43d552405def57a07411a32016097b" deposit_data_root: "0x6db78e60584351fc046ce86f6f56c1ec42ecc5526677d4a1b3bb720280277f38" eth1_data: deposit_root: "0xf18ab78c3cfee43fc0c09c7c1101d655b86b30809149134e0fd6603247b48650" deposit_count: "27" block_hash: "0x6381e5f3e249642bb56562bb2cd645d77578491d8b22b4de49976c606f10b275" block_height: 28 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" - "0x16bdf648ff50bb5f33cab70a7cff595ba63caaff4fcb670610e802cc344dffc2" - "0x6db78e60584351fc046ce86f6f56c1ec42ecc5526677d4a1b3bb720280277f38" deposit_root: "0xf18ab78c3cfee43fc0c09c7c1101d655b86b30809149134e0fd6603247b48650" deposit_count: 27 execution_block_hash: "0x6381e5f3e249642bb56562bb2cd645d77578491d8b22b4de49976c606f10b275" execution_block_height: 28 - deposit_data: pubkey: "0x963528adb5322c2e2c54dc296ffddd2861bb103cbf64646781dfa8a3c2d8a8eda7079d2b3e95600028c44365afbf8879" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa52e6582b3f70257211e96a5023f5f860d6c9a236ddd1362f8bf354a3621cee74500682ef4e10f725f19a15527c086320fe2714745b54b4be4cbf1d6ff3f84821bd9e789717ad9fcfc36f9a96509fe4889c0c7824f4e0ce21108744f369d1c07" deposit_data_root: "0x7e238e9a9674ddc5e0913d2f698cb776a64392c390353e42287f7c5f4098168a" eth1_data: deposit_root: "0x4fa046ca0d14d29f272ee56ef063b382a46a04b30cf2826dd0c832152a48d476" deposit_count: "28" block_hash: "0xf6c4330660f686d3c0549237f8331f78fdb99653b72a25d5b88b7a26be512ae3" block_height: 29 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" - "0xf7068f7d6c4ca26e61c3ea98cde4d5de184da7fba2f5a99ea5de37c719e27a07" deposit_root: "0x4fa046ca0d14d29f272ee56ef063b382a46a04b30cf2826dd0c832152a48d476" deposit_count: 28 execution_block_hash: "0xf6c4330660f686d3c0549237f8331f78fdb99653b72a25d5b88b7a26be512ae3" execution_block_height: 29 - deposit_data: pubkey: "0xb245d63d3f9d8ea1807a629fcb1b328cb4d542f35a3d5bc478be0df389dddd712fc4c816ba3fede9a96320ae6b24a7d8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8a177ab3d2b199d3f8bd8dea6b896e1456559e2205064eca589ff1150ad4a4cefb3307fbe1eab515b1caae1d9bd4181f106e1371e3f11d22dd76d90589dcad6b9d9317c7a403dcee09b5074bed807fe6e57c85d688956ad439232d20bdcfc069" deposit_data_root: "0xe71a456a9faa68cca752c81c90d954138a586b0f8166c8870ea89b54b01313b3" eth1_data: deposit_root: "0xc71512461c08e8fab3ad7d23413a46e9c47f3d133ce181800484b6f4603bcd55" deposit_count: "29" block_hash: "0xd11a018e251c410ef7672f160087e677d29da1b591e14ac632fa2a1c9e00b62f" block_height: 30 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" - "0xf7068f7d6c4ca26e61c3ea98cde4d5de184da7fba2f5a99ea5de37c719e27a07" - "0xe71a456a9faa68cca752c81c90d954138a586b0f8166c8870ea89b54b01313b3" deposit_root: "0xc71512461c08e8fab3ad7d23413a46e9c47f3d133ce181800484b6f4603bcd55" deposit_count: 29 execution_block_hash: "0xd11a018e251c410ef7672f160087e677d29da1b591e14ac632fa2a1c9e00b62f" execution_block_height: 30 - deposit_data: pubkey: "0xa98ed496c2f464226500a6ce04602ff9ef133ed6316f372f6c744aee165149f7e578b12780e0eacec307ae6907351d99" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa12d7c9738f2e443bb7226e03631847b82b84fa2a77426b101dd4c0574da816abfbd0905df5e00d4217ac9ea10b0213c09f6ed2fe8628f8e15c8e07d7d7809cefebb0d9dc515b2f2603e6fba7854c8c842b70137e0f5dea4e2f37ca6b116d8dc" deposit_data_root: "0x9e5bfab0b9bd4cbf7232f3a004074c87974e1e1c98838a99775355443426bb6c" eth1_data: deposit_root: "0xc0108c1784340504324dc235e2214f51603386e6d7d1a36a36adf67148a19a66" deposit_count: "30" block_hash: "0xf50b59b6a0f164a687d5388bc590467f68a874769b2e320a0c83f4a01dcd663c" block_height: 31 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" - "0xf7068f7d6c4ca26e61c3ea98cde4d5de184da7fba2f5a99ea5de37c719e27a07" - "0x011f1eb3813fb8ee88932f9e3ab2781c9c085105658ba15559994d2e26a1d8dd" deposit_root: "0xc0108c1784340504324dc235e2214f51603386e6d7d1a36a36adf67148a19a66" deposit_count: 30 execution_block_hash: "0xf50b59b6a0f164a687d5388bc590467f68a874769b2e320a0c83f4a01dcd663c" execution_block_height: 31 - deposit_data: pubkey: "0xae00fc3de831b09661a0ac02873c45c84cb2b58cffb6430a3f607e4c3fa1e0932397f11307cd169cdc6f79c463527260" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x84ea7a055239b25ec73f3ac4f12e92941c3cd05a35a72f9a1ee8267cdbc8b97e9ee32e52262b87563186d716ead86d2f01d7ae34575579a6348d9085154b0ea1f186374f169c251e621e1fd177a7fffcb1af3feac4555092ef628a090de37a85" deposit_data_root: "0x661bd0e0ddbd2ba4acb89aa575180637c85f5413ed1bcdc028ab1abd0cfc2b47" eth1_data: deposit_root: "0x832e7610fb4663859d3d72f21510c20aede5e3a5dfc5ac4434c5800ebfd78444" deposit_count: "31" block_hash: "0x5eceb3df2ef05c68164fa475e0e0e0e2ec5f5613dd8bfe1c486a172dbf0ae594" block_height: 32 snapshot: finalized: - "0x5f652df37d6370cd7a4267959f0b885e201b293a69f57a8769c92d797050967e" - "0xf411283523e35f406ed67667dab5e352fc257052ddac82c3bb78c1cf157884aa" - "0xf7068f7d6c4ca26e61c3ea98cde4d5de184da7fba2f5a99ea5de37c719e27a07" - "0x011f1eb3813fb8ee88932f9e3ab2781c9c085105658ba15559994d2e26a1d8dd" - "0x661bd0e0ddbd2ba4acb89aa575180637c85f5413ed1bcdc028ab1abd0cfc2b47" deposit_root: "0x832e7610fb4663859d3d72f21510c20aede5e3a5dfc5ac4434c5800ebfd78444" deposit_count: 31 execution_block_hash: "0x5eceb3df2ef05c68164fa475e0e0e0e2ec5f5613dd8bfe1c486a172dbf0ae594" execution_block_height: 32 - deposit_data: pubkey: "0xa4855c83d868f772a579133d9f23818008417b743e8447e235d8eb78b1d8f8a9f63f98c551beb7de254400f89592314d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x95e0bd85c20f14f8eb05bb4f2d6a5a0297c78c6598fcc886fa93d2bee73b52c8913a848f690be3094883fbe31200bae90a1401d4c8b11dc82c635f63a3f42cef8fb19f04b27e7ec67c03811327614242d407b157b852e008df78fe482c3496ac" deposit_data_root: "0xc8d8e9014b8fd00b885838bd0e71fcec16dbdef5b5b5cae3b09176d8e6bf7883" eth1_data: deposit_root: "0x2def103e29ea70f435350e0a77e1f8cafe671db9d9f43a1d20621abc7f85c73a" deposit_count: "32" block_hash: "0x6476bebf6ce3c9e8cbc630a58962e9891b99320d548ea03e527ebd3d23f3c35c" block_height: 33 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" deposit_root: "0x2def103e29ea70f435350e0a77e1f8cafe671db9d9f43a1d20621abc7f85c73a" deposit_count: 32 execution_block_hash: "0x6476bebf6ce3c9e8cbc630a58962e9891b99320d548ea03e527ebd3d23f3c35c" execution_block_height: 33 - deposit_data: pubkey: "0xa9cf360aa15fb1d1d30ee2b578dc5884823c19661886ae8b892775ccb3bd96b7d7345569a2aa0b14e4d015c54a6a0c54" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x87e60e3980d5d71bcc9983c3317ea8a1a60862ea9f4a4d3c3c710ddbd90db3dac49d6ff7c9d2f8c447a02f9310d7e2eb119e06b83543bc0918c87199ba2724624ece384c336e69743850dd4b3b92f560423279bf50252546d612107a03bab3d8" deposit_data_root: "0x1051a6ad73280cee0f10ba9c5762e001a23aef44269a7eae9b2050d17ac1b2cd" eth1_data: deposit_root: "0x2260d0f4b57dd958fdc8badd66391e11e13bfdb64563ce7904bec1ddc4f8ece1" deposit_count: "33" block_hash: "0x0268dec10d6ad09835aa9a0a2fe971f4b4ef81f59aaf8a9d43d99f17c186964a" block_height: 34 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0x1051a6ad73280cee0f10ba9c5762e001a23aef44269a7eae9b2050d17ac1b2cd" deposit_root: "0x2260d0f4b57dd958fdc8badd66391e11e13bfdb64563ce7904bec1ddc4f8ece1" deposit_count: 33 execution_block_hash: "0x0268dec10d6ad09835aa9a0a2fe971f4b4ef81f59aaf8a9d43d99f17c186964a" execution_block_height: 34 - deposit_data: pubkey: "0xaef9162ee6f29ee82fbfe387756d84f9ac472eb8709217aaf28f5ef0ea273f6210e531496470b30d2b7747216e3672d5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5dc53467b3e5826af953385e83f5a21858c7019c6c87aad005509038379db54e0d7d48453bb00394f78e1895a3af296147c45f766f4eafad06e60e7d2b206d628ba2cc61db59a472c68cf48b28979bfccf28a4cafac63271bfcce7461450b5e" deposit_data_root: "0x6c24e556eec47c66d6b2a3ec29e013ba206ea34e8d3685b90ff823b06aa80b4b" eth1_data: deposit_root: "0x9268f23209182ea5393b84731c67d205b50dd541b590548479d816be20fdee70" deposit_count: "34" block_hash: "0x69ef65f0294564315ef609e7b5bf76420ced3fe110c763dd8bcd348760b1a267" block_height: 35 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0x70918d35011dbe3749fad7b8ca02046cb69b4893834ff0f71cfe11a17f2fde0c" deposit_root: "0x9268f23209182ea5393b84731c67d205b50dd541b590548479d816be20fdee70" deposit_count: 34 execution_block_hash: "0x69ef65f0294564315ef609e7b5bf76420ced3fe110c763dd8bcd348760b1a267" execution_block_height: 35 - deposit_data: pubkey: "0xb7e6e187ed813d950a9a17d1e70c03e4de2903596c4c5ff326848515c985deee38198efebc265300cd4f1d6bd7b5d264" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x886d08aca274c127f741d249a865851818a8bd387d1eec83f2d702c4ce78e6ba93d3ddc629d0269f43a91b2a56074797044f37c528b10344cd08808f829867577aa8aed839f6066922ed4953376b65ea14ba725478674bf32a37e337563774cc" deposit_data_root: "0x72c9a1bdb8a1deaae1c4007567257ebad96b664c27c9accfab8ad9f9d10b8ca1" eth1_data: deposit_root: "0x5261a6f04d75e281c1c83bd3a443746b643d0956a23cb2ce69d39c0504072038" deposit_count: "35" block_hash: "0xd54072d4f8010162a877d38f5d814d9a05ec3ffacdf04128c86205cbc9de92aa" block_height: 36 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0x70918d35011dbe3749fad7b8ca02046cb69b4893834ff0f71cfe11a17f2fde0c" - "0x72c9a1bdb8a1deaae1c4007567257ebad96b664c27c9accfab8ad9f9d10b8ca1" deposit_root: "0x5261a6f04d75e281c1c83bd3a443746b643d0956a23cb2ce69d39c0504072038" deposit_count: 35 execution_block_hash: "0xd54072d4f8010162a877d38f5d814d9a05ec3ffacdf04128c86205cbc9de92aa" execution_block_height: 36 - deposit_data: pubkey: "0x81054bd51ce57a8415f0c8e0f2fbf94f5a8464552baa33263c20a4da062e5ed994a4d32c171106d2008cd063f48f6fe2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x97cc963e23ecd9b21bdea8cfebaa2b4d1a47caef4f6c404ce40849fc20ac2337116fab977fc21104491435e6301d499203d6d33b70e389ff42264891d422a79f76d20ec6d501af2d03fdf2d44d00894db77955b19a91823e665a4fe7cff2e9a7" deposit_data_root: "0x4a985ca67543ab0f8e8510fc74fcd3efc4eb46e4590c60f415a568b4253701ad" eth1_data: deposit_root: "0x82c0b3acf41d802658accffa90b6991181cfe9ea6163104cffe745280e17831f" deposit_count: "36" block_hash: "0x3f9eb6bfe92c16a2bfd72bd6f5a7464255400c39a5ca46e0f50b91d3908fa0a8" block_height: 37 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0x98b240f56117c7974d324f09c387e28e5acced1186003fe8df875e1c7377d7a5" deposit_root: "0x82c0b3acf41d802658accffa90b6991181cfe9ea6163104cffe745280e17831f" deposit_count: 36 execution_block_hash: "0x3f9eb6bfe92c16a2bfd72bd6f5a7464255400c39a5ca46e0f50b91d3908fa0a8" execution_block_height: 37 - deposit_data: pubkey: "0xaecc56f2b1c4011d450214d3e1254479d583a6a5c2c06fbc049512731f76227d140df9f36a3f76b4ccb4df1342403573" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb609cc73d220819290cb6f814295b01aeaa044a83105a7df712ab659e9368d3291b55f1b611bd28edc40c5694b5786a6068616edd2cdcac6104d0342b70b1aa0005bfb6828813d58fde482972f8c837d0650945b56e41ab157bbc4e1e7928351" deposit_data_root: "0x6466d5d6da2e21242c13f72238a6796c78b52decddb11ed4e3b5e489b96317f0" eth1_data: deposit_root: "0x1cfd89cb2db15e0811b5a9cf5047e0e0b561afced194bb0a102a2ba155319600" deposit_count: "37" block_hash: "0xbd8cb6544b20968a1b580dcc4f70cfd241f736bb1c399063a7c25e077e734d15" block_height: 38 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0x98b240f56117c7974d324f09c387e28e5acced1186003fe8df875e1c7377d7a5" - "0x6466d5d6da2e21242c13f72238a6796c78b52decddb11ed4e3b5e489b96317f0" deposit_root: "0x1cfd89cb2db15e0811b5a9cf5047e0e0b561afced194bb0a102a2ba155319600" deposit_count: 37 execution_block_hash: "0xbd8cb6544b20968a1b580dcc4f70cfd241f736bb1c399063a7c25e077e734d15" execution_block_height: 38 - deposit_data: pubkey: "0x9243ef5ed3bd28892d1ef4f7aaf29faeb9c0e725673cd38e308bd756f20a9ee09de5cd9822e5e77bd03b734ef8a92695" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa19c19c9d1d616f7d3f57393d9ce5230dc2502f6764612a0911227811bea8688fb1f7ffcfb680ea21dd60a3a8faf596b0edaef49936901ae891d7f2266ef937731bb2fb34fd1e30bb161ab8b8e6ee389759519079ebdab9f1500fdb3b633d110" deposit_data_root: "0xe430fb5af8b28239457fecf2ea0106ca1cf1e68e5d22ddc64adbb4b5167254be" eth1_data: deposit_root: "0x7580110cf5b8a5450a42ea097b2fcab6ad4cdb58a2100f8274e486b62ce673e2" deposit_count: "38" block_hash: "0xed447968de652c510595235a85ad711d39cb1d767bb247d94e82b63be69155ba" block_height: 39 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0x98b240f56117c7974d324f09c387e28e5acced1186003fe8df875e1c7377d7a5" - "0x5240648c484242305f1ff513c043647c24fc5e5d61cd4196ebf3c2c86402f1f0" deposit_root: "0x7580110cf5b8a5450a42ea097b2fcab6ad4cdb58a2100f8274e486b62ce673e2" deposit_count: 38 execution_block_hash: "0xed447968de652c510595235a85ad711d39cb1d767bb247d94e82b63be69155ba" execution_block_height: 39 - deposit_data: pubkey: "0x925b1fb57c06b5668567bd5aa196531032d6f8918dd4f702017c11b59288e3bdb98e3820ac22780f73580a4119de4bbc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x81c25d6edbe71803bd57c92c073be629bae323c28ff1a6f30ed5c507493d8271591b46581467cdd92f5847d20a1bc2760bc351838dbf690d90e06af696c7e9e46b943189b2aef29115e1c6e4ea83ec724c7955736e42c611859afebaf622a1a1" deposit_data_root: "0xfa7f084e644997f1640e3568bd2400fa26cf9fd43e37275cc6578db139d9921a" eth1_data: deposit_root: "0xab72caf415667e76d99579f3cd9f5092c19470ce7e2267e9d7dc6d1c42c1401f" deposit_count: "39" block_hash: "0xd7ecbd540da29e0e617261e2b901815fc05c912a34d91df31de54e91eba6f49b" block_height: 40 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0x98b240f56117c7974d324f09c387e28e5acced1186003fe8df875e1c7377d7a5" - "0x5240648c484242305f1ff513c043647c24fc5e5d61cd4196ebf3c2c86402f1f0" - "0xfa7f084e644997f1640e3568bd2400fa26cf9fd43e37275cc6578db139d9921a" deposit_root: "0xab72caf415667e76d99579f3cd9f5092c19470ce7e2267e9d7dc6d1c42c1401f" deposit_count: 39 execution_block_hash: "0xd7ecbd540da29e0e617261e2b901815fc05c912a34d91df31de54e91eba6f49b" execution_block_height: 40 - deposit_data: pubkey: "0x9648b83a4f09b4ca2021f0c193c5c41df1465715761bca52671ca790a3e92d67686b97b3d54c6110409779df887bd9c6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4a58b0ccdc9ba7bd7ac424e1e8b961ffc3839ce06f200551b7302a33d96a8c047f1184889c21711fc2de482c8a9ac05043ff957bee33046cdb77ec386225bf885776275e0643b155d528ba24ceab1c96e2c2da2d64021f7a26f742341f1c6f4" deposit_data_root: "0x1edbb8a2956dd6fe52e14a004566f29757e212de7f64c8d98070f33ba78a78d6" eth1_data: deposit_root: "0x3c6fcce34339d0a97e566eb15d960c2b79440eb5a55a2a2e66dee1a3f63e515f" deposit_count: "40" block_hash: "0xfdb11831fe4c2fc8596455800b8420cce083f2ff92552d4255876432038a335c" block_height: 41 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" deposit_root: "0x3c6fcce34339d0a97e566eb15d960c2b79440eb5a55a2a2e66dee1a3f63e515f" deposit_count: 40 execution_block_hash: "0xfdb11831fe4c2fc8596455800b8420cce083f2ff92552d4255876432038a335c" execution_block_height: 41 - deposit_data: pubkey: "0xa34febc12af07316580b480364f90a76313ccce7927bbe263e27ea270853b02ad4d1428caf55363f3ebebac622cb9fd6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xadbf354b18eaaed15a3191ee9dc053d250fb54b59959eaba812b8a589797d5c310170da7b98b0448d4a3aaf3091305bc07b6c077b5973fcf0c7d5aefaacea5b6988b297f336841215a5bbed37f0271b325b178a4bf0835bfceae150ae6b3de37" deposit_data_root: "0xcde3ed824c06263d6e165d50f2781de0f8e4b36f6e4167427a3e9b90ff45f7be" eth1_data: deposit_root: "0x3fdfcce325e69c97df3b47c43925e4ff58f633e9c1a4fcd6997c98a4d6931406" deposit_count: "41" block_hash: "0x4b93ca227181f17fc7c4f95ec672f19a1485d4ebc1981de852066119ede6f989" block_height: 42 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" - "0xcde3ed824c06263d6e165d50f2781de0f8e4b36f6e4167427a3e9b90ff45f7be" deposit_root: "0x3fdfcce325e69c97df3b47c43925e4ff58f633e9c1a4fcd6997c98a4d6931406" deposit_count: 41 execution_block_hash: "0x4b93ca227181f17fc7c4f95ec672f19a1485d4ebc1981de852066119ede6f989" execution_block_height: 42 - deposit_data: pubkey: "0xb8cd1cef89aa1567a6058957442a698cf1b267130606f749451152959a5dfb50d243890d4adc2c3309f7696d54af1260" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x95031abea421c3997538c779d67489c04c635449f753f8836400532d70e6c4c7d0e42117b773da9b365dd9590cd01ad6079cdaa62e7ce21911bd519218064200e3d15ad252a072eac4554da519bb23f609b63684045b209933a5398606ba8aaa" deposit_data_root: "0xdc998298cb82156f077de9a7289d8e92e3270653d4c5388f6ff11102dfa75a15" eth1_data: deposit_root: "0x60ad801fc6a68abf39ce5ee6db6913e019e9370ea744c3d4b7436f1bd1b7befe" deposit_count: "42" block_hash: "0xdd485eb08d480f2e25f7ae196f4eb69eaad495bf76be1c9c1d237f92ca6c0d40" block_height: 43 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" - "0xe3897ec112ed55cfe802be2b7c9dfcc1b5a274736d0a8d8588d28b93bc2e26c9" deposit_root: "0x60ad801fc6a68abf39ce5ee6db6913e019e9370ea744c3d4b7436f1bd1b7befe" deposit_count: 42 execution_block_hash: "0xdd485eb08d480f2e25f7ae196f4eb69eaad495bf76be1c9c1d237f92ca6c0d40" execution_block_height: 43 - deposit_data: pubkey: "0x92a93728c252a45ef587ca53a037593912599d82e2b8aa1b734b99d500a0ac8c142092ea8b3c2c34a28dc8ddf337a249" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2efbb211e85d2a8cd924085571ab0637583a0fbe41a4f2f4e5b173631067f69fa0eebd2910673afe6bd59bb6f34fce60a974adacb5c1edf47bf8d81084a26e9cc16c553c1601594a393172613cdde131b96434801b6b77ca08f00db29294ecb" deposit_data_root: "0xd038d18b6d28712d26bfefef79e3df36a9f5502e066f1a6667b0a0aca21322f6" eth1_data: deposit_root: "0xf82bbce9e12b06f122b0c9db7b2a24484f78772401aaf5056610de1071de7829" deposit_count: "43" block_hash: "0x65a8f07cef0dc9e98a8b3c685ed6a36bd6ad5fb6e97b57d202074839fd857e10" block_height: 44 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" - "0xe3897ec112ed55cfe802be2b7c9dfcc1b5a274736d0a8d8588d28b93bc2e26c9" - "0xd038d18b6d28712d26bfefef79e3df36a9f5502e066f1a6667b0a0aca21322f6" deposit_root: "0xf82bbce9e12b06f122b0c9db7b2a24484f78772401aaf5056610de1071de7829" deposit_count: 43 execution_block_hash: "0x65a8f07cef0dc9e98a8b3c685ed6a36bd6ad5fb6e97b57d202074839fd857e10" execution_block_height: 44 - deposit_data: pubkey: "0xb7ee0ef26144de04d9cc80864b869b7ecafbf1b7c0050403cc3c3b514368713b8bb708c464568a18c837e1fd21d09063" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa356193c75dfb2c15995650552d0ca9df6d9adc19dd19dcd26d79e88420fd0b1ad7a923e6c44ec5de81b5306b93f36040341b2393d40a3b0cd70f6f71dabac60bf2d1948a8e2da190316b56ebd84d9ecb7fd6d894380331070885da41c9b6277" deposit_data_root: "0x433ac5e37040ef1005e56991ecc42a7207b1557a9d446e5b56a3bb8a617f52fb" eth1_data: deposit_root: "0x9d13195b240044e78fe982d51b31223feef1d8997e9f8231ac727a05343c55cc" deposit_count: "44" block_hash: "0x3615ed6ba3c2eac9dfb051aa571d6275395111b6eb80f82acd4da05cfd687f5b" block_height: 45 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" - "0x7d41f8f8048c87f844b352ae9a9900997fe13c3cb8786346e55ba2c5affb00d2" deposit_root: "0x9d13195b240044e78fe982d51b31223feef1d8997e9f8231ac727a05343c55cc" deposit_count: 44 execution_block_hash: "0x3615ed6ba3c2eac9dfb051aa571d6275395111b6eb80f82acd4da05cfd687f5b" execution_block_height: 45 - deposit_data: pubkey: "0xafc0fa2ed6a270de6122a19d4600380b7f9b5e974d16f095f1702f55792ecab0128b155a69f17ad64a6de0a7063642ec" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c256c7242c520d646b3cb21d1fbf19097b8131857e7dc246fc81dfe8389b2335d9e1c2e394051a8293ec33bddb006c018696be5402901b5f9446d97cb9f8c5fe48c501e13382801e4e96dfae1df99471df39cc82741590c6915624f63d8bfaf" deposit_data_root: "0x2522ea9a8f9dd6862e56af3f38827a80813082b521d43b7e21903c5b81fc1290" eth1_data: deposit_root: "0x1815da8f5d53ed18c0db0942e6e06bbc1e1e87cc21dd186b66d3a654fbb2aae4" deposit_count: "45" block_hash: "0x2ee3c9a0d2109d8544754a4d3771e393d9f15c55211c92be0f486e7478840805" block_height: 46 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" - "0x7d41f8f8048c87f844b352ae9a9900997fe13c3cb8786346e55ba2c5affb00d2" - "0x2522ea9a8f9dd6862e56af3f38827a80813082b521d43b7e21903c5b81fc1290" deposit_root: "0x1815da8f5d53ed18c0db0942e6e06bbc1e1e87cc21dd186b66d3a654fbb2aae4" deposit_count: 45 execution_block_hash: "0x2ee3c9a0d2109d8544754a4d3771e393d9f15c55211c92be0f486e7478840805" execution_block_height: 46 - deposit_data: pubkey: "0xa5869ba554d1432b09ee677c117511291b9901f169e870831f457caa6ccfab376cb1fe33813bdb495cf4afec9ea35fdf" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x91cd39a6714d4851e7927c03e5039fed3725573cc1e6005bb20ba21e47ee63ead1defd93963ad5905c6f8074b1197c131011daa8be473190c83523e3028db2f8dae5ff7daf1f708f2830b0ab70916a20154e8135a20972109cfcc1f76bb05caa" deposit_data_root: "0xd716729370e1d97244f1758c3f5540e29461b31686c30dd333abbbae979e43a4" eth1_data: deposit_root: "0xda383b51baf43274f4bc3a1f6573a660a0f49feda6d3cfedf3aec0050a8bff02" deposit_count: "46" block_hash: "0xdc9667ffa9917e167974cac3e67dd0845657c81556dbf51e77b6915a2741bbb2" block_height: 47 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" - "0x7d41f8f8048c87f844b352ae9a9900997fe13c3cb8786346e55ba2c5affb00d2" - "0xbd3a8edc6db6b9fe322ca4af975e44750c273e56b1a6730a29adc004939ae9a8" deposit_root: "0xda383b51baf43274f4bc3a1f6573a660a0f49feda6d3cfedf3aec0050a8bff02" deposit_count: 46 execution_block_hash: "0xdc9667ffa9917e167974cac3e67dd0845657c81556dbf51e77b6915a2741bbb2" execution_block_height: 47 - deposit_data: pubkey: "0x92f43d79d9f488010b310a54f3fc2e7f4be191ca06d93e588c30c8abf59a52190e060b285ac626eb13cd95bbcc3a0a2a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x921608298683b15a514c05fb08f39958123498b48d8bbfad1fdd62fc84556aaba3b363e3a20c8423c9b8a157690241bb0ecfeeff3393f4502a2cd14cd8e2fa2373ddba64b573e1ec4c6941ba7cc423248878b9d46444ad8c10bd6f4bea2234e6" deposit_data_root: "0xd5d100cccf8847fdf9b03e33e030d4a7dfc868e3c3b6107c4849bd78140bb87b" eth1_data: deposit_root: "0x62b97e8c2969a6f0d48a9f61a762561a8c7189af1c178b9215771e614909e7f8" deposit_count: "47" block_hash: "0x75bd1deec6fafccc3cf68485f19eba3c5e0edbeec29ae9f7c59b44f5c44a6f0b" block_height: 48 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xd499ae9a9b57a50ee29e23a5f5130a7ae9dd46ac336b2741be8f300c7ff363e4" - "0x7d41f8f8048c87f844b352ae9a9900997fe13c3cb8786346e55ba2c5affb00d2" - "0xbd3a8edc6db6b9fe322ca4af975e44750c273e56b1a6730a29adc004939ae9a8" - "0xd5d100cccf8847fdf9b03e33e030d4a7dfc868e3c3b6107c4849bd78140bb87b" deposit_root: "0x62b97e8c2969a6f0d48a9f61a762561a8c7189af1c178b9215771e614909e7f8" deposit_count: 47 execution_block_hash: "0x75bd1deec6fafccc3cf68485f19eba3c5e0edbeec29ae9f7c59b44f5c44a6f0b" execution_block_height: 48 - deposit_data: pubkey: "0x9698d9519a02b64f230e5a2520401799c2ca7d69ab23a6d9817943147264bf00d409264b928718245efff4f7ee97dd5c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xae3dcc94f04909fa6d3c8b56c6af1e037064eea73a5ee9300b2bb4655cd50e4e082108b3009c13d1deb4b94f7ff4c7cf028cb95f86c1e354892263d43826de017601f20c5fd99eadf42e1cacae7c2698715be3582d3cba2d2962891fb1dc58bd" deposit_data_root: "0xbc47514e4e62c58f75742971af992d758dad75cf523eccbdaa33bee01a290794" eth1_data: deposit_root: "0xc36afe52bbbc41a91a58ee9e37deb448edd44992b00cb0bc8b5a32d46ce5dfff" deposit_count: "48" block_hash: "0x296842ff1c8cdd3e7729800191fe9a1da0209b1f554709867dadc6942510d3ab" block_height: 49 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" deposit_root: "0xc36afe52bbbc41a91a58ee9e37deb448edd44992b00cb0bc8b5a32d46ce5dfff" deposit_count: 48 execution_block_hash: "0x296842ff1c8cdd3e7729800191fe9a1da0209b1f554709867dadc6942510d3ab" execution_block_height: 49 - deposit_data: pubkey: "0xa852816b8e463178eea5acebb4b86d0acb6d8c6812cf313296bd271ea4d2fd89d281e5fc296df4df49019169bdf96922" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa562944e5476538903b89274c26eebf2bf87547968022140c4c950fcf9c02140ca064cdfa79aeb3bb0d0f738b2f56f401501fe791231633153ce1a56ccec8b8ba3b3d104b00b6477c89cf887b65d4ebc32c7f8d4d692288068941131d50c286" deposit_data_root: "0x15e2e2026f0b8722f28569cf3752f02eec3d115c7a58947559fb0d40bc70f211" eth1_data: deposit_root: "0xe8659b62077801e4e285d99cb0f7df9eee6332af5d7173211c5119e89bfe98c7" deposit_count: "49" block_hash: "0x2ad547b4552b0d033398b10c76a224ea4e27af714a7d40208a1bcad524bd3de9" block_height: 50 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0x15e2e2026f0b8722f28569cf3752f02eec3d115c7a58947559fb0d40bc70f211" deposit_root: "0xe8659b62077801e4e285d99cb0f7df9eee6332af5d7173211c5119e89bfe98c7" deposit_count: 49 execution_block_hash: "0x2ad547b4552b0d033398b10c76a224ea4e27af714a7d40208a1bcad524bd3de9" execution_block_height: 50 - deposit_data: pubkey: "0x8a298ee1ac0466ecaa04d5798048c6e192409af63217f32fd7e07794cfcdcd8deca055b9782dd1ad45a578a9ec10606c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa14f099ef773a2282a7c0d664557897c48aa594015e05373a5fef26c8dc848ae0c25718d3a9be982117159c908abcc1e0aab94110824c8410ea08039398a8569a844cafd9002ef319a2e6a0717a5b340a4d153e6f136be7a57ee5abd73cf7017" deposit_data_root: "0xc46f9746cf62672d7d8ed56c05a7dc880f2475a6bd8a73151abef6f88907d53c" eth1_data: deposit_root: "0xc30f240a494e623caab8bc918828d31feea930902c6e3dca2c3a423f3f0bf102" deposit_count: "50" block_hash: "0xdcf96433eba5c4c5877afce8ecd730c943b0b3b02c6b36593fda5839cc095d7d" block_height: 51 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xe74828c6edb30e3e4bf54de63aeab6c3f97f7d6f3a558705eaedef064b8645ce" deposit_root: "0xc30f240a494e623caab8bc918828d31feea930902c6e3dca2c3a423f3f0bf102" deposit_count: 50 execution_block_hash: "0xdcf96433eba5c4c5877afce8ecd730c943b0b3b02c6b36593fda5839cc095d7d" execution_block_height: 51 - deposit_data: pubkey: "0xae4d49364e4a36760cc74a675500055b9aed99bc19d31abb953ea156bb5a76dcf36769d15341b850114a30ffc8057780" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8fd33d2856c669b84efb3465006ba799fd3c680a56b104edc738107913fe0f91a6f99b7a69c337a493d8ea43791127211de5d964d1840fc403151a92d7b28cf8b141caa76807a06b673421effffa1d4e718ebe7fd27e59f1525126a01ab4bc4" deposit_data_root: "0x9330e615cf2658bb9b5039e5c6eea90714a76b3b8f3759dff1e295c364f695db" eth1_data: deposit_root: "0x0e258dde53879f7f68ee782954ca2b25d222447991919c685f637409175252be" deposit_count: "51" block_hash: "0x9678505c7aacb038cfe8edc0a224c5eb2d1abfdd5775bc6d6260189c247e3443" block_height: 52 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xe74828c6edb30e3e4bf54de63aeab6c3f97f7d6f3a558705eaedef064b8645ce" - "0x9330e615cf2658bb9b5039e5c6eea90714a76b3b8f3759dff1e295c364f695db" deposit_root: "0x0e258dde53879f7f68ee782954ca2b25d222447991919c685f637409175252be" deposit_count: 51 execution_block_hash: "0x9678505c7aacb038cfe8edc0a224c5eb2d1abfdd5775bc6d6260189c247e3443" execution_block_height: 52 - deposit_data: pubkey: "0xb397692ccbf442bfe078174c85dbad7fd605e4ff1caf2904b31e4a4c79d6444813ad9b2093ac8fbd4dd59ec7a4c8c006" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa10cd137f49972e2e2a053abc96a1e356a4a65b9beac4b910a867c5e150e77a8b66cf7e32dae3ddcc1be9643a1ed775d0e6ab93def5f8685f756a014d6d6b721ce5b7d17cc85d8fefdf89276bbf67cf0b5775ef535bdea61a5fbe40b32d318ae" deposit_data_root: "0x3170a57af6642be1e018dba7471b811acfb9ec1b9a66eddd3f28666e0001c492" eth1_data: deposit_root: "0x1b23c0123f7e5de30edcc56f34eef43f3dec1cee9374fc72a9f8d92b34111b1c" deposit_count: "52" block_hash: "0x2d4a16997b0e306d3e8f22dfd9b465ec6532273d54608973da7900e7223be426" block_height: 53 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0x7d1f34ae9db53b9a029e24b8d766e0e54a464ac4eade9210f96eb71d77dbe9c0" deposit_root: "0x1b23c0123f7e5de30edcc56f34eef43f3dec1cee9374fc72a9f8d92b34111b1c" deposit_count: 52 execution_block_hash: "0x2d4a16997b0e306d3e8f22dfd9b465ec6532273d54608973da7900e7223be426" execution_block_height: 53 - deposit_data: pubkey: "0x87c9f7605d07550b46c79add5ea4e39de5014c03833669257bd6666b7ec838f53800104779940d8cdd884275a0f6a3ef" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb6a8b8d4ea3c51c1e53f1eb8eaca900db9c70a2c7c11f555856b6aff737c972c9f5871bbc8fb46d6ca3f33b271c8a7e20976ca805666b41bbe38a576167466db0f8beaa28995aba1ff250fa3e4f87a0843d3941ff477528dc7daad37f5a720a1" deposit_data_root: "0x0c0f4d2950ee7d4b8062761154cfe0c1d6f13d9a4d5e2fef701ea38614add54b" eth1_data: deposit_root: "0x89aeb5a6e924afe40fa404ce4c31a09ad222c9f3dddfa1df9f4946ba81243754" deposit_count: "53" block_hash: "0x5279517c77c4fbf7e0c19cae59db917ff0ec55bc62ec2254df5cc945eb415daf" block_height: 54 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0x7d1f34ae9db53b9a029e24b8d766e0e54a464ac4eade9210f96eb71d77dbe9c0" - "0x0c0f4d2950ee7d4b8062761154cfe0c1d6f13d9a4d5e2fef701ea38614add54b" deposit_root: "0x89aeb5a6e924afe40fa404ce4c31a09ad222c9f3dddfa1df9f4946ba81243754" deposit_count: 53 execution_block_hash: "0x5279517c77c4fbf7e0c19cae59db917ff0ec55bc62ec2254df5cc945eb415daf" execution_block_height: 54 - deposit_data: pubkey: "0xb08f7feb86786c37661afb9951a959c9b465fd11ca98fcbc908fcf49144084051f6c363e2eb4459da2c2d03d84175692" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x86fb9f4c6ca3c5453646471e6393f1260f04f25bae62541203f6dfbfaf226dee57b0b6a1b2d698d3630a4ae418f7986b0273299006e4488f835612311eccb1fecaf576e1740d29b0c26478ec11eaf644b3e3c696ebe562e6942d282bef29f82b" deposit_data_root: "0x04e2ccad9538abe82e053c1414dcd8083d20206e84a3ce294036e271bf391e7a" eth1_data: deposit_root: "0xd749a15bc781e795b4e88adce9dbd068f0350586391f8170e025a4a671c7be06" deposit_count: "54" block_hash: "0x7a5b1937cf1cf319c059b24ac4d7a905d841d3c725da9597f32cd609159f1e04" block_height: 55 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0x7d1f34ae9db53b9a029e24b8d766e0e54a464ac4eade9210f96eb71d77dbe9c0" - "0x45ae70157fb3f9a80f56cedf94dd1211a7bb8fe79527c7077097c766dc4fcc92" deposit_root: "0xd749a15bc781e795b4e88adce9dbd068f0350586391f8170e025a4a671c7be06" deposit_count: 54 execution_block_hash: "0x7a5b1937cf1cf319c059b24ac4d7a905d841d3c725da9597f32cd609159f1e04" execution_block_height: 55 - deposit_data: pubkey: "0xa48cc260df1df875176cb17493a5b53d669c091da74d5075acb8952a641b1b7ef68d01f009c1a365d2fa80937c79dd6b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb3c12fa96e2938a28f872bdf1e62a037dcbe3d5fb0e7cee58bcd2d2c6d82ffdc6428a5ec997a8ae26d113f30959fddb407f319ef49f989fdee215aa96d2fcf30b6154590ee9f856daaccd20c344fa5d4b4cb6678a3409aa619af35bed6f5259e" deposit_data_root: "0xfefb7de90e7a23e87b7df79ef2b97df376a89aab301014112ce01f2362515d7e" eth1_data: deposit_root: "0x92e91d9cb729330a946dea613ffd50ed1911c3b7cdb92a7e400d486310a77c6a" deposit_count: "55" block_hash: "0xfb4bb38d9560af55e012e04dc652fe291826bbd4dd8fdc350300f9d97e463ec1" block_height: 56 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0x7d1f34ae9db53b9a029e24b8d766e0e54a464ac4eade9210f96eb71d77dbe9c0" - "0x45ae70157fb3f9a80f56cedf94dd1211a7bb8fe79527c7077097c766dc4fcc92" - "0xfefb7de90e7a23e87b7df79ef2b97df376a89aab301014112ce01f2362515d7e" deposit_root: "0x92e91d9cb729330a946dea613ffd50ed1911c3b7cdb92a7e400d486310a77c6a" deposit_count: 55 execution_block_hash: "0xfb4bb38d9560af55e012e04dc652fe291826bbd4dd8fdc350300f9d97e463ec1" execution_block_height: 56 - deposit_data: pubkey: "0xac9f4df3f20a16a9fefad08817fcbc9a6ee17f7512db006414b4aa6f234c2313585ef72c5776df55fa6284af4bc3f631" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa5d0be0b159b75f2524e1bc1243bb8f1272716daa2a1c635f0b34004b30d9038450cbd9b72f29a17d1fb4d99857fdbd710e2edb2036aa89589d1344b6e3984fbaa44ee0409fa048d0dd86aa1aa0164663b187e0ec9f798b490dc4b34b095152f" deposit_data_root: "0x5568cb23722d865d414baf5f7ee92234383e175fb3e5b7cae390244f9735987b" eth1_data: deposit_root: "0x565ce384ec4ca0d45ab8c20b895996f4dd15f01f00497b24cdaf6378602efed7" deposit_count: "56" block_hash: "0x13a0c8bcd47c1e4d208515dfb6e9773ee2d5f894691e7986bb8d8699f33d9495" block_height: 57 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" deposit_root: "0x565ce384ec4ca0d45ab8c20b895996f4dd15f01f00497b24cdaf6378602efed7" deposit_count: 56 execution_block_hash: "0x13a0c8bcd47c1e4d208515dfb6e9773ee2d5f894691e7986bb8d8699f33d9495" execution_block_height: 57 - deposit_data: pubkey: "0x94f0c8535601596eb2165adb28ebe495891a3e4ea77ef501e7790cccb281827d377a5a8d4c200e3595d3f38f8633b480" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x87d4271630df8e3780900e5171d3642a781205154f11be812e923c87d19a3224213b9dad62ed42f1126a0b52157afa9e16acfecf96c7f8c2345bc1f744e491136cb100d82f549467f595fa6393ff0f8d0dd83cf5c95d88c47d0023bf0796fd6f" deposit_data_root: "0x6adfa7ccc8b757b108c02b37ee27bc04e83e9c7538b1c07ebcf342d564c56135" eth1_data: deposit_root: "0x352eee8320a9c83dc4f9b5086b92df7ab3d1844f77cde7f3c3daf8905d91c4d0" deposit_count: "57" block_hash: "0x1023685ab1df034f7762e46035d995d87f972c29ffaa097a5b6301da756398cf" block_height: 58 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" - "0x6adfa7ccc8b757b108c02b37ee27bc04e83e9c7538b1c07ebcf342d564c56135" deposit_root: "0x352eee8320a9c83dc4f9b5086b92df7ab3d1844f77cde7f3c3daf8905d91c4d0" deposit_count: 57 execution_block_hash: "0x1023685ab1df034f7762e46035d995d87f972c29ffaa097a5b6301da756398cf" execution_block_height: 58 - deposit_data: pubkey: "0xb5bb0162a4f27d1bab4c7dc3d20f5a75d6ee98c56bcd309a1f0f307685ad47ffb8a35bfdf8431b9b954b59662a74c478" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb091cd5476b2bceec9f6cba38b3787fb080d9ea63cd6ed19eebd72be7ab0887e44f233e993b9ded4fe33353a9aba5a9206b8a9da387d222e58bf05cf333b25f6559557cf95645c785c75683317a1c97dec807770e57d581107e9fbca03069eff" deposit_data_root: "0x9fad5a196b6ac7c47a1fd191fe4eac56bd9b9fed5d275ad0311e165059d7d40e" eth1_data: deposit_root: "0x349bbbc8e21e10251fcfceec3821ea9dd2806526e71fe472bb8b84d8d5458f5f" deposit_count: "58" block_hash: "0xdeaa8a27fbc74fcbda0b7a30da9c4e4392a9f961b90c45a272a204bbfb5d8d4e" block_height: 59 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" - "0x2ef9c25463a9664b369b20321671d2fec217ea4c64ee3a714e5983a0be95acd0" deposit_root: "0x349bbbc8e21e10251fcfceec3821ea9dd2806526e71fe472bb8b84d8d5458f5f" deposit_count: 58 execution_block_hash: "0xdeaa8a27fbc74fcbda0b7a30da9c4e4392a9f961b90c45a272a204bbfb5d8d4e" execution_block_height: 59 - deposit_data: pubkey: "0x8826e820179fd321819e78ffee16f50ac528db2da71ad8c269f60b878bc4887c79c0545b3d750e86e490d5ba9083cb70" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x95622cabae0c3d62f58fba1302e207d5ce92aa3df653968f020dce42b84d49ac928f7ebce159b2b5fa55115bcd0895820269879dd4ebea6359d5c9d8b9c209cac6891552985da1e64a60e6b0959b2bf0ed81d97381ef9b1e0aa59217e9dbd280" deposit_data_root: "0x80ecb93497e9a21c4e6d48528adc8d32ec4808a275fcdb2ecab6fc052e6936a3" eth1_data: deposit_root: "0x56f2b33a48de69dc2f0652bb1d6d4a63de86b9db2319b51f59f93225d93787e8" deposit_count: "59" block_hash: "0xecfb4b768d48d31ac3d30f640d00d0afb9c932ba7316c9f21ede2ece7e4a65c1" block_height: 60 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" - "0x2ef9c25463a9664b369b20321671d2fec217ea4c64ee3a714e5983a0be95acd0" - "0x80ecb93497e9a21c4e6d48528adc8d32ec4808a275fcdb2ecab6fc052e6936a3" deposit_root: "0x56f2b33a48de69dc2f0652bb1d6d4a63de86b9db2319b51f59f93225d93787e8" deposit_count: 59 execution_block_hash: "0xecfb4b768d48d31ac3d30f640d00d0afb9c932ba7316c9f21ede2ece7e4a65c1" execution_block_height: 60 - deposit_data: pubkey: "0x92977e71396633d442f61e16a0cfcf8ffad0af93c9f1b7fdf4f7ccb816de052925fc192922d6252d325ef9fa2e0595d2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8645569a7d2c3a844a0215c163fb2e247b4201161e2399f213c0985b568ac98961398f0c712c05892857cddf384a12e007ad9412dbbc26b18b7e76b9a5d5735db8dd0142e879b7b46f8d42dc05be19ec9cc9bd42b741cffbbc250d576f86232f" deposit_data_root: "0xb4fc5adc460335413f7ddc9f38007ca12c841212a86961b3190b566e371b6fcd" eth1_data: deposit_root: "0x2badea58e40583186b7ad89ed366eb9fe85cd849309ca43bf5f4703b45c7c9bd" deposit_count: "60" block_hash: "0xb6a0eed143a5b2bd2ccace6a5f28ec0b9ef819eb82a781b12f82ff9e717077c7" block_height: 61 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" - "0xc7acab11e9b20b4a85bafee152a8fc5314df74b63c324dd84a917f89c3c5bf0a" deposit_root: "0x2badea58e40583186b7ad89ed366eb9fe85cd849309ca43bf5f4703b45c7c9bd" deposit_count: 60 execution_block_hash: "0xb6a0eed143a5b2bd2ccace6a5f28ec0b9ef819eb82a781b12f82ff9e717077c7" execution_block_height: 61 - deposit_data: pubkey: "0x91ae4686b0d20470409f020eaca826c3efc6c1926ed25d05e6f0f7916391ec89c2341917277c437ac8fffffe94b68111" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa88873293cce3d3e180c98a6e973057873578ee51480e5d2a821c6137aa143ab8ccf64dcb131013b6203fdbbbb848efe015949a431ff7b401b131ab6d33ce9dcc698c00e3503c5cd98d935d2040952dc9a863fa7e8ff60e52088ae198773b740" deposit_data_root: "0x75dac1ed3a104cdfa3e93c4b91e85ff6bd7a309a3f881fedf48219657ba71993" eth1_data: deposit_root: "0x243b61a30048fd9847aa0c1424feffee5876462556952e6120800137cdfca8cc" deposit_count: "61" block_hash: "0x3febb45aaa3b77bf4190c51f349ae02ab28df9c090a727294f2d6850feaf71fd" block_height: 62 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" - "0xc7acab11e9b20b4a85bafee152a8fc5314df74b63c324dd84a917f89c3c5bf0a" - "0x75dac1ed3a104cdfa3e93c4b91e85ff6bd7a309a3f881fedf48219657ba71993" deposit_root: "0x243b61a30048fd9847aa0c1424feffee5876462556952e6120800137cdfca8cc" deposit_count: 61 execution_block_hash: "0x3febb45aaa3b77bf4190c51f349ae02ab28df9c090a727294f2d6850feaf71fd" execution_block_height: 62 - deposit_data: pubkey: "0x8a0d241955104bedacb3b829162f2b457915c2beb9018ede8ef8ea80f401b471c42354358da9e62b51c38d54263a78a9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa073c1da30c9555dde136f86879936cbf247828ad39b688058b8dad95781651379dfce772fb5aa93d60e50d0d2374ada00e3ebc42e2b1d732512f990dafa34dc7dd1553bff38a171b06f0b215f40bcf5fb354d914bb595acb8dc49d042896ff7" deposit_data_root: "0x3274fb1171cb037b6242c298f1680eaf23f01ef807669e9b00f65eafe0640a1a" eth1_data: deposit_root: "0x52e5a1f96b0f8c69423bfbeb7ed3888cfb9c9098eafd0eeb14a9a8c21d77d245" deposit_count: "62" block_hash: "0x8fbc1f4ff163d89df6143c66f1df08196d0313df09ff0b062925ec33e48415bf" block_height: 63 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" - "0xc7acab11e9b20b4a85bafee152a8fc5314df74b63c324dd84a917f89c3c5bf0a" - "0x997db7123f404f063da7db4a2d3952d11f30820ec8445b5da03eccfde69e946f" deposit_root: "0x52e5a1f96b0f8c69423bfbeb7ed3888cfb9c9098eafd0eeb14a9a8c21d77d245" deposit_count: 62 execution_block_hash: "0x8fbc1f4ff163d89df6143c66f1df08196d0313df09ff0b062925ec33e48415bf" execution_block_height: 63 - deposit_data: pubkey: "0x80a2be2c7dbce8ddc2eba03522697587c375a5a9e92d4b31ed9e3c34bee047095d93e3c70b1662b3faa301f5b19978e5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x81e2f7ffe007e2d6b121ec976d7a9d3cd053d82cf07f2411184522664755306185dbb3352c5bd7e83154fafb34a56f2601c164f280e447e64655ba7e9457f5967f15eb4d6080af7ef971b9067a498266fb3afd979a251169402cb4d80205b9e0" deposit_data_root: "0x75169d67108dcd4c68492847c39c0f7b24ecbb2a0240e62dd5f72518e142df11" eth1_data: deposit_root: "0x8ffd6666bccbb0269e2df5e53b91844c9bdbac57d3089d6d9a4d91c1963a61c9" deposit_count: "63" block_hash: "0x4d7818aafb46a6f055359d6d7c664c3b36599a2dcab8cf332ff896345bc0cab1" block_height: 64 snapshot: finalized: - "0x378775a69829a0b8467bf331f4815d2ab91c796f5eb14cd9c08347421a245f2f" - "0xdb1b9444d0f397f37f74bfcd3cc45beb343c4fe728174c624eaeb3647745b17b" - "0xcc3b81ef99612124c28a53fdad6aef205b53c82843c080b9f269b80313fe7481" - "0xc7acab11e9b20b4a85bafee152a8fc5314df74b63c324dd84a917f89c3c5bf0a" - "0x997db7123f404f063da7db4a2d3952d11f30820ec8445b5da03eccfde69e946f" - "0x75169d67108dcd4c68492847c39c0f7b24ecbb2a0240e62dd5f72518e142df11" deposit_root: "0x8ffd6666bccbb0269e2df5e53b91844c9bdbac57d3089d6d9a4d91c1963a61c9" deposit_count: 63 execution_block_hash: "0x4d7818aafb46a6f055359d6d7c664c3b36599a2dcab8cf332ff896345bc0cab1" execution_block_height: 64 - deposit_data: pubkey: "0x86a73886aa0114bbdbba346cb7c07376c81b549a4802c24d98ebbc54a6a1b5d2ac874ef657cfb27c3644fcb85f97a2b5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb697a8a9e4d724302efb08e88ec4308b803fe8544cd5d53324dce4b601a18a66fd612318734d520d5909051f62e9e9e90823a7bcb951c2b5b9d349f0c5b57ff748ec93a1750df96e212f39900eac541d0753683d46a375a421300c0434c3fa88" deposit_data_root: "0x1418de3c263fa52285b93a809f16134cf4e008bebd2d81da7eb7d6f2a22c61a2" eth1_data: deposit_root: "0x5c7e3d0e9ac6cd2613e89748ec650d1ec5d44bf936c7761a0f5fc9526f263e17" deposit_count: "64" block_hash: "0xab873b4514bca399da91a00dc630df65bf37f53517b54c075f2f40a01e47661c" block_height: 65 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" deposit_root: "0x5c7e3d0e9ac6cd2613e89748ec650d1ec5d44bf936c7761a0f5fc9526f263e17" deposit_count: 64 execution_block_hash: "0xab873b4514bca399da91a00dc630df65bf37f53517b54c075f2f40a01e47661c" execution_block_height: 65 - deposit_data: pubkey: "0xa98c264dfc3bc3ed635df5dbfd54909e77600cd68480ec201d9f5c416580591daaa9735b04743e10e7fc6370a8189775" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa946b360375c6dea0c890263ccdefeb4f4a815bea7ebb6513de80f7932fb34ed36f3d5e41f26a9ef1550531d7ae807cc1094b7b5cdf2682ca713658ee8ffe4de45a0a20d8ea3a10b141e4d831030339e78936f04363529be77fcee46d4a9642a" deposit_data_root: "0xb484b20a0bc7eb410b062c857ecce9460c3aa86b2b81133ef727507bb60c6f9e" eth1_data: deposit_root: "0x5744f4e817aaa5221b70a045adde9f74069f40880a4646630c0417afc759a267" deposit_count: "65" block_hash: "0x9f358a6ec47032ba2fd6e11f79da1ef89cde8d1cdfdc3f8f21006fc056a1ad61" block_height: 66 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xb484b20a0bc7eb410b062c857ecce9460c3aa86b2b81133ef727507bb60c6f9e" deposit_root: "0x5744f4e817aaa5221b70a045adde9f74069f40880a4646630c0417afc759a267" deposit_count: 65 execution_block_hash: "0x9f358a6ec47032ba2fd6e11f79da1ef89cde8d1cdfdc3f8f21006fc056a1ad61" execution_block_height: 66 - deposit_data: pubkey: "0x8bb7aa61aa8bbd2b7825d28c340da89b625381232dcf2742276b4e3a2e4a0f42ef68794fdf005d94014636732fba2f40" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8adda613ebf39f91333958b18dfb271b5b75d97342a9447e5371e31af7fdbec354687868cbf1f2e57a71c3aee43e623f0a6161ff94eebb064cf57aec311e0f638b24b864c1433622b5236e5d33e410626c34784e8409a90bcf855192fc1ae0b5" deposit_data_root: "0xebac12ca39e81dcea9e7c2de29be0ffed4b4b560c5cf4539f3c3d7789ddf03df" eth1_data: deposit_root: "0xce3f915b2665672a9e96e35249fd4a07a0ff010b8f455995fb4d9d4d383d5921" deposit_count: "66" block_hash: "0x4fe81ed058f82fd3308a29454b21d44d977963ab016f3aa161803a909fe20768" block_height: 67 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xb74da2b05b56d5a84748b4616151668e0b0bf38c880acdbe71451e62bd7306f9" deposit_root: "0xce3f915b2665672a9e96e35249fd4a07a0ff010b8f455995fb4d9d4d383d5921" deposit_count: 66 execution_block_hash: "0x4fe81ed058f82fd3308a29454b21d44d977963ab016f3aa161803a909fe20768" execution_block_height: 67 - deposit_data: pubkey: "0x8bb9e1693eab1496d7583bf22fb1f2a475934c63b4d94118940617aa187bc277f738223e0ec1ce8a5566035d9bcc5470" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb00b5a95db40dd1b1bdbd364519b03447ed232d3c88dfad68203892523509831131f21b819260be2554d0e627f113f831477f83c9fc1948a451f4dab078c05376608168964fda9b8d033f8768f008fa1db2d0c61c47a9adb3812ef5e25f42889" deposit_data_root: "0xedbc4b624f488b096f5cce8386dc735682a0d890193dddc47273a3f8e9587c4f" eth1_data: deposit_root: "0x8039f6582e426da6ad47fa64f2b0c5927b11f9980914d12174d0d4c883ab1c21" deposit_count: "67" block_hash: "0x3dbbf6de20c3b31947160ee99b05fca4cb77b35ef72f7bd5ef183b57dde0f4bd" block_height: 68 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xb74da2b05b56d5a84748b4616151668e0b0bf38c880acdbe71451e62bd7306f9" - "0xedbc4b624f488b096f5cce8386dc735682a0d890193dddc47273a3f8e9587c4f" deposit_root: "0x8039f6582e426da6ad47fa64f2b0c5927b11f9980914d12174d0d4c883ab1c21" deposit_count: 67 execution_block_hash: "0x3dbbf6de20c3b31947160ee99b05fca4cb77b35ef72f7bd5ef183b57dde0f4bd" execution_block_height: 68 - deposit_data: pubkey: "0xafe6eface52fb6de91055a81abf9aa6e42ce2ef36fd8ae0d09aec6e5d8bd40a065dfccda6104af94df3f7a5854559ef4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x966e020128302f799fa32f954776a47b6e40fbf346c8055427254918a88c39609ead584b770a03a4425dfcf57fd79aff17f0ac1e364a383823fef8a7aaa06d3a252c6c8843ab9bd156bbb5ce8ecb542c5459c9d587e5e29e90f640c8fb1a16bb" deposit_data_root: "0x678f9a3c3a59f9118d5f278fefa238950ea26786faaf42d3d17096c81c89a78e" eth1_data: deposit_root: "0x4e422cc0aaad3a3a9f4e415a68f1286df79ea6a95326f73b6822bad8eeae6508" deposit_count: "68" block_hash: "0x64bb0a98a090f4763a6709b870b3366512db0c089547e1d2bfdefb531e7d08ba" block_height: 69 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x59fc60d715f9f381f553928b5bab510c59f2b5763bc27115827930abc8fa06e1" deposit_root: "0x4e422cc0aaad3a3a9f4e415a68f1286df79ea6a95326f73b6822bad8eeae6508" deposit_count: 68 execution_block_hash: "0x64bb0a98a090f4763a6709b870b3366512db0c089547e1d2bfdefb531e7d08ba" execution_block_height: 69 - deposit_data: pubkey: "0xaa241b2afbb33f92a5d281aec9c8bac8997c1dddc051455fc0f334de48320f160b5029b552495aed21ed9ce252aab499" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96e8e6ad4c9339471b4133f16fa80c48183a4bb54ae9f7097766112005375693dcbc459050d4a20a88a4d72601ea171402dbb3b934fecfc4e90c8aa8d9a20818086b126f0c72bf8eff58008aabec8834f8b252660289b818c1724b8fe6f75fbb" deposit_data_root: "0x27dfc1b46bf479c37bdfd8fdd34ab1f760dd118b031edd608a5b09e217f67bc1" eth1_data: deposit_root: "0x1878ee9b4d268fd60d60bbfa65e807f1e45331dfb13dcacc489de9dfc27f4a23" deposit_count: "69" block_hash: "0x899a35f3d719b2eb46085aea5820429a4ea164cc9092f096418df37fc8d5b3c4" block_height: 70 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x59fc60d715f9f381f553928b5bab510c59f2b5763bc27115827930abc8fa06e1" - "0x27dfc1b46bf479c37bdfd8fdd34ab1f760dd118b031edd608a5b09e217f67bc1" deposit_root: "0x1878ee9b4d268fd60d60bbfa65e807f1e45331dfb13dcacc489de9dfc27f4a23" deposit_count: 69 execution_block_hash: "0x899a35f3d719b2eb46085aea5820429a4ea164cc9092f096418df37fc8d5b3c4" execution_block_height: 70 - deposit_data: pubkey: "0x974b2aed17665e51c1c091998ca9649875330947de3d2733a5bd2eda69b0c593cdac2e416993a87f9a17aec1ccdc2368" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9695b7d689cb75c10edc7a6e7b9e03b802ed7e9256d589a7f5f2d192454a4b58000972109d812ca067b62caace91281714a783bcd8233414a5ca9abd3ff3e8b59d51b383079a61e3a5f9529f279d9e1f4fd818ad3daea046e883a9c0bbdd1b6c" deposit_data_root: "0xa827f1f12751ca75d95a814694177e948d61bb11d675d3730f8cdc8889329c71" eth1_data: deposit_root: "0x93fe27d7e2eb9366225f56a794563f4dfcf3696253dc58eb25eb54d0c0eb9def" deposit_count: "70" block_hash: "0x1ba29709a4d5765dd8ffdee19aa7407fd25c7173a3f71e5c7920f3f5ca941b49" block_height: 71 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x59fc60d715f9f381f553928b5bab510c59f2b5763bc27115827930abc8fa06e1" - "0xee50b240458527c727db7672bbeebac6a3d40f017fabafb80c39bc12ad50df21" deposit_root: "0x93fe27d7e2eb9366225f56a794563f4dfcf3696253dc58eb25eb54d0c0eb9def" deposit_count: 70 execution_block_hash: "0x1ba29709a4d5765dd8ffdee19aa7407fd25c7173a3f71e5c7920f3f5ca941b49" execution_block_height: 71 - deposit_data: pubkey: "0xa3177a98f653cea646f525f0f13348efb27e0d3d0cd824704c91d8d959096d259c9e577298f444acc629920c9619be50" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9985fe391e73d35c8044754de668b3113d8c341bcb04acbd6eddf8b683ea0fe5dc163b434243cb6ff5588a2d4146b1151851bd39edfe532a31a3b81afc644f3ae781ff2f6e73bca955fe47fa4029f8759ab2a6784e1eade8f34c97223bab6af2" deposit_data_root: "0x679b8078ff958c2a06ded461b6891f5a8038dc16adc475ba5867998a7d14adfa" eth1_data: deposit_root: "0x5173afe39bf20d7f26ab0d805059f50e0024f037cbc446e12171978d8d87e863" deposit_count: "71" block_hash: "0x7ed23cf2347fbaf8084d0c9b4acd2a88a5b793a68c7dd50d00627d4d6ad91457" block_height: 72 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x59fc60d715f9f381f553928b5bab510c59f2b5763bc27115827930abc8fa06e1" - "0xee50b240458527c727db7672bbeebac6a3d40f017fabafb80c39bc12ad50df21" - "0x679b8078ff958c2a06ded461b6891f5a8038dc16adc475ba5867998a7d14adfa" deposit_root: "0x5173afe39bf20d7f26ab0d805059f50e0024f037cbc446e12171978d8d87e863" deposit_count: 71 execution_block_hash: "0x7ed23cf2347fbaf8084d0c9b4acd2a88a5b793a68c7dd50d00627d4d6ad91457" execution_block_height: 72 - deposit_data: pubkey: "0xa8a18565733e70663c77bc0c80e08f50de908cc048152f1e7dae85d8cc218afbdd337d7d33a44e25400be2f06907c64a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x905cb27fd1bed206b261cb543ffd3fbed57f5b9d938c4dc488e1bd34d198395bbaf1237cf183cc73f5c8e2e31d20d4c40e191278661c85adfb507024b5e9a5dc3ebbed92e8aaa85c0cfc6df6b05375c26b2f49a8f695ac156bff342bf16fc4cc" deposit_data_root: "0x8bc78f4a029e716370a431e7034b9fa1991e36246d00fbf41a1dfeaba5748f67" eth1_data: deposit_root: "0xd09cddcb5675f6c5affff8a42f1fe425994bbe9133443d3f5516f8b34a9d0ba9" deposit_count: "72" block_hash: "0x16925bb1988c358148331ce34f247a985c829d8c14bed9481998942083cfe783" block_height: 73 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" deposit_root: "0xd09cddcb5675f6c5affff8a42f1fe425994bbe9133443d3f5516f8b34a9d0ba9" deposit_count: 72 execution_block_hash: "0x16925bb1988c358148331ce34f247a985c829d8c14bed9481998942083cfe783" execution_block_height: 73 - deposit_data: pubkey: "0x902ff56a7a4c5b6cc57708ea7b0b72cb54e4b821c95373f503648185f15208f6ca6281677fa0ecc14f911d7b7ca04f4e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x84b716bac859e61b80e0cfd3fc484d59c2865794d11e3264d58d6c4d2af2e2eef12a94944f331a4b3c83221a5d1fba2e10fa236515db3d9eaf92c4ff9c118cf73f0cb59b4c7b14f253e7c7b7b2cd0d23f659c24bd4f37a99ac82bed18c56e8cb" deposit_data_root: "0xa23bbf261e1427b5532adfeba387f89d35f66f776af44be7f183d06af0e55828" eth1_data: deposit_root: "0x44c70c125786b9ab6f938ecab3227d21da2ed26f1a1677f8f78e4058dc721403" deposit_count: "73" block_hash: "0x869606a66fc329f9076cc7257a61018e04b6a6c658298c65de81f67bf6990a4c" block_height: 74 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" - "0xa23bbf261e1427b5532adfeba387f89d35f66f776af44be7f183d06af0e55828" deposit_root: "0x44c70c125786b9ab6f938ecab3227d21da2ed26f1a1677f8f78e4058dc721403" deposit_count: 73 execution_block_hash: "0x869606a66fc329f9076cc7257a61018e04b6a6c658298c65de81f67bf6990a4c" execution_block_height: 74 - deposit_data: pubkey: "0x98f011f9a4dff94eb0352ff6e21b7df45e2a112bd5d789b5729111b89b368e7ed554e4d1c16b72f4d105090173cafed2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89641c38182c333a0485aeb0c4eb6f399a3581d19b33370522623d4c827de1cd5dc79c510a7e5bcd33f4d7a12bc6ef101630d2e4bfdf28c89b974c3927c314d118a345a3c424d0b3680c2de454e0e95f1d9c96565c2a7d771af7e8baddd25f02" deposit_data_root: "0x65569e8f6db92744dd0abfbbc30a083986f842aa23cc02408099f2b586a3ed1d" eth1_data: deposit_root: "0x727ba31c7148e93fea338887cb4cc053a8eaa60dbd3dfc15607e837a845b38e8" deposit_count: "74" block_hash: "0xa68c064f8ee59d1857ae8a3a8eea5b59bce083fcde164fed763ac2ab30e51f90" block_height: 75 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" - "0x8b4eb1bbcf79beaf6350d27870239dac66f0155fb7f8807a1f2b96afbba18f03" deposit_root: "0x727ba31c7148e93fea338887cb4cc053a8eaa60dbd3dfc15607e837a845b38e8" deposit_count: 74 execution_block_hash: "0xa68c064f8ee59d1857ae8a3a8eea5b59bce083fcde164fed763ac2ab30e51f90" execution_block_height: 75 - deposit_data: pubkey: "0xabef42538a17a55804b634aac9d211b92b5768c4cc1263342ca287323bb3d5c768080451d1b5d652e9f8646fbb35f57c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa7bc665e4424cf5e48e6b1dcc5f9d85e9f44ccb12690969a548fc0835b2fcdb6d587c997696e19fdc16ecb8c9b8a9d4810795c716232c2a2839845cabb70ff78aedab16d3ae55751c4b75a64dcbd5b630b652308300313457176c99889436d94" deposit_data_root: "0x2da83bfca1b961cbe477157ccb844db21392e1fb44822b1b330c686984e85586" eth1_data: deposit_root: "0xc7a1f21839a10b008b4503cfd0e8f57dc67b83642e8ed9aa1d9f042821f22b01" deposit_count: "75" block_hash: "0xf7b4c7f12fe8c83d3546300a2bbf4a01034fc10eaf79295db8dc9e1b36c9a20e" block_height: 76 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" - "0x8b4eb1bbcf79beaf6350d27870239dac66f0155fb7f8807a1f2b96afbba18f03" - "0x2da83bfca1b961cbe477157ccb844db21392e1fb44822b1b330c686984e85586" deposit_root: "0xc7a1f21839a10b008b4503cfd0e8f57dc67b83642e8ed9aa1d9f042821f22b01" deposit_count: 75 execution_block_hash: "0xf7b4c7f12fe8c83d3546300a2bbf4a01034fc10eaf79295db8dc9e1b36c9a20e" execution_block_height: 76 - deposit_data: pubkey: "0xa8e3c2d3ac4e0e3c83380577ff7b7b5b2a98571e0d04ddebc0a6c472ce3bc5cc6a6733be728a0ee17da74b7691d2679d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2719b1ed9259b55d519158388e8cfd749a186c6247c2a637848e133d761ad6b105e27d3f1a950455d8abaaccb756e6016c838c3ed0abbb9a0bc966ef6f58e681d232cedd792c2b19cb3d17a5240a16b97c62ce29682c078131b67143878d02f" deposit_data_root: "0xbd2182e7a29009df9034c125e8e09f7f6e3b862944aab607f84d64545ab002e4" eth1_data: deposit_root: "0xee5ee677dd7394ae7c9548383112262e9af48b1f84a109a1e42ca1a1fc57e527" deposit_count: "76" block_hash: "0xdd2ed41e4e3336c4afb390d9c8572db1a2d5d403b470eb88a3a85df3bbbd107f" block_height: 77 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" - "0xee021dc6246d96e341b4df28f5db26a62e2d9716eb92394f5bd7fa7e246fa85e" deposit_root: "0xee5ee677dd7394ae7c9548383112262e9af48b1f84a109a1e42ca1a1fc57e527" deposit_count: 76 execution_block_hash: "0xdd2ed41e4e3336c4afb390d9c8572db1a2d5d403b470eb88a3a85df3bbbd107f" execution_block_height: 77 - deposit_data: pubkey: "0x98f620aadc4e58392b5b583fed96c452b54c39ba3a9fe8c277f625fae7e1317d034f732995fd88c1461463edd0f2b86d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xabd8b07d34a93e4dc68fe6115af72218e56ad477e848d0d1036114aee03cba10ab561d1570bae237d94ff4d6aa029c760cf2ceda174bbce181ca2e9ede9b7f6a466d2e2d4a38b7367124bc70c887b69770938d3f82c7263b70d0ab960438afa8" deposit_data_root: "0xdaa5f5480bd46b815e89b67e6ccb84dab0b44ccdc687017785f0b26647eb2da9" eth1_data: deposit_root: "0x85ee92997d8c724afd6bfd6078f6b2fa8aacf96a8e98018ea21832f3b4df7d56" deposit_count: "77" block_hash: "0xf3f609e1b0e8c5ce0c404929cf2146d97e053f2a7c4dc186701fca3c81c79424" block_height: 78 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" - "0xee021dc6246d96e341b4df28f5db26a62e2d9716eb92394f5bd7fa7e246fa85e" - "0xdaa5f5480bd46b815e89b67e6ccb84dab0b44ccdc687017785f0b26647eb2da9" deposit_root: "0x85ee92997d8c724afd6bfd6078f6b2fa8aacf96a8e98018ea21832f3b4df7d56" deposit_count: 77 execution_block_hash: "0xf3f609e1b0e8c5ce0c404929cf2146d97e053f2a7c4dc186701fca3c81c79424" execution_block_height: 78 - deposit_data: pubkey: "0xa7f5d408af436d71ec7acfe9a4592679649d326c00ac92c6f3332423be30c3601d232f265078f1f2a5d6d6cde08de7d7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb3b301cd266d7dd40fed80f8f1609ca35256d263b00b16eed767dfe5ea8116eef1f6cb7f25028c98a9b28357b56ae1890b418858a4500034887ef60b7cf0f8b0f7a8718d450687316f7397632a3c167ecdb2db26694a8608ae06b0dc782e9c7b" deposit_data_root: "0x19f237b217967fe4d2ddbc826bf6e2c33687cea82a120e7b85e412d7e137d579" eth1_data: deposit_root: "0x5ad46efc2ae1bd120b59461c83d8799b741ad5000b754d6f9c20de9115890054" deposit_count: "78" block_hash: "0xbf4d50dea5661ab07e15967d8fa2c51cc55395749405ccb6a252ee68f8be1e01" block_height: 79 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" - "0xee021dc6246d96e341b4df28f5db26a62e2d9716eb92394f5bd7fa7e246fa85e" - "0x1d7bb861e983c4afb9abbd3c0f7546b0b8e381c2d7679f6993d4ef95f55f8127" deposit_root: "0x5ad46efc2ae1bd120b59461c83d8799b741ad5000b754d6f9c20de9115890054" deposit_count: 78 execution_block_hash: "0xbf4d50dea5661ab07e15967d8fa2c51cc55395749405ccb6a252ee68f8be1e01" execution_block_height: 79 - deposit_data: pubkey: "0xa8be337b3d0e6be415dcb037b246831f9966aacef62b69d6b609e4ff8208bc536c6473bc9fe9e3bec9a8665c8caa05c5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xac120d0e117e12d4af2ed041f4f7bac11ccafbdfdc4047808b83defc328196994afab43ec6581e6e88ce3eade65dab2a11618290151258cfb017fe15ea630f10d3c388c8b8e86a391a82f34c58974509e1b476876bba5b9d5f2c2a6b4682418d" deposit_data_root: "0xaf7bcef44525d9887a3a9982947bcf876e369190201ca2ea096bedf13edf353f" eth1_data: deposit_root: "0x8949d7d74a871960abf40a678878aa93c2d2a3e38bb9fcc9a055d19f434d9cbc" deposit_count: "79" block_hash: "0x881de104237f77e44ad277325f56e42735a577d9ea660124ecb08597585991ee" block_height: 80 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0xa1e9ca708d13a0c759703ba39fd1bcb39b5114273ca6dfff1e76d5c2c687b2c9" - "0xee021dc6246d96e341b4df28f5db26a62e2d9716eb92394f5bd7fa7e246fa85e" - "0x1d7bb861e983c4afb9abbd3c0f7546b0b8e381c2d7679f6993d4ef95f55f8127" - "0xaf7bcef44525d9887a3a9982947bcf876e369190201ca2ea096bedf13edf353f" deposit_root: "0x8949d7d74a871960abf40a678878aa93c2d2a3e38bb9fcc9a055d19f434d9cbc" deposit_count: 79 execution_block_hash: "0x881de104237f77e44ad277325f56e42735a577d9ea660124ecb08597585991ee" execution_block_height: 80 - deposit_data: pubkey: "0x93bb1c86717fa7303f65cb8c45c9fcc8fecb88428b7cd1dd59967a132109c25ab5c97888e46c5d471ff911c573f45a34" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb4ac35f3fb67d9a5ee84dbafbbe9fc2cc173b4198d3369a3ea40b745ff645c269ab3e8742b4033763d59aa88042ed040189f8093e55e38d0e202093c73bf469a35af5a340647247ce3377b213c6b2505bba028436173fd09ee845305a906af95" deposit_data_root: "0x65440def2a2b71e4e27356ec9dc2a661d5f937f8f0543a8e76c7a8dcb7d8e500" eth1_data: deposit_root: "0x2a8a1fb507e33b36be62ba505ce068295dbf1d40538474fb1446b02643b8dd4f" deposit_count: "80" block_hash: "0x53a3edf49a1a316d10285385209c510be04cde3a50f816beeb5da44196e426ac" block_height: 81 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" deposit_root: "0x2a8a1fb507e33b36be62ba505ce068295dbf1d40538474fb1446b02643b8dd4f" deposit_count: 80 execution_block_hash: "0x53a3edf49a1a316d10285385209c510be04cde3a50f816beeb5da44196e426ac" execution_block_height: 81 - deposit_data: pubkey: "0x815042c33c1a43c1ee58a58ee074bc93a13c23a035dedee6879730220379d0c03ff4a3829240b6c34e56feb55cd322df" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x951ce0fb4767567fdc4ac1c2b999d39624eb1915b3f74939685a99a30b99212f57eb17b163e3544d1524ada89d3d4fc9195163d5877a53b1d62fa210327eddb6b42150527df562ac5a67a0de3e59e3696a129c3c71c21240b584fe60cae66142" deposit_data_root: "0x6a9f3213a02e902c041ba8261f093e6c100dceca1ce46fc91420ca0c0a900f20" eth1_data: deposit_root: "0xcec66765569321e99f2a977b9ea2864097333eed6bc258e903142b60a8605ea8" deposit_count: "81" block_hash: "0x4a84e0118e1e4ec671bc23c123591f08b2ad83363a68941d1fcc2073a50d715f" block_height: 82 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0x6a9f3213a02e902c041ba8261f093e6c100dceca1ce46fc91420ca0c0a900f20" deposit_root: "0xcec66765569321e99f2a977b9ea2864097333eed6bc258e903142b60a8605ea8" deposit_count: 81 execution_block_hash: "0x4a84e0118e1e4ec671bc23c123591f08b2ad83363a68941d1fcc2073a50d715f" execution_block_height: 82 - deposit_data: pubkey: "0x8be11e9ead2e1bb5be7e2ec066ff83589558a5d9373666b3fc518a6a6639b3baecb87f8f34895f63e8d09d270d93ce04" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8a9863487be81d3b7a8fb0ce2d141843c43751e3f030529f2cd271968671da68c520bf86e8ad56786cf4df9023bd80380bbe0bf6eea87b99a2dc70d3de0d4bb1507fd4fb8f3aca17ac37b71bb11c0cb003cea26a38fd84a2da2e6a9922ef8472" deposit_data_root: "0x27dc8639ac98670dc00960901ffe78d2ac05ef71bebf1734b839f89f24137300" eth1_data: deposit_root: "0xf34475554a62ca5b35a9a0c54a8abab231ae1f7db3098144154435c6d5d51d23" deposit_count: "82" block_hash: "0xdc459617e7f73073e5134da264c9ddad3ea4fed09245b90f13ba139a899bbb85" block_height: 83 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe1af0aab0c08eb08233a563ec4bff65ad501d92c9a40ce2dc785d145c76117b2" deposit_root: "0xf34475554a62ca5b35a9a0c54a8abab231ae1f7db3098144154435c6d5d51d23" deposit_count: 82 execution_block_hash: "0xdc459617e7f73073e5134da264c9ddad3ea4fed09245b90f13ba139a899bbb85" execution_block_height: 83 - deposit_data: pubkey: "0x8bf2630491d2a480ec243b00d65d76e69615e67d3df5d8c14ca7506edd8e896a9083e8ee9e4129af0f6d896a3225c08c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa12d975029e83dba3b911bea41a5f1090fbd2129472a2244171f57ad1fe0f44043d36cd99501aade7f9ed8ce2b36b567025b63e075edf6ebfa4ea3b262ada83fa8872244bb5fcd4f61faf576bfd704bbbf7c1729610a10f1b316a2edcab8f2a1" deposit_data_root: "0x1657e7e852988d74eadcdd365213af142142f68dfb32ae071af7b9640a7b1724" eth1_data: deposit_root: "0xfcaec4c59f62d7cb9fdc1539228db986aaeaf6ce6182e9356d0d7ac9554cc5b7" deposit_count: "83" block_hash: "0x1b1fcd8f43efc0746a5c9a5e6069bcad198f4fb06ea4aa27fb2099886f74ea92" block_height: 84 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe1af0aab0c08eb08233a563ec4bff65ad501d92c9a40ce2dc785d145c76117b2" - "0x1657e7e852988d74eadcdd365213af142142f68dfb32ae071af7b9640a7b1724" deposit_root: "0xfcaec4c59f62d7cb9fdc1539228db986aaeaf6ce6182e9356d0d7ac9554cc5b7" deposit_count: 83 execution_block_hash: "0x1b1fcd8f43efc0746a5c9a5e6069bcad198f4fb06ea4aa27fb2099886f74ea92" execution_block_height: 84 - deposit_data: pubkey: "0x914b56f41c411fbfca9dc9763f44daf253c103b162457d07954fd0af768b5e74692b4639c22455fb81d71f7ed6144514" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xabbd26d91fb83232422509d6ca45b721185fa61fe610027a06c510dec708eea6cf54d1d955b676f5b77b141a6696f18d18b7336ede4da02504ca96e3363ce3c91698ffcf904c9f3c9d31648c79263acacb9747d7069d79016791b4facce83555" deposit_data_root: "0x4123a31554edb843e51c2c6d3d608693fda4d5def338ade6425f1790fb511774" eth1_data: deposit_root: "0x15754d151c1cae6449d10e2e95489aeab66d5defa0f19c29635f0319ff830a28" deposit_count: "84" block_hash: "0xa18fcf7a630b971e354e7c3661f21b45306ba7ff6d02a67a7a9fdce708a97805" block_height: 85 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0x78b501b3fa5475f83b94eafea06a4d859d98ca9dd9efb1f7c9f440868791c620" deposit_root: "0x15754d151c1cae6449d10e2e95489aeab66d5defa0f19c29635f0319ff830a28" deposit_count: 84 execution_block_hash: "0xa18fcf7a630b971e354e7c3661f21b45306ba7ff6d02a67a7a9fdce708a97805" execution_block_height: 85 - deposit_data: pubkey: "0x8794388915e86e4988363cdd4289ad19182209c873cbbbf5a80ff5c99f93acb839807787a77ad2b603f074405d7ed08b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x87e0e8c98f9e186d31d992634611b6d08376911636fd1d689b01330e70b4a9c819ddaef93128bb333bfdaf9e6e2697550897b9be994b5033b6397989e1db1b7db9d889083f4ad1c763192da282943f571d77781ef46364757151aeae27740ac8" deposit_data_root: "0x55aa7b5a4c6d119979913fa560116bd32289f6636e12f6056017cdef97b55682" eth1_data: deposit_root: "0xfa36dc4e7091338e1af1a655d7f73c8a4a31453769962a8335196409cdd05552" deposit_count: "85" block_hash: "0x6706a23dd2a500b2856ef97cdee6757a46ab118f06df889d50afc259c7938558" block_height: 86 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0x78b501b3fa5475f83b94eafea06a4d859d98ca9dd9efb1f7c9f440868791c620" - "0x55aa7b5a4c6d119979913fa560116bd32289f6636e12f6056017cdef97b55682" deposit_root: "0xfa36dc4e7091338e1af1a655d7f73c8a4a31453769962a8335196409cdd05552" deposit_count: 85 execution_block_hash: "0x6706a23dd2a500b2856ef97cdee6757a46ab118f06df889d50afc259c7938558" execution_block_height: 86 - deposit_data: pubkey: "0xa3862121db5914d7272b0b705e6e3c5336b79e316735661873566245207329c30f9a33d4fb5f5857fc6fd0a368186972" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x86fc69a33aaa4221dd112b9c1d69633430d803b55fd0e046d17e9ecc02a53d05429034baeb7d235bc76573449bdd7d0d05c80a3cb7e785f1a06b40cea3fbf66ceefc0a542983a92a609051580f48980a42f3cd43703b810f0f5ee8b5c2a5e556" deposit_data_root: "0xead7c5895bcb78cb6bf3b7dd8c3e984cd33de92cedafcbfb11821d725a1a7008" eth1_data: deposit_root: "0x55993260810877f669acb1d186a3b2e6715d9ff9d948cdc4da03a0515dd3fb03" deposit_count: "86" block_hash: "0xa2ec2792a7481050df8e4c66e3049fa01b122a59b4b0da16eefb2160122bd887" block_height: 87 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0x78b501b3fa5475f83b94eafea06a4d859d98ca9dd9efb1f7c9f440868791c620" - "0x05fdfe681bbf2653770a5add8d5a186497090b0852abfc6d2b5c7cd9c2cd48b4" deposit_root: "0x55993260810877f669acb1d186a3b2e6715d9ff9d948cdc4da03a0515dd3fb03" deposit_count: 86 execution_block_hash: "0xa2ec2792a7481050df8e4c66e3049fa01b122a59b4b0da16eefb2160122bd887" execution_block_height: 87 - deposit_data: pubkey: "0x96ef954b331a534199f4f113d993a50ec7a781fc5aa2a181ea0bdbfd4c5c557abfebfcc02604d5aef52ba64afbe0ff18" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb64dc6b6527edca3c16cf0dd04aeda244d69cb84a96e951ed1a7286c0a8ee24b56d4651e14e03d472ae3ed0cc9928dc40c5947e185e67716db8e8bd4c85bb5ee4bd14102347117b90276620bda17f0a68b6ff225842814a7e0f15e920350725a" deposit_data_root: "0xf962e2d35918b11c748e47d10d66e0e052bfb45965a88ca185044e820b33f0e4" eth1_data: deposit_root: "0x1e14f4e10d68971bf523b164e176f135b1304cfa07c88a57233d8b39a6c83456" deposit_count: "87" block_hash: "0x3a5d185a584fc74290efc7f9f7781c00d96708e925061731d5e083d44ee009f7" block_height: 88 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0x78b501b3fa5475f83b94eafea06a4d859d98ca9dd9efb1f7c9f440868791c620" - "0x05fdfe681bbf2653770a5add8d5a186497090b0852abfc6d2b5c7cd9c2cd48b4" - "0xf962e2d35918b11c748e47d10d66e0e052bfb45965a88ca185044e820b33f0e4" deposit_root: "0x1e14f4e10d68971bf523b164e176f135b1304cfa07c88a57233d8b39a6c83456" deposit_count: 87 execution_block_hash: "0x3a5d185a584fc74290efc7f9f7781c00d96708e925061731d5e083d44ee009f7" execution_block_height: 88 - deposit_data: pubkey: "0x96c8d3dd08724624017f178393d176b425dab9dfa1cc3f62c7669337446baa601e0aa261c00c76bde07ba9a1a3582c0a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb37b23e995a74a1c72a6e5d0dc75aa44d3e560c5c3aeaac78648ccdd38380e68b321cfc39555af65cdc2dbaadf3eace20011622070f90f2e782e5edff8330c8b3d8623fbf58fb878e0645f3588b3f75b293fc5f8051d7c324ccb9df12b48a07c" deposit_data_root: "0x0b8d152337bd30a81e3353cd2ef3767d4a3f6b84c124010ec8eb784591158e17" eth1_data: deposit_root: "0x4800ae85e0ddc8eb4927b7c3ac52f3718e7a47eee6b9490d4d974deff6b09f16" deposit_count: "88" block_hash: "0x6bf5193552720db315898ec262ab1cfd7590e13a88ae86efc702243acfc001b8" block_height: 89 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" deposit_root: "0x4800ae85e0ddc8eb4927b7c3ac52f3718e7a47eee6b9490d4d974deff6b09f16" deposit_count: 88 execution_block_hash: "0x6bf5193552720db315898ec262ab1cfd7590e13a88ae86efc702243acfc001b8" execution_block_height: 89 - deposit_data: pubkey: "0x92bd81b8e9099b9ca87a2033fdd84475752dc34a0fae0a8e50aabf4d3baff9cd45ed56508c837023944350f53dbc4ac7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x88835cc0416f137bf06133717762b9bda8e31f66b6910eb55a8eae0a4d97bb8d51284a8c4038da5e2b15b77e3beaee6b09d1561bb5bf1ff2cd2f7e6396cb80c520f161f43fb01dc259f5e2c2f33dc632ff1a6a14b46cade75b0850d3841e666c" deposit_data_root: "0xd3fbf626f2db8d53f0cfa2e8ab199e5633cbc1b1bc01dd5579000ae8b4c59525" eth1_data: deposit_root: "0xe83ff8243a690675111ffaa012be7ff8931efd74d0d29c99f7c543db94fb2e68" deposit_count: "89" block_hash: "0x1b93e72ce9ac8a2eaf1c6b6e8ceb0d413e084b62ab3b65a33414f794c6bca144" block_height: 90 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" - "0xd3fbf626f2db8d53f0cfa2e8ab199e5633cbc1b1bc01dd5579000ae8b4c59525" deposit_root: "0xe83ff8243a690675111ffaa012be7ff8931efd74d0d29c99f7c543db94fb2e68" deposit_count: 89 execution_block_hash: "0x1b93e72ce9ac8a2eaf1c6b6e8ceb0d413e084b62ab3b65a33414f794c6bca144" execution_block_height: 90 - deposit_data: pubkey: "0x83802cd575a3cea7e3e38fc1a73d94a9e4fdb999b8494e7929309c009d79a23edb1ba091ac02588f130e0585fb106540" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x90b696dc285957fee877e14c40dcd159622b4522ddb9e31d10f5d89d83af25c7a65de87deb816ec3fea86251c38247bd03e0e4e083e8ce7b63ed5917fd5b7a8bcea01ed61b3234b62eb0baeaf253cc04655cd5b64e7d642a3bc7be5e4a32634a" deposit_data_root: "0x58ea01dac688f2b29e401e7edb6319c7017d12c8adc57b372865b40d907be8d6" eth1_data: deposit_root: "0xd8b0fc873ba2d2d52ef3e7985d6ef0cc924ce56c852970823814b95892805127" deposit_count: "90" block_hash: "0x666278a6a24e797f1040470692822b240b2630b0af2a38c26da23f727af7780d" block_height: 91 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" - "0xe2fdce2d1fdc2fe192bb4aa9293cebebd50dc5e78e38a1bbc1b9b4fd39e22985" deposit_root: "0xd8b0fc873ba2d2d52ef3e7985d6ef0cc924ce56c852970823814b95892805127" deposit_count: 90 execution_block_hash: "0x666278a6a24e797f1040470692822b240b2630b0af2a38c26da23f727af7780d" execution_block_height: 91 - deposit_data: pubkey: "0xb451eb0ff4990917aba6e3d80c34aee91ea1ce49053f38ae174cef107cb9acc595d0ca3fefcb804c9dd04510c630cabe" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa5e3f58c8249a0d3c8269f16af4a8fb42b20b821c1554e51443c897ff00389cb8b85cd953236bc22430ddb49e3b1d8b018926d1e5b87a614e1b9257838cecf59eac47ecfb8648c930d839b8524ade0b68036e9e9987c554cfa24417a00ffc40" deposit_data_root: "0xf11f85f05b6d4b0d8ff3bfdc09e03ece905ba6452e2e45f20c78e62652a71f6e" eth1_data: deposit_root: "0xc1dc1c55036f14ded17a34c5d6c82a3df5c704a067ab5d0f9d50481679c9345b" deposit_count: "91" block_hash: "0xcf447d1821972d4a820ab84a95dafa442735e577290d6f110ee498567a0a1662" block_height: 92 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" - "0xe2fdce2d1fdc2fe192bb4aa9293cebebd50dc5e78e38a1bbc1b9b4fd39e22985" - "0xf11f85f05b6d4b0d8ff3bfdc09e03ece905ba6452e2e45f20c78e62652a71f6e" deposit_root: "0xc1dc1c55036f14ded17a34c5d6c82a3df5c704a067ab5d0f9d50481679c9345b" deposit_count: 91 execution_block_hash: "0xcf447d1821972d4a820ab84a95dafa442735e577290d6f110ee498567a0a1662" execution_block_height: 92 - deposit_data: pubkey: "0xa7f711233af57440e9ea700113fc4dbaef97e7da7741dd2e38ae668a7f2685d4585d54a9e6712ff1b87c69dbb181abf7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa2e034a05c1d3cac573a3cd1a4d76584fe1c12dc828aa85fe6b14958efb476d2e5afe6df9f7f7b8af02f19c0f74d93fc0e94911f2152659c11246ad51e5174d1fbcd9335c60fb3097c8168793238d0e0ff710b70f7bfe7f321131271bdff8dc7" deposit_data_root: "0x548e5a3a2012b86724762a43fc45047e7e8092914d1b2188a583ca9903f96ca0" eth1_data: deposit_root: "0x6d4e79bc326336e3a6c8e6c421a29d877c8daa3956aa1e55a63257ab6f5f43af" deposit_count: "92" block_hash: "0x631ee71ad7fec6f24ca2a56cd1c45f6c860b4ca487b28365f65860caed0614fd" block_height: 93 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" - "0xf5e222e2ec0403f08a8f04b439d8af9798f665fcc237f672d6e5e7484a024866" deposit_root: "0x6d4e79bc326336e3a6c8e6c421a29d877c8daa3956aa1e55a63257ab6f5f43af" deposit_count: 92 execution_block_hash: "0x631ee71ad7fec6f24ca2a56cd1c45f6c860b4ca487b28365f65860caed0614fd" execution_block_height: 93 - deposit_data: pubkey: "0xaca5e4979f281b5ab0ea0f549d6dcc34989607c335e94efedeffc7e73b393f42c7b11d76144a750f82600b21d10b6777" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x90374711b91d6b7385cf3f099f5ed3a93d79383968645d9bdbb191bc461b3559df4a7bef411c33a692590ffa1aaaa91f1870a5c0d20df79f2cfaf2d5482f49f380679168f47affe35a4fac018692f5f0f007031bb3d8fef31e23a922a444d8b5" deposit_data_root: "0xfd4f2e7d7c027a545467d3a3295b2ab5ccfebc669330a533243db77cd3e8cf4c" eth1_data: deposit_root: "0xdda9d42bf636ae45f5c4376a0cb0b56e15846bc9119dffda44e196de5ba747e4" deposit_count: "93" block_hash: "0xcb69ea6fddd200d561ac5e304e8b08abc9b6ec65c3f0e4cccdda7f523facdd6f" block_height: 94 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" - "0xf5e222e2ec0403f08a8f04b439d8af9798f665fcc237f672d6e5e7484a024866" - "0xfd4f2e7d7c027a545467d3a3295b2ab5ccfebc669330a533243db77cd3e8cf4c" deposit_root: "0xdda9d42bf636ae45f5c4376a0cb0b56e15846bc9119dffda44e196de5ba747e4" deposit_count: 93 execution_block_hash: "0xcb69ea6fddd200d561ac5e304e8b08abc9b6ec65c3f0e4cccdda7f523facdd6f" execution_block_height: 94 - deposit_data: pubkey: "0x984620db3658a19769475080998db9e7f5bcd4255a89a70b5ecf7db01226f213836d091a3b37eb96e4937966b094a291" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96f074fc891b637e18eb0b3c5908f94d4e71f76243914e3b3a88348b7a7ec85289d322e24f14ce75a7d193dece4c7cb5150aca3dae194839807c09039304a894c9e5b70735b88c437f9c6043e495201f58a28683d2eb528e3e81fe14b3ce867c" deposit_data_root: "0xeaad4c2435c42339d3f2248def6f6d44a0da2237d6eb6092016e5b9a47b3fa9f" eth1_data: deposit_root: "0x026d58bd6b7169617f62fc8725cebcafd8b3f352d63060d3b3326ff6e9d2d3da" deposit_count: "94" block_hash: "0x562a78b2c5ec97a0b4fa413f57885311a457155372bbf630a434d8c243d21036" block_height: 95 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" - "0xf5e222e2ec0403f08a8f04b439d8af9798f665fcc237f672d6e5e7484a024866" - "0x621b699cf7502853da163711315ae56eac3eca5afb2c480325bb9a35e3c9f37f" deposit_root: "0x026d58bd6b7169617f62fc8725cebcafd8b3f352d63060d3b3326ff6e9d2d3da" deposit_count: 94 execution_block_hash: "0x562a78b2c5ec97a0b4fa413f57885311a457155372bbf630a434d8c243d21036" execution_block_height: 95 - deposit_data: pubkey: "0x8f1ef3639aea57fef705847e251b785bb608a848f42d9107c494cbc696be35642f6552fb83174ca2e73632568a5667f4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa733bafcafc2ba319538ce6af3de20976c5ebd8040a8a3628f7e69a16baeb95566b0cefc55472fba696aa023001b52f605d8824f7dbf2dba9ff2a53554c155815da39e3f27ebd7022a52412b9a793468cb1a1c6469aae7750a1d36a0010fc8b8" deposit_data_root: "0x93614f1ff88e971226eb167a407e0afe4d236a82e2eaf43259946edbc8af576d" eth1_data: deposit_root: "0x511e1b6a894a5783751f3eac7f79d3f52c94a76f29686ebe7eaac7a854d490d1" deposit_count: "95" block_hash: "0x723848008dec04dc63b5a521c38e95c5f2598053fb5a756022d3a85906128eee" block_height: 96 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x9cdee5c9ecd1ef9a54feb904550ef7271277dcbc43318688b0b0f4b0454c5a95" - "0xe78ee87ce4f2c19b2b27b0e4d875fb21bf9580e9b8e683f34db124274f263dc5" - "0xf5e222e2ec0403f08a8f04b439d8af9798f665fcc237f672d6e5e7484a024866" - "0x621b699cf7502853da163711315ae56eac3eca5afb2c480325bb9a35e3c9f37f" - "0x93614f1ff88e971226eb167a407e0afe4d236a82e2eaf43259946edbc8af576d" deposit_root: "0x511e1b6a894a5783751f3eac7f79d3f52c94a76f29686ebe7eaac7a854d490d1" deposit_count: 95 execution_block_hash: "0x723848008dec04dc63b5a521c38e95c5f2598053fb5a756022d3a85906128eee" execution_block_height: 96 - deposit_data: pubkey: "0x8967da3c8071ba2bf632cd40ae08fbbf0a203c47c02af1948fc232a7a743c0c0cfbe51606b89f102f2f6de7f039fb155" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x913fdc3ce1efa57fc787572b38a1682a411548e5707daf8e7b9e6a6126ab172c33226e21dff8bbd48b2a8d22f1a8b0e51540166b4c6f8cdf978f69a04a3ec48ebbf64d9640e20b834b56362b0bab8ad1793f72bce5d6afe74588a6f6efdd7267" deposit_data_root: "0x6b4666b947e91abcf56197ff3e4c918aee6289bb0dade7a5788d7032ac026acc" eth1_data: deposit_root: "0x083b92e2d2cee3120c5fdc9d2ab492d7563bec65eb27aa5013465136f7eebe41" deposit_count: "96" block_hash: "0xc566f29d941053e9c2881d01fc9b1314c714fdc6d6ef63d842e557e6a347884b" block_height: 97 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" deposit_root: "0x083b92e2d2cee3120c5fdc9d2ab492d7563bec65eb27aa5013465136f7eebe41" deposit_count: 96 execution_block_hash: "0xc566f29d941053e9c2881d01fc9b1314c714fdc6d6ef63d842e557e6a347884b" execution_block_height: 97 - deposit_data: pubkey: "0x8d58f7e2e58471b46d20a66a61f4cde3c78ab6c0505517c615e08d8ef5adf59b65fa2b01ea2395c84584a6f10d6cee2f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x892b60039b6e05f3f82b460d9360e1f1121adc5974a7c75f8cb723d597f764fb26aaf21bbd6a08b36078d6acc00a355607888b4838f9a1d007a4d0d0db5650e36ca498d6d074bf14a0a33ef13c34a419d7f99c6ebe0eca5001263cbb26f299b4" deposit_data_root: "0x34e3e3e0c13a79cd9e7e8826d9d20c106a9401f253750a68869eb8d31fd8d03a" eth1_data: deposit_root: "0xc33b108e1f20262d0bd6dde0604c39e305ecf07eb8c390070cf586395b6050ff" deposit_count: "97" block_hash: "0x01a6a54f02fad6d7168ef158896c42874a9696b7d6b33b6a90fba4e9892723a2" block_height: 98 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x34e3e3e0c13a79cd9e7e8826d9d20c106a9401f253750a68869eb8d31fd8d03a" deposit_root: "0xc33b108e1f20262d0bd6dde0604c39e305ecf07eb8c390070cf586395b6050ff" deposit_count: 97 execution_block_hash: "0x01a6a54f02fad6d7168ef158896c42874a9696b7d6b33b6a90fba4e9892723a2" execution_block_height: 98 - deposit_data: pubkey: "0x8db9f236d3483af79703244c7034b5267a0546c3c840d4e91fdcdd466373d62d960553982225ca5f7666dd7375a29c19" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9395087be80e3bc55d623f4d5bdfe6de200064e27d862d731c0c3dcf60a7c73fc6ad5c59177f788b5ce4ad6c2053fcea0950ec9196c8deae651f8cf3042a87b234bb4f201fe0d852708c332d0efe4323a7f6b3782ee919b365479cb5aa90bcc3" deposit_data_root: "0x57a75df5bd0f09fbaa3bbd2ad872fd0704d94d51ddcefad7ad9af438b9d63ce2" eth1_data: deposit_root: "0x99b08e97b9635d5ce40146efae53e688f53a8910a0357fe211440987b63f86c9" deposit_count: "98" block_hash: "0xff6e581a1f58dd834e095b5dc6cd14940a0b5148a7d0b6d94944ee324750abeb" block_height: 99 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x9c30281da5fd2d7a8bd8e4c8c3a19ee28bb8a08c97e386825abf49429dfc8492" deposit_root: "0x99b08e97b9635d5ce40146efae53e688f53a8910a0357fe211440987b63f86c9" deposit_count: 98 execution_block_hash: "0xff6e581a1f58dd834e095b5dc6cd14940a0b5148a7d0b6d94944ee324750abeb" execution_block_height: 99 - deposit_data: pubkey: "0xb7721412ae5a793f34ac8866698b221c67ef8272eba44d3030512ec3f7ed8ffcb620b58f17809690d5276423e849827f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8967a6b4490020cee91b6554b3aadb730da19f1dc9ab10629014f1b6221bb3f5827dafab1c48d97a5e0f55577708dad613724b60700424854c38a14aae340d8fd20ed7145e95dc458cc3d298192aad68c112bccd7f5574594a6d5a5b5401bd63" deposit_data_root: "0xc14a33eb96c6282e934f2944a23bafc7813ab96c21dee6ec6b2ad8c4c10ec4e4" eth1_data: deposit_root: "0xcaa6c2f895d078431ed03bc0d16ff9cae6eab44c2675a42de52820216f647f0e" deposit_count: "99" block_hash: "0xaf681b414bf20e9775a4c897373013a58d6db4e23c2a394b25cd9dab40ca6c53" block_height: 100 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x9c30281da5fd2d7a8bd8e4c8c3a19ee28bb8a08c97e386825abf49429dfc8492" - "0xc14a33eb96c6282e934f2944a23bafc7813ab96c21dee6ec6b2ad8c4c10ec4e4" deposit_root: "0xcaa6c2f895d078431ed03bc0d16ff9cae6eab44c2675a42de52820216f647f0e" deposit_count: 99 execution_block_hash: "0xaf681b414bf20e9775a4c897373013a58d6db4e23c2a394b25cd9dab40ca6c53" execution_block_height: 100 - deposit_data: pubkey: "0x99f6e5b80dc52407f0436d3474bd5da5ff23a19cb188b933af6312d9793cbfd54f9e72596c5d481a1ed8d705b81c1f0e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa0de9fe9ab9d8fa0b287ca0c7335bca94a79a888e67a7e0a933d38b5dfca2cb30d77f75398652a3c787af48b0707ebb20d3fd2e3f78c459235bd0eb17f550964e6d2638470728499f59cca4c041846d433e9095b5d2cc83c633cc728f3683db8" deposit_data_root: "0xc6f502475ac7546b770905653f9c9da144d8721ebf626232259099df44d67793" eth1_data: deposit_root: "0xe346f5cfac0d8834bbdf80742e9de3418f612bc03fa79a9be61a9a201070673e" deposit_count: "100" block_hash: "0x40078f8026a5491a9530ebc2bdc366535d4c6a7c37c1df6515c4074508849187" block_height: 101 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x2c03f5ec194e16617790b85ceb15755990f694b3fb90b74d26812f265b90d33d" deposit_root: "0xe346f5cfac0d8834bbdf80742e9de3418f612bc03fa79a9be61a9a201070673e" deposit_count: 100 execution_block_hash: "0x40078f8026a5491a9530ebc2bdc366535d4c6a7c37c1df6515c4074508849187" execution_block_height: 101 - deposit_data: pubkey: "0x8931cd39ec3133b6ec91f26eec4de555cd7966086b1993dfe69c2b16e80adc62ce82d353b3356d8cc249e4e2d4254122" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa1e9f2cddc66b67063b4caecedc4093ecb9241a751da05b6219b5062a5311590d0b4f8b258377a6696316d7808e10c6502542f3a14c00693a70ea8adf2bb74b79d0a15613058c521b50882007b85a0ca26b0bf888695d0a03dcdf0139364c849" deposit_data_root: "0x61a0ce23d0255c07b5f1f85771735ffc18dd898b056d00d5e72431c9ab4526c8" eth1_data: deposit_root: "0xd5db7d15947a7d071f2809c8e827e9ca01511010e1af5e50e59ed2eae150fab5" deposit_count: "101" block_hash: "0xbfa88dac097016410b459589b3d5703070fb2da3419661138f0e3e9bc868e49b" block_height: 102 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x2c03f5ec194e16617790b85ceb15755990f694b3fb90b74d26812f265b90d33d" - "0x61a0ce23d0255c07b5f1f85771735ffc18dd898b056d00d5e72431c9ab4526c8" deposit_root: "0xd5db7d15947a7d071f2809c8e827e9ca01511010e1af5e50e59ed2eae150fab5" deposit_count: 101 execution_block_hash: "0xbfa88dac097016410b459589b3d5703070fb2da3419661138f0e3e9bc868e49b" execution_block_height: 102 - deposit_data: pubkey: "0xad01d0f23cb74fcc4c39a2d0827d22f4722f02076196350dff5dcc6be765009c66e29001001959d77b277c2f0fba0425" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb3ffc0107b268976d973c779f1682eb3b92fa5988a72a169d6b959472a72b9ea48c30132bbfac1dbde2a1b658007025011969607d97747e6bca0a852a0c0a03d0fdee3550f22f4052fae270a373b92d40f14c86ff0f79d7570335e16269b034a" deposit_data_root: "0x7fbb1660d3859504d5652fb48a640e3a0852b9087209abc9e9a641a3b0bc526c" eth1_data: deposit_root: "0x2a0a58d87c8644cff8c8b70ca8c8e698376bed37ba7f9b4ed5f5e9058b3e4017" deposit_count: "102" block_hash: "0x2617746c889290b55facaa523ef25b1bf1bfad0be77797ffa78bf2fd44217fad" block_height: 103 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x2c03f5ec194e16617790b85ceb15755990f694b3fb90b74d26812f265b90d33d" - "0xde2e3c85af638e1c1b8581fd99aafbb0b9e0e2d638a96c2037814fba4940ddad" deposit_root: "0x2a0a58d87c8644cff8c8b70ca8c8e698376bed37ba7f9b4ed5f5e9058b3e4017" deposit_count: 102 execution_block_hash: "0x2617746c889290b55facaa523ef25b1bf1bfad0be77797ffa78bf2fd44217fad" execution_block_height: 103 - deposit_data: pubkey: "0xb300303a03b8eff26a25449169d1946b208d5240f011ca6f5db23cd7f2c004b63f60afe3c9e047b67f9e4c8970c71cf0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x88d4150448307f43753ee083124754d8c18b2c4eadb170e741e828b61b356b8cf3c69caadbdcae96f3353ba068f2c2da00596d5ba1f5dae9ec4c305ee7c5069ba5c71ea6ac5cde50bdee887233c18a85928a066802d5b4b38f3295c706860d93" deposit_data_root: "0xaccb652fae17e3c73511c9d3065377183aa4cc46b7f0f57b0e7d821b2b2ce99d" eth1_data: deposit_root: "0x7154ee203a0ef6d25aba1c8473290a20ff6db1147cf850f848d8641e25d872ac" deposit_count: "103" block_hash: "0xb082be3f6319b71f9235dd3320af6ac53a7211bd652c673eecd70fa2443d9b76" block_height: 104 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x2c03f5ec194e16617790b85ceb15755990f694b3fb90b74d26812f265b90d33d" - "0xde2e3c85af638e1c1b8581fd99aafbb0b9e0e2d638a96c2037814fba4940ddad" - "0xaccb652fae17e3c73511c9d3065377183aa4cc46b7f0f57b0e7d821b2b2ce99d" deposit_root: "0x7154ee203a0ef6d25aba1c8473290a20ff6db1147cf850f848d8641e25d872ac" deposit_count: 103 execution_block_hash: "0xb082be3f6319b71f9235dd3320af6ac53a7211bd652c673eecd70fa2443d9b76" execution_block_height: 104 - deposit_data: pubkey: "0xaca096c7f41cfa6b9317dff26c6c96878c9e5d5eed50afde44d8df206372ad4b4c45568f6671552029f4c3509e295bef" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa200bef0c9ca2a3efafb7d75dd19be1f621a50b1f5d3eaa688a6d02119a1c08125c4d9dd71cc388e2dfac5544d466bf618293c90e396b56e0d7ab9714a386e0f9685cd4aa07de369cee98ef3912281f438c7ae29146a199c94d2542889d9f898" deposit_data_root: "0x70ee28dadd98103e531ac6f411f1798bec743246fe66be847efe6fc26bf530bf" eth1_data: deposit_root: "0x548bfd5b5eced68eb9fdbabb484a6145d518a234cd7626ab7bcde2752dc878eb" deposit_count: "104" block_hash: "0x1cf1756c5ffc73b0f80fc2a242fedcdeed357eff548826f5b81a765f69f98a9b" block_height: 105 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" deposit_root: "0x548bfd5b5eced68eb9fdbabb484a6145d518a234cd7626ab7bcde2752dc878eb" deposit_count: 104 execution_block_hash: "0x1cf1756c5ffc73b0f80fc2a242fedcdeed357eff548826f5b81a765f69f98a9b" execution_block_height: 105 - deposit_data: pubkey: "0x87bbd5574c17dbf80463d11f812a77306f67913c510b1b234f5bd80478c7da8e69476cd6711cd1f4c0e228a4e2e99636" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x982d4f21d196dd1c646180e68e831f730e596980de02297deb7a91a2d1b5fdf82fe7bd7dd9e2d301ef25481814e763b505f8183b996e08e363c27fc6e6d08538ee37898ac5ea10f9ab9b6f70265ad3b214613e643c9c047333bbaf95053eb3f6" deposit_data_root: "0x16c89707a34efa444cf234654f40c446d1dc61cd8f9868668df3b1ab87eaea8e" eth1_data: deposit_root: "0xef70ec141be46e60cb179e2b7dfa8f061a0ed3cdf8b1f8b67e0f410f3a6af678" deposit_count: "105" block_hash: "0xda9c4714b0ab8c1befb967e12d9f677e7c536aca4750647e6302a6c5687460f2" block_height: 106 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" - "0x16c89707a34efa444cf234654f40c446d1dc61cd8f9868668df3b1ab87eaea8e" deposit_root: "0xef70ec141be46e60cb179e2b7dfa8f061a0ed3cdf8b1f8b67e0f410f3a6af678" deposit_count: 105 execution_block_hash: "0xda9c4714b0ab8c1befb967e12d9f677e7c536aca4750647e6302a6c5687460f2" execution_block_height: 106 - deposit_data: pubkey: "0x89a80c9263a21ebb9b7b99e59e53edc9ac766a55da86a52d1098d57572999ebad7cb92800b1f15be8d7c43889ab71c5d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb6ca12b56b3beb9f9c785f8f865ae5d33ae5d432c34b580907c56ea252be219553c87e3a6d2eb3d93bf29b16c0c522b303c289933ace190bcc666cf3cbcc22f5f516d2ecad7bf29ceef55f8911b33a9c9f7bdde58876e6c02522925d0de0e444" deposit_data_root: "0xe9b136c1ca2fcb6d303f551b646a882b36d377989a217239b68534d1afc9fca0" eth1_data: deposit_root: "0xaeae251b14d94efe7aa55639a1387528a1e5ef2769b05e8286a661d147e06cb3" deposit_count: "106" block_hash: "0x5669324d92acbdd26d268054be610287bae0b19c33fc941fd3096db48833448d" block_height: 107 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" - "0xa2000cb687523633d740002d63b1deb735701652a6d1053a8e859b2a2b17ca0b" deposit_root: "0xaeae251b14d94efe7aa55639a1387528a1e5ef2769b05e8286a661d147e06cb3" deposit_count: 106 execution_block_hash: "0x5669324d92acbdd26d268054be610287bae0b19c33fc941fd3096db48833448d" execution_block_height: 107 - deposit_data: pubkey: "0x802408c2a1901d316637a3ec6d20447bb9ee105c8c088510bfbcf8cda3ffa9376779f36e12e960e7efa5f2aba45e6483" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x91efe4ad425f9226a32e6c2bb04e47bd7adb4ebbbfcb20bf4119e046f22aa714264dcfaa8a1744d02d959e6719fbb245013230f209524365c2b2f418abb365a439883f89abce8896f4463dee7e9b08629b06bf1a1e8704cee65bad429c0a5757" deposit_data_root: "0x43e5a791b6ea536132e9b7c2e9e154eb7228704fb1749d76474dccf2cffb2c2e" eth1_data: deposit_root: "0x97284fc411333bd602aef2ebd5cf41ced3b2d7b27ae5de0d97a0b23f1a352ee6" deposit_count: "107" block_hash: "0xb1f82e537255e3d8c6607a9e5acf26cab9c71cc10145c2295012c650f67a3476" block_height: 108 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" - "0xa2000cb687523633d740002d63b1deb735701652a6d1053a8e859b2a2b17ca0b" - "0x43e5a791b6ea536132e9b7c2e9e154eb7228704fb1749d76474dccf2cffb2c2e" deposit_root: "0x97284fc411333bd602aef2ebd5cf41ced3b2d7b27ae5de0d97a0b23f1a352ee6" deposit_count: 107 execution_block_hash: "0xb1f82e537255e3d8c6607a9e5acf26cab9c71cc10145c2295012c650f67a3476" execution_block_height: 108 - deposit_data: pubkey: "0xaccc213c82702adfd5c32b24a68863f16ab6ab46947d1d7b3829bc62cd5f2a87bcd0d3ef27d442f07ad4363be9fc12f8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa2e689452fd1534510fd42ff1e2dab4addf50492d66518836649ddf9ca206953fbd0ada1f727d14fb05e2041e3d786e308f06f5cb5f610fb8c8bea08730f4f35cf4ce8e12dbfe2d86f5be234b765373fccf1d2e167d2e14051aabf6c563822d5" deposit_data_root: "0x834c7ef796fc324ee3d09a5c35fdc887d317b6e6fb166403b37f9672736f83c8" eth1_data: deposit_root: "0x0d890ddd7f83f43cdc1bd1888b4b514892240f854310148d31fd0cd36e577d0e" deposit_count: "108" block_hash: "0x3859945b847ee6c8bda15345167cd845984f63fa80b59abd02e47f305ab1859b" block_height: 109 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" - "0x3f0c046faed71f3fab856fcaf43a55a7865e4f8054998ea1b7b0ac4b2ec62d03" deposit_root: "0x0d890ddd7f83f43cdc1bd1888b4b514892240f854310148d31fd0cd36e577d0e" deposit_count: 108 execution_block_hash: "0x3859945b847ee6c8bda15345167cd845984f63fa80b59abd02e47f305ab1859b" execution_block_height: 109 - deposit_data: pubkey: "0xb0af0bfa83f0922e6cbfd2bc8ec19ff0f692fcb87c4e35f30e1353b342ae2fdaea6056bc2759970fc2a1f561826f564e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xac48afbc00ea959cf42b12f84d934ebaa6411c2ef6543b9551795d44b9c0ad242892330217978991c010250104e9b3d702107985f4f3f470ea555d9995fdf2c53549f3f4577e1893cccce684b9f13961730dccab982e8ffc56013ddec229e145" deposit_data_root: "0xa366a29df760de23293716136774c56eb8d31fc5c2ab2ad91235305fffff9ab2" eth1_data: deposit_root: "0x4c52ffd886c8668450508977adb286c525f48706688f364dcd0a7197b08b6dc0" deposit_count: "109" block_hash: "0xd5bebc34ca9da5a4ee194fec1c3efdf56a070520be6dbfd87f08862e7909ad5e" block_height: 110 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" - "0x3f0c046faed71f3fab856fcaf43a55a7865e4f8054998ea1b7b0ac4b2ec62d03" - "0xa366a29df760de23293716136774c56eb8d31fc5c2ab2ad91235305fffff9ab2" deposit_root: "0x4c52ffd886c8668450508977adb286c525f48706688f364dcd0a7197b08b6dc0" deposit_count: 109 execution_block_hash: "0xd5bebc34ca9da5a4ee194fec1c3efdf56a070520be6dbfd87f08862e7909ad5e" execution_block_height: 110 - deposit_data: pubkey: "0xa626de0451397075bf145e720691c9d5ed92eddf1f4e48155b455aac7a8e920d042f5635c7a74fe3a9175ffbfb7ce12e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb34e59e6935eafbe65e52e28c5f311f381b303f479ec2a6e9fba488e514de0eb6e1079f033cc8dcdd839675a6ef00869132aaa13dae6179fa88d01620af6cdf890258219b7bd4e374f82712cab8aec4de54ea403f2807c20ff8587ba9740de6c" deposit_data_root: "0x225e8673c5a0ede3e15885c408c04c2468c223f1fff0a87b08cc74887dd3a56f" eth1_data: deposit_root: "0x7c63909e1401449ed1e5773863d7629fbc8396468b85476a75d7e637b5f9f7a0" deposit_count: "110" block_hash: "0xfdee2ad0a738d5c9a2f063b80fce04b5e61df04fd595155dc5509d45ee6495b5" block_height: 111 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" - "0x3f0c046faed71f3fab856fcaf43a55a7865e4f8054998ea1b7b0ac4b2ec62d03" - "0xac07404027d09239f2784ec2873ccb9baf4212a432cce6626f56e80f1e99ea5f" deposit_root: "0x7c63909e1401449ed1e5773863d7629fbc8396468b85476a75d7e637b5f9f7a0" deposit_count: 110 execution_block_hash: "0xfdee2ad0a738d5c9a2f063b80fce04b5e61df04fd595155dc5509d45ee6495b5" execution_block_height: 111 - deposit_data: pubkey: "0xb0933ec64b73c49071fb92028a8e3d1ad18019e177370d335fa03c61de5d01e1a7e154812f720c44109701e2b07068b0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4070a873b52b119a63ecfd68300d7f2f359963cdcdb4b7e6764647975b2fcf6ac0682c37690493d3078794ee680c0490381f85b20b8c0ff33f9642dad0064e0ab84eced4a8e38bacdcc4a068a7c5742d67e64b9019bbaf2f2a64a7e525b2198" deposit_data_root: "0x5242358df16ac3f92030b1fbbdb91f85d477b50d2d33a2f59dcf4bce046ee698" eth1_data: deposit_root: "0xa277f7cb6c03e9087666ea431b99d82c13b4d5ee95ccd73b1b627bacb236486a" deposit_count: "111" block_hash: "0xe89d23f1eaca58026acc006eff84e317245838800cd5c1be08a8564284c75a6f" block_height: 112 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x6cd8d51fa9ddfe114bb7f25d29576b6a72602063f2c1a541ac3e767dc0bd28f4" - "0x3f0c046faed71f3fab856fcaf43a55a7865e4f8054998ea1b7b0ac4b2ec62d03" - "0xac07404027d09239f2784ec2873ccb9baf4212a432cce6626f56e80f1e99ea5f" - "0x5242358df16ac3f92030b1fbbdb91f85d477b50d2d33a2f59dcf4bce046ee698" deposit_root: "0xa277f7cb6c03e9087666ea431b99d82c13b4d5ee95ccd73b1b627bacb236486a" deposit_count: 111 execution_block_hash: "0xe89d23f1eaca58026acc006eff84e317245838800cd5c1be08a8564284c75a6f" execution_block_height: 112 - deposit_data: pubkey: "0x8b47707a1f563d3b1034e20be2a663587f17fece6581fca156cf660575fde4b8de4d45f1fda7ade9167b953d4c93417d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x94c71b0489c2e7cc1041a4971b92bf507c78b868d58de47fa10f673952fffa15edbf42cff7dc09f55ded92069023ed31049a7b917ac3629560e1a1ab6dd936a8e846a36cc5a691cb0cdcc1ac61a47565778aa9c8ddecb41e2cacca4fa7a9a093" deposit_data_root: "0xecb5c27e0bd4dfba545e4be285416d20eea78a0c894c97542ead3e70cf3a0788" eth1_data: deposit_root: "0x98e76adf146e3608cd2e4f340d4d646e8f43a211e2326a454a86e2a2ffa8442f" deposit_count: "112" block_hash: "0x6803694b96704cf8b5a7b731ab9497fc091064132096166e8852ad5de1d23aa3" block_height: 113 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" deposit_root: "0x98e76adf146e3608cd2e4f340d4d646e8f43a211e2326a454a86e2a2ffa8442f" deposit_count: 112 execution_block_hash: "0x6803694b96704cf8b5a7b731ab9497fc091064132096166e8852ad5de1d23aa3" execution_block_height: 113 - deposit_data: pubkey: "0x8ce551755078927147bae52f683f962ca09cd68e2a14dc7444f98739fe5d27e3596314d78deedc87beb705bcf9532182" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa68afbb096250d43a72588cf6db83f6be6413f0d7350056cba7d11df6fc7efa07107dd925130c0d1ab55b510e5e39b29151649e8f371e113a83c7e2518c4a0d6d16b17c7209396a5bd9653f78f357528e277071f03bb9abfdb10580e919b84a8" deposit_data_root: "0x54af1e6596ebc505cb6c1eb2c2a58d137f0ab4ff9e8919495631a9c6ce02e185" eth1_data: deposit_root: "0x28d6d95d118088e83779c9030adbbd5faebcd35e8168a1d8c3f675a80ae7aa83" deposit_count: "113" block_hash: "0xaaf1b5f2693fb64143ababcc4d377385cc37a7f6a87c989b5c21ee9dd1578fbf" block_height: 114 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x54af1e6596ebc505cb6c1eb2c2a58d137f0ab4ff9e8919495631a9c6ce02e185" deposit_root: "0x28d6d95d118088e83779c9030adbbd5faebcd35e8168a1d8c3f675a80ae7aa83" deposit_count: 113 execution_block_hash: "0xaaf1b5f2693fb64143ababcc4d377385cc37a7f6a87c989b5c21ee9dd1578fbf" execution_block_height: 114 - deposit_data: pubkey: "0xb363a57c600a0037d54d738037358aa686e27da3ea65be95f95fc04d5736fba6338c5d544c3cf2b11262bd20e7a42dd1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8fb0e367ac8eeceeccc271b8abb3f6a51ac714bc0837d919ee3cd56df40f2b3020fa79592035cd9b4b59e428620b1fc0ef0b62804119288362814074b2247be97106821cbe2e5ee077d4935a853c17730701c0b9eafc83ff08656b8ec2fa7a2" deposit_data_root: "0xd6fdfa51b7eb29f6327bd5f283e43b584dde088d09df4378e58b244b871c4dbe" eth1_data: deposit_root: "0x4f43eee61db70c0290a3ec3eeed96b98d38fa1fddb21149808760133b9f7a385" deposit_count: "114" block_hash: "0x9184c85f99de9e7302c25f18b814f557e5ed7363677ce9fa97dd727f1c9c01b6" block_height: 115 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0xc2d2d3ec8e50223aa7c20032356d3d4a3be3ecfd18471318d91192e20bca4cd9" deposit_root: "0x4f43eee61db70c0290a3ec3eeed96b98d38fa1fddb21149808760133b9f7a385" deposit_count: 114 execution_block_hash: "0x9184c85f99de9e7302c25f18b814f557e5ed7363677ce9fa97dd727f1c9c01b6" execution_block_height: 115 - deposit_data: pubkey: "0xa5e05143d5034740cb9ad524bec81678b07223989d4534ad44ffad33ee2fc73e4ee6b297b68aef9de33f98e5487467b5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa44866b3ac0b41fb89fd7a51f4963bceab4b31e92f963aea80979a8a96835067eac75868f59c7ad204f00e117bb3cded053e6d2334e626634d0cee0120234658f7cc1e0c68f0c7d1f23327db2bf91d86b56ce7131012b0db84266bf624f0b599" deposit_data_root: "0x72a8893e5155db8e97031c2de604a4ea3b0d3323a6a242a4253c7a539dc72ddf" eth1_data: deposit_root: "0xa9ddf7428ca9cb8ffa10cf3f1ac2e56066e9f962e8cef91aedd841f0c0b3a6c5" deposit_count: "115" block_hash: "0x0343f11c8b2cb94cf8cce1b1f0e6dafcc956a4d6ba21a0010ae204a4e50d8171" block_height: 116 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0xc2d2d3ec8e50223aa7c20032356d3d4a3be3ecfd18471318d91192e20bca4cd9" - "0x72a8893e5155db8e97031c2de604a4ea3b0d3323a6a242a4253c7a539dc72ddf" deposit_root: "0xa9ddf7428ca9cb8ffa10cf3f1ac2e56066e9f962e8cef91aedd841f0c0b3a6c5" deposit_count: 115 execution_block_hash: "0x0343f11c8b2cb94cf8cce1b1f0e6dafcc956a4d6ba21a0010ae204a4e50d8171" execution_block_height: 116 - deposit_data: pubkey: "0xaf14e8626e043caed52d9dfe62046eaa698f8b95d25cedc8c63e472def8b6a59e64febfa00e95568538c1a382ac91d2b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8a07f9a5faf428d95a6924d2e4d9aab65e9756b878d548a9ab04b57257c56c3878e1d451b36f264f6fdb1521162ccda089ad9e5c250738c983827e64dfd21b9b3662ce1c5fff45b2f73bbe47d0b1a6b208b4f2fbf78447ad5e12bf6e7a4596e" deposit_data_root: "0xab893bbeb9c8f1b0aeb760b31be1696736b2f7ee05edff8dcc6183d76adae267" eth1_data: deposit_root: "0x03d68d623a18dd6af2380829bcb89709b8024f8ba83771ac3f5135bdcdee00ee" deposit_count: "116" block_hash: "0x73d9f83ad8851e59c41c2b25e0e568dbb0ef8c23f37a006dcade3329a8d6f0f9" block_height: 117 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x97906a31d1ca59143dc947a1f048242f4c67382be296dcdf43a03951553464ed" deposit_root: "0x03d68d623a18dd6af2380829bcb89709b8024f8ba83771ac3f5135bdcdee00ee" deposit_count: 116 execution_block_hash: "0x73d9f83ad8851e59c41c2b25e0e568dbb0ef8c23f37a006dcade3329a8d6f0f9" execution_block_height: 117 - deposit_data: pubkey: "0xb41a0d9f8f19be13395aa09711b492d20eaf4a56d2360cd6daa2fd665532d852cb9224a5a39e5abff389882f961f12a6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9976e20aca195ad464d2e5bdff8f89100d8fa42357588bffae1c3ebce0af6ab593fdbb83b6e316fde942bad4dca225520e3aa856e5e5adb167c7fee7a1f022a9caaa0f199b5e5a2f7a2ecda1f016c02845f2168f0a144a1de33890ec8480441b" deposit_data_root: "0xc970a40ac721ba0ea1adff1e2f0a10b8dc9529a25bf867f8eb22359655eb5c66" eth1_data: deposit_root: "0x1e0d48b0764fedc0a118aea5976361d0612144be975699f762b00c0365b22cae" deposit_count: "117" block_hash: "0x1f8c317ca00006c5468170bb2ad996fc5264a4622b30ff4feabf2c3a923a622b" block_height: 118 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x97906a31d1ca59143dc947a1f048242f4c67382be296dcdf43a03951553464ed" - "0xc970a40ac721ba0ea1adff1e2f0a10b8dc9529a25bf867f8eb22359655eb5c66" deposit_root: "0x1e0d48b0764fedc0a118aea5976361d0612144be975699f762b00c0365b22cae" deposit_count: 117 execution_block_hash: "0x1f8c317ca00006c5468170bb2ad996fc5264a4622b30ff4feabf2c3a923a622b" execution_block_height: 118 - deposit_data: pubkey: "0xb242e56475dca34fe92de09daee3951d647c04ed7a483a5c5c5613676f5ca88d54ec64d1aee81fb0f085aa67c88ee6db" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb0e8b1ab87c739db7149b5e2756e3fec4cb8ca9ce14cd17af4064c85e0917dfdd4c40c13f6c48cbffe760a45f63567fa13272ef95f73c5fafbfe62336292af7c1cf68d2ea3a399729e330feccc375c237c6630a031c1badee92d8d463bf2c3e4" deposit_data_root: "0x458248ac4f1676159c16889a98e42e86fcb36615a646d1f3e8c0d56a5c5710a4" eth1_data: deposit_root: "0x1331f96e0caa629377f330bbad76213870a7d46ea84f70f3211344cd2864ff22" deposit_count: "118" block_hash: "0xa2c8860839e76bdc3c39ffe65914b4fe29936c31f0218c0ec7b1096f086e6066" block_height: 119 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x97906a31d1ca59143dc947a1f048242f4c67382be296dcdf43a03951553464ed" - "0xa325f304db3245c0b82c9770d2cb6ee122a7a8ee7b7d02568fcba7c3d74cd1c4" deposit_root: "0x1331f96e0caa629377f330bbad76213870a7d46ea84f70f3211344cd2864ff22" deposit_count: 118 execution_block_hash: "0xa2c8860839e76bdc3c39ffe65914b4fe29936c31f0218c0ec7b1096f086e6066" execution_block_height: 119 - deposit_data: pubkey: "0x894798d09babc765b3ba22473d820465e713c1d7f78f3eaeade3d957bd412a742f498a9b91e55cba8e08c36c8ad4788f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb3fe3f86d154a803bfbbcdf25da35ae7293e7a67ed8a486b2178424cf4dc4cd580419276d833bf6aebf02d5c59fb85c70e69fa7718448e6e590c5a88f81078982243ebc70eca16a8c65983d367597d9af062c7bec6e0657ed33c7caab044a6b9" deposit_data_root: "0x84bc2d2d601a86cf3f07e155e5fbf2c6a24a838c35c6f5aeb1cf8ec9f54076a3" eth1_data: deposit_root: "0xc711c10ca8badf31bce9ca6b0ef21a3aad8c94218e594891dbc49e5de5ef0480" deposit_count: "119" block_hash: "0x09861bc26ec9b9b75d164cba54b6b8f81256b16a0b8d4fad05c0bcb2368cef02" block_height: 120 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x97906a31d1ca59143dc947a1f048242f4c67382be296dcdf43a03951553464ed" - "0xa325f304db3245c0b82c9770d2cb6ee122a7a8ee7b7d02568fcba7c3d74cd1c4" - "0x84bc2d2d601a86cf3f07e155e5fbf2c6a24a838c35c6f5aeb1cf8ec9f54076a3" deposit_root: "0xc711c10ca8badf31bce9ca6b0ef21a3aad8c94218e594891dbc49e5de5ef0480" deposit_count: 119 execution_block_hash: "0x09861bc26ec9b9b75d164cba54b6b8f81256b16a0b8d4fad05c0bcb2368cef02" execution_block_height: 120 - deposit_data: pubkey: "0x93c65ba88f12ad22c761003cef7ffb155b9b17134ed871c0703fac60e80dbd2dd8d163bd28eba9dff88b1e9bd1ae4a76" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8358f8f27f66caf3abf2ab7ebead7028bd465266a29d6d465e94ed3bf4a26e7820379f90db0ddd4eef534a8fba0257691579607ef99b3e8cc06dd9994ac7b226a5cdf3b2e2c691ac805a26045d984fdcfdda393fdff9d27db2d8e6f58d49e364" deposit_data_root: "0xa702f084aa633619824587a2a5aa49dbe17cdf12bfa499bcc15fb2139f2773a6" eth1_data: deposit_root: "0x490811983daeadcb303ff1b7ff46fd6cfcd36dd23b0ce7949b4ee1db7ad695ea" deposit_count: "120" block_hash: "0xa6354e31dc8b76a24c330aa6be59b256b11155ac456a21d04e4bdfd3a0e56ba9" block_height: 121 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" deposit_root: "0x490811983daeadcb303ff1b7ff46fd6cfcd36dd23b0ce7949b4ee1db7ad695ea" deposit_count: 120 execution_block_hash: "0xa6354e31dc8b76a24c330aa6be59b256b11155ac456a21d04e4bdfd3a0e56ba9" execution_block_height: 121 - deposit_data: pubkey: "0x8ab4d3a78c54107bd7e71a0a006cb90dec379d6d86c9b6e4b3b010ceb37236cf2566febe76f955dbf0512884215f9f86" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x80ea3f9c01a6c761102737733f9e2f0911fafe3bededf9704e219c4537de0ad1cbc4e60a67447e1d25d53c24511ba3640d7aba5362c465042b7dbf40a7a8e0a5e8c002c511c36f7a45411e5770ceefa0571a5670fdf9fd2c0b6a4ca453866f73" deposit_data_root: "0x838301a371b334dc75bce42fbac042a519866b7fbd0741fdcacd54b584f1110a" eth1_data: deposit_root: "0x2d26430bf9f104f9295c2318bb2bd619f41f538ddb1407718bde5af1aa789926" deposit_count: "121" block_hash: "0x46004bd96b147395928f4342db995e0e5f8c84f6be8479f1713553bbfb32dc2a" block_height: 122 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" - "0x838301a371b334dc75bce42fbac042a519866b7fbd0741fdcacd54b584f1110a" deposit_root: "0x2d26430bf9f104f9295c2318bb2bd619f41f538ddb1407718bde5af1aa789926" deposit_count: 121 execution_block_hash: "0x46004bd96b147395928f4342db995e0e5f8c84f6be8479f1713553bbfb32dc2a" execution_block_height: 122 - deposit_data: pubkey: "0x982d829cab4f09be252a2c57b77c166679b7e9fdf6f5cc882462b8f4dc9a90beb303c85af56304fb79b975d3643e2ed1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa49e810bb59cc1194a7ccbd85e6571d2b3fb04372071e9f520bbc6a89f17ce2b4ea4e2efdd7566736e7415c2bb2d5cae19efa75295819f670b2e1a152e8eddda18de95518f2d8ff615f131030635b766504b98a0b72e8470f476ed70c86f3ace" deposit_data_root: "0xc8fe237e6c86c9da4429095bdfacab4dc1fd6a8145fb01abad35d9746e44ce9f" eth1_data: deposit_root: "0x46c5bd8627005a4b9e42e3844469187bec02232d2005a380c126d0c652cab644" deposit_count: "122" block_hash: "0x3472792b86ec4d8fcb0eafa369176a7c2f0836c1e258a0b136f20dc78c6fb5cc" block_height: 123 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" - "0x7504f9b600c756a12aa0e36a3cdeb84baf7704f65c12284994facedb4cb7130d" deposit_root: "0x46c5bd8627005a4b9e42e3844469187bec02232d2005a380c126d0c652cab644" deposit_count: 122 execution_block_hash: "0x3472792b86ec4d8fcb0eafa369176a7c2f0836c1e258a0b136f20dc78c6fb5cc" execution_block_height: 123 - deposit_data: pubkey: "0x908ad5c41ba5fc8bea0cd8f028806a823bda814fcf6c2c32b5656c42b5d3061cfb077ecde2a50bf374e055e8d5dad4c7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb557348bd23fe03c42a128cb692187bc5b6ad278a205080fb475e6fd80ae7ab4fa5d212e3124631fb3c8ba457cb8dfc009e3909b741811b93aa5cd82d8a79e6570c1bc7e21cb62cb4540d7588b1c09803fb8a5c5994b30b8e0675567a94db604" deposit_data_root: "0x5f3f0fad8eb6c5f9e0775ec949cdab9b768e3a35ff9f275dfba030661917ee01" eth1_data: deposit_root: "0x53ae75a6909e9c71ac74676e3a6d8b65f375b54444b70820da477d70eb3146d4" deposit_count: "123" block_hash: "0x731a443bb391702a1b35eedf368fe11f2707e192e5fa7f0c76cd4b3450486e39" block_height: 124 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" - "0x7504f9b600c756a12aa0e36a3cdeb84baf7704f65c12284994facedb4cb7130d" - "0x5f3f0fad8eb6c5f9e0775ec949cdab9b768e3a35ff9f275dfba030661917ee01" deposit_root: "0x53ae75a6909e9c71ac74676e3a6d8b65f375b54444b70820da477d70eb3146d4" deposit_count: 123 execution_block_hash: "0x731a443bb391702a1b35eedf368fe11f2707e192e5fa7f0c76cd4b3450486e39" execution_block_height: 124 - deposit_data: pubkey: "0xab4de8ffccf7b19aa6d7d4ccc4c82f091ebd5715b5dd6680edf9eb4f0dfc312e8999b89a78a8d4ed4512aec75a5e5906" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9789f3948b7b284a5082da4e971859ab6d11ebd59bba14e25a5fe9f933148d151f7e831dbbb1d2219a3548aa77b64a970b630ff661ef87608c446c8ee87eefb8728afcc9d3f062955e2059dc22cbe43120777fcc0bc080adf513864869b53a1d" deposit_data_root: "0x5968e76b664c7a893bd1d6b4770e2ab6c367986489cb078bf9ebe15a7c37bcf0" eth1_data: deposit_root: "0xe61360c04f1c6070915102cc3c8e1da6f83689c00802a0a4d9421b597712b380" deposit_count: "124" block_hash: "0xe7d04b58be7cc09e2efaec16fc8acde80caf3dfe208a1f399464ef1e01c7c6a6" block_height: 125 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" - "0x000a10f9b9b70f1743febe640ecb94109a63a9e80299df2f72bf1882689e6293" deposit_root: "0xe61360c04f1c6070915102cc3c8e1da6f83689c00802a0a4d9421b597712b380" deposit_count: 124 execution_block_hash: "0xe7d04b58be7cc09e2efaec16fc8acde80caf3dfe208a1f399464ef1e01c7c6a6" execution_block_height: 125 - deposit_data: pubkey: "0xb544d0df633f2334845f73a3921f2a716b9694baa6abcd7cedfa359ba3448029d5b874eef8b3f9f324f1ff4c0f997e97" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8fb8d58d8be318a8b649c3a74593aeb6c83698850be4571509ef5e2b053e3ace87583b89330b63a804fc56fec750be74030a530602fc80566be34a22b5a37389d036796f48619842b4b4169421c8deef8e745b2873e37fff345fedf94a395823" deposit_data_root: "0x69c57f789da4ec1bc1c89fd375a62a159775a522bb17763f98317770d40ae9a0" eth1_data: deposit_root: "0x0e122e727cad3ae0d09e532df6103c967179b5f7841b6e19b9d224e2abe11a40" deposit_count: "125" block_hash: "0x2ac76d9635e62e48f43779725791bc2955641b541ce279dfd8a1d4ee43242664" block_height: 126 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" - "0x000a10f9b9b70f1743febe640ecb94109a63a9e80299df2f72bf1882689e6293" - "0x69c57f789da4ec1bc1c89fd375a62a159775a522bb17763f98317770d40ae9a0" deposit_root: "0x0e122e727cad3ae0d09e532df6103c967179b5f7841b6e19b9d224e2abe11a40" deposit_count: 125 execution_block_hash: "0x2ac76d9635e62e48f43779725791bc2955641b541ce279dfd8a1d4ee43242664" execution_block_height: 126 - deposit_data: pubkey: "0xab77bbaf0047e03ef4bb1ddaefb777f263c9dd556502f3078d51790653a59452f1455d23002e175ec5b541cb69007f8a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x892fdcc974b84026d23901f0772bfcaaf8ed4817e8dd529525658a3f422e8248cad7fa34e9c6d12b3203fe211340b2a90ff420761424d417a446a66c8317f8b120e89c72b7a6ea0e822bfdeaa43fc4efee6568c7f0ce860c9c8499406ba58825" deposit_data_root: "0xae683dcb55578a08ab4cc416cbf6f9a4d400f611555ae3572f5be428049c264e" eth1_data: deposit_root: "0x2d75c60ef0c030b2cf8b18fa80490294476ed31bda31c346ba6c408d54bfb741" deposit_count: "126" block_hash: "0xea2226b57df5f18306352ff56c91e325260868a83fea4af3100d2adad1cad128" block_height: 127 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" - "0x000a10f9b9b70f1743febe640ecb94109a63a9e80299df2f72bf1882689e6293" - "0xeb193fa7b29a3c6c580bb7006a016eb539a1f3c2d0b529d8ca69462e48200c6b" deposit_root: "0x2d75c60ef0c030b2cf8b18fa80490294476ed31bda31c346ba6c408d54bfb741" deposit_count: 126 execution_block_hash: "0xea2226b57df5f18306352ff56c91e325260868a83fea4af3100d2adad1cad128" execution_block_height: 127 - deposit_data: pubkey: "0xb56c50c51aa1ba14062d9a477ae78646c459bfe12fc1fa3362f0652077a0ba090a0b780ee0b58085ad2b885fa4a37d4e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x85654b45a591e3ef272bf2d4f55ea861e6c06781b79059c0e3a56c07f86d7eef1ceae1d61cdba178078852d34103fc160a9499a05792e08759d15b414a6e174d7d01495fceda5a13517da3b020f4bbf54aadee63765fd78834ba3d6e99a003f5" deposit_data_root: "0x1aafc611bf508823603b5049d2bf7238853a3e19edf7af77fb8fd0d4d0057214" eth1_data: deposit_root: "0xe9a1d8e3b5b5bce6fdcd79c03f4acb7efdd73eb1071a1974af2cfa6f02d40f91" deposit_count: "127" block_hash: "0xf1097ac5fc5fb25e73c35efe2e9e75acb6cbf842cded0e5912d59f67433c92e0" block_height: 128 snapshot: finalized: - "0x7a8435cc00762702eb56b993adbe7f3b4f2e490152838e57fbbd87920ffc66d2" - "0x09a2fea2eb2470fc221e82ba026e7e9fe417bde2e54fafb68c804dc2a598cd59" - "0x0ff1cd5c2a584c83b12d7ad77a2e309ba97738719c0876302ce0ca1e9b02892e" - "0x750fa31940eac308088042d159ae2a9895b1c22f1b3aaf2faaaaf448dac52668" - "0x000a10f9b9b70f1743febe640ecb94109a63a9e80299df2f72bf1882689e6293" - "0xeb193fa7b29a3c6c580bb7006a016eb539a1f3c2d0b529d8ca69462e48200c6b" - "0x1aafc611bf508823603b5049d2bf7238853a3e19edf7af77fb8fd0d4d0057214" deposit_root: "0xe9a1d8e3b5b5bce6fdcd79c03f4acb7efdd73eb1071a1974af2cfa6f02d40f91" deposit_count: 127 execution_block_hash: "0xf1097ac5fc5fb25e73c35efe2e9e75acb6cbf842cded0e5912d59f67433c92e0" execution_block_height: 128 - deposit_data: pubkey: "0x8bc5c1b16286219f479f6d00b0b31b193811b499a86139c45ff4350d8c9b492421e854cf75fba1a0dd566e6ead8ad667" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c322ba5f9cfaffd49ce18217a4351f2bff820017197a676657a1d29d140d41697adb960d340ebf075808ca553bd594713c290beac55aecdc63f96f1da3ea0945360cc8ce7a8de60186ca7a25386a09b17f01d0f3f98c084ff9f998a2ac5fbdb" deposit_data_root: "0xfd64f7c42aff4433793cc1eceb1a97ed7e3dbd2f5588cd2c613b99fb2dd7ac03" eth1_data: deposit_root: "0x8aea1ce3d5cf89b67db5f909d4d50f4db94bd65fe6dba209e245d440a7723c71" deposit_count: "128" block_hash: "0x87ccd43a65dd5d36c0607edfaef9c6bd9d772e1b41da8140b5f93f23cf5a2c79" block_height: 129 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" deposit_root: "0x8aea1ce3d5cf89b67db5f909d4d50f4db94bd65fe6dba209e245d440a7723c71" deposit_count: 128 execution_block_hash: "0x87ccd43a65dd5d36c0607edfaef9c6bd9d772e1b41da8140b5f93f23cf5a2c79" execution_block_height: 129 - deposit_data: pubkey: "0xb7eaf282595bd590bde41f67783d12ccf7666aea2f1efbaeaa80c8478a157cf59ca7bf009e5a125163212b0b9f51c876" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5c648bb5cf946f279dd63efdbc85bb7567aeb488fa82fc07094fc2a06306a9bafa1eb70f96d767d1a183838866704cd18157b2e00c7c3ab7c8e97b75533ea364042359d5860aeb6aac63fc88ab600d73e66e10056da3b3149056731fe71f228" deposit_data_root: "0xc72d087b5d20cfd70d9183225d0617b9829513337759db9764a466e391605f30" eth1_data: deposit_root: "0x4e1a7a0cdaa453f648dd2eee6e210e5ce1ced22668c8389b14b69cf390d06e41" deposit_count: "129" block_hash: "0x1daf3d0631736aff5da169b0fbfaaf76670e04bfb5f1d582847873089630a2c8" block_height: 130 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xc72d087b5d20cfd70d9183225d0617b9829513337759db9764a466e391605f30" deposit_root: "0x4e1a7a0cdaa453f648dd2eee6e210e5ce1ced22668c8389b14b69cf390d06e41" deposit_count: 129 execution_block_hash: "0x1daf3d0631736aff5da169b0fbfaaf76670e04bfb5f1d582847873089630a2c8" execution_block_height: 130 - deposit_data: pubkey: "0xb404c5cda4dad57827e456beecf745b1ed9f2bf776ca0eb806010b80b8912b683c288b4f231bb67c29ddfcdeb16ca909" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89c8d47b8ef9e3282d2e9ba98c4d4cdf0fd362f210564e00a8531640fbbe574206826502ec05ea941cd31a5e591aa1b416230bf0aa78cdf74694681653c2b4e36286aa8d92d4086232d58e6b52096a526d4bbb476961d94202c63182b76b3ab0" deposit_data_root: "0xb38f387c64b9c9322cb74515298703ce4922ef2997c1064e4429f037f1609ebf" eth1_data: deposit_root: "0x5399bcc9eb6e3af50e9fba6c24424fa4df66ae4a13f6b03f7d50045c7c0c434f" deposit_count: "130" block_hash: "0x80ecd955e11b7c0379a794762c9e233d40df9af56efee83dcade1a18cad09982" block_height: 131 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xc712b8c0610483895c01d4680ed4421cc67ee49d0792102971ff4642b82e36c3" deposit_root: "0x5399bcc9eb6e3af50e9fba6c24424fa4df66ae4a13f6b03f7d50045c7c0c434f" deposit_count: 130 execution_block_hash: "0x80ecd955e11b7c0379a794762c9e233d40df9af56efee83dcade1a18cad09982" execution_block_height: 131 - deposit_data: pubkey: "0x944c4c5147a6b263898f335d2d59177c829d55901e5a4e394c9253cfbba6f0f3ce6ac393aa7b123f7a15db2909aaa37d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa46121a7594f41556fea16a1b3292312880391bce6deb315f12f445e326a2ed77b4a74007b876eaef7c8da205e00e6830bf6436dd332fa280ca379ede2c334279309527b076f1385c9e55da6319b3a534053cd4598a4979b35e136e81f7f2dda" deposit_data_root: "0xfc30a2ec2eb7b30f13ac732834306398cda4fc65e4677ef007bec1a3d5dbf18c" eth1_data: deposit_root: "0x8a0505df56a0bc3b337baea7a403e6076f751267b9b0b32eb3f377a4c7464098" deposit_count: "131" block_hash: "0x1a51a4d2db3c6a25fac8e8df0962130e493850d808d3a798dbaa7b3cdaea01f5" block_height: 132 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xc712b8c0610483895c01d4680ed4421cc67ee49d0792102971ff4642b82e36c3" - "0xfc30a2ec2eb7b30f13ac732834306398cda4fc65e4677ef007bec1a3d5dbf18c" deposit_root: "0x8a0505df56a0bc3b337baea7a403e6076f751267b9b0b32eb3f377a4c7464098" deposit_count: 131 execution_block_hash: "0x1a51a4d2db3c6a25fac8e8df0962130e493850d808d3a798dbaa7b3cdaea01f5" execution_block_height: 132 - deposit_data: pubkey: "0x97dfc5eb14556d1a85e34c069da71fc5e1bb5e17b421d9503f25d76a8f3cd0f2f9c5a1937e785e1c0e73edb6561dd176" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x82d599849169580c5cfe93e84ecf5935ab27dc88447836eb4f9d9d1875d8d5131356e5b220d6ef92de2cc8eb93e6301c0ca1107e2b33a0cfe4a82dcb0cea523bb223e47b91eeb8fda927ac6b951d5741004e2e2340a451649b266df4dcbcb38b" deposit_data_root: "0x0efa199eadc389a2e5876ed70eabd6fdb57b124fef39391a43197a06d4d12a9a" eth1_data: deposit_root: "0x6ff97ae565976870078e1d2df2f544fa9a9f52e522445e9613cbb9d6d0e0ae34" deposit_count: "132" block_hash: "0x5b5b8e0f913eb2cff3476e7e7cba6efc247b50f863093abe9184daa9c43ffffe" block_height: 133 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x21919d31feaad9b4f0198aa85b8c92b9162acdb2be06e4fbb76488dce29f6409" deposit_root: "0x6ff97ae565976870078e1d2df2f544fa9a9f52e522445e9613cbb9d6d0e0ae34" deposit_count: 132 execution_block_hash: "0x5b5b8e0f913eb2cff3476e7e7cba6efc247b50f863093abe9184daa9c43ffffe" execution_block_height: 133 - deposit_data: pubkey: "0x9145e0920e276f19fe65b9ea81339a41dee6e21ca12512005701a014426322be4fe504f853d6ae48314902fe9ff50a43" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xafaab29ec6f5ea64ebde52ec7d3fc4ec1eca00c799f9b73b51f40a59d8047d2623c7bc92456c3754a79c0b62c722db85113cb8bdcede6b95093a591f43f63098f9d558fb898f4098d6c731534288343e6b23fe04b1b0d36e49cdc03b6a097a51" deposit_data_root: "0x8e2528c2d652e704bf50d274aa2f813cab8038b2f0c6242556fe38e4ee1342a7" eth1_data: deposit_root: "0xc9c06b3a8f036dac268ac85aca78bc258b292b53bb870d6bb65d2e4400eee5a3" deposit_count: "133" block_hash: "0x5668a8e6259e5716d8988973626760ed0f8f381d0553230e5b74a5a9f01dcebe" block_height: 134 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x21919d31feaad9b4f0198aa85b8c92b9162acdb2be06e4fbb76488dce29f6409" - "0x8e2528c2d652e704bf50d274aa2f813cab8038b2f0c6242556fe38e4ee1342a7" deposit_root: "0xc9c06b3a8f036dac268ac85aca78bc258b292b53bb870d6bb65d2e4400eee5a3" deposit_count: 133 execution_block_hash: "0x5668a8e6259e5716d8988973626760ed0f8f381d0553230e5b74a5a9f01dcebe" execution_block_height: 134 - deposit_data: pubkey: "0x836c4b67713b082c060003d8fc839e265c1aca7f9bb82ce07f71a459d39073ebfdca87609859c70e55a1b0e7a613b395" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa04db5e044437271fd78d17b8f68970582937d883f11957506eb5a03e751ee98b10788be39acaa54ac43fdaf233d17470e7cbdaa7696e13a095e4cc2f1198e080f7d263b0e2f94f987d111ff479a24707b426aadee55e9df8aed27cf2f214c87" deposit_data_root: "0x3a112eabe9f6e71d1909cef64d68d32ff8ceeeed9247f628babab96f83f4c748" eth1_data: deposit_root: "0xff0787b73d84f56a8d8c4f58ee259b2a799758380be7452d30200be34a2b1697" deposit_count: "134" block_hash: "0xf158ad39fac4114d21115c72d76ef1486378b8bb3972904973e3bf415093e86f" block_height: 135 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x21919d31feaad9b4f0198aa85b8c92b9162acdb2be06e4fbb76488dce29f6409" - "0x27ef184d8974736eab9799399f71b459bd5a849f57939017510488c06a92471a" deposit_root: "0xff0787b73d84f56a8d8c4f58ee259b2a799758380be7452d30200be34a2b1697" deposit_count: 134 execution_block_hash: "0xf158ad39fac4114d21115c72d76ef1486378b8bb3972904973e3bf415093e86f" execution_block_height: 135 - deposit_data: pubkey: "0xb5217af9139deb6be95a106c7651e1d8dcd8eaa04f3c6196dd52abad84c862724603686f90c7c2a985f2d75a1c8facdc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x85a96d2f00884fe1e363e875256bccc230716611daa78efc84425b051008e606401bf9b5413b9b8f806b2177cf7d1cf20cd75f895c8a69c7cb59ff553af9fcc1dbb33c360a1834daa1efb5fe57322303fabde1f93e692c96b4bbfed668ab6268" deposit_data_root: "0xaa6054d15854b80f7ec7eaae6dee3a436a3fbc7a5b960d5a63b87cda94d45467" eth1_data: deposit_root: "0x450e75beff47dda09d642c64023e985bb9b4084c3ebb3fd93cee4ff6ecedca3f" deposit_count: "135" block_hash: "0x768e4089d2988baf80e8a20e391ae3827a2018cf543e42831949ee31d9abcb51" block_height: 136 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x21919d31feaad9b4f0198aa85b8c92b9162acdb2be06e4fbb76488dce29f6409" - "0x27ef184d8974736eab9799399f71b459bd5a849f57939017510488c06a92471a" - "0xaa6054d15854b80f7ec7eaae6dee3a436a3fbc7a5b960d5a63b87cda94d45467" deposit_root: "0x450e75beff47dda09d642c64023e985bb9b4084c3ebb3fd93cee4ff6ecedca3f" deposit_count: 135 execution_block_hash: "0x768e4089d2988baf80e8a20e391ae3827a2018cf543e42831949ee31d9abcb51" execution_block_height: 136 - deposit_data: pubkey: "0xa38b021855057c62bac15b2de83156dc8649bad858327b10cbab68c8fa3613a3de698322826d2644652ca9ef92664cb3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa8634b7543bd89635688f7842e0202b9430332a39d6ad9670277543387708e06466c21747af713f1c6cdf62f78e96411191d7bbd079322d3c6bbf1fc4f739ca4f6a77b304566a3a77768188efde4e240fa78245d5943a3a601192112a334a76" deposit_data_root: "0xfef7a5178631d697d14133c15287f33d6a2ccb3e6efe5dd46022965eca0f23fb" eth1_data: deposit_root: "0x9825f4b4b017dde1e6fda6ebb8a809409d57cc060bf19d44a9a898a26f75d50e" deposit_count: "136" block_hash: "0x051c8ee04d7535b585729a7ead7016d35ccd323e274e39a000a4d302bf454de5" block_height: 137 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" deposit_root: "0x9825f4b4b017dde1e6fda6ebb8a809409d57cc060bf19d44a9a898a26f75d50e" deposit_count: 136 execution_block_hash: "0x051c8ee04d7535b585729a7ead7016d35ccd323e274e39a000a4d302bf454de5" execution_block_height: 137 - deposit_data: pubkey: "0x828b5be17d71a278644b6fbe7ab5fd3a065312d1b03734e0b9d74703a566dc99815c81fc50b13725961376edc2f54405" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89235bcafefc07c6ed61bc483071b76d22e0881272925d61d8178942b701797d907ad10a3ef967df5f647863540e70d6052ba3814abffac5acb8bcadeb41b9c393dd2d664871535e6984725c7cdac5c1433abb7e05f06adcf75fd2c3a8e096f3" deposit_data_root: "0xae3d1bd187858e08287ed35692a78547ca791719a1cab975707b4c4c023d1f12" eth1_data: deposit_root: "0xf52b85738cb675d5d8f894f5653ed2e05cf513faae7dbec06e9b1841510d3bdc" deposit_count: "137" block_hash: "0x0bfaadbce1850c4917a8e7b161d3c926ce11488ae996ade89332e76c3c26e30b" block_height: 138 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" - "0xae3d1bd187858e08287ed35692a78547ca791719a1cab975707b4c4c023d1f12" deposit_root: "0xf52b85738cb675d5d8f894f5653ed2e05cf513faae7dbec06e9b1841510d3bdc" deposit_count: 137 execution_block_hash: "0x0bfaadbce1850c4917a8e7b161d3c926ce11488ae996ade89332e76c3c26e30b" execution_block_height: 138 - deposit_data: pubkey: "0x956aeb449c6e00e75a7795ea552bb0a2c14e065bfc9fee78c5a337f9d0c1814045802ad4f2e3c60868e54cd381809cca" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x819db83518bfe3262416f3592dc4a98a7811decc1c2e3b75adbec61e503cf31adc93bb0ab7167f5cb5659a4836dbb047141c61f810b392c68f8abba9699131fef029ad3ed054895b35c599460a3c3c25a9c0290bd3d4a51806cacef247589af9" deposit_data_root: "0x7863ebf9d15b7d7faf3eaa9c5921396b467c452ae27d2a17cf873fd03ebeb5b4" eth1_data: deposit_root: "0xa5000d5a716be585c7263959af46459fe207ccfee4b131e340db755d7841b6e3" deposit_count: "138" block_hash: "0x7e3ff3c5214e2e9d1bf033fbd58772d2df71241ff00f285e467559ba2c435729" block_height: 139 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" - "0x4e197bcd1ccf6d1ef8b4b3c658d14cb45b72045390d6afc86479c562d99290ee" deposit_root: "0xa5000d5a716be585c7263959af46459fe207ccfee4b131e340db755d7841b6e3" deposit_count: 138 execution_block_hash: "0x7e3ff3c5214e2e9d1bf033fbd58772d2df71241ff00f285e467559ba2c435729" execution_block_height: 139 - deposit_data: pubkey: "0xa0ab6917fd4c65ff95b1a5ed5f3c0d7cef103de58a90f2cc5383b4914566aa085f04e8505c862a29a0c914072746f83a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b99987e93032d8d9d07d726957fe4394b818ee34dec214aa6dcdb1469f0ed7aa0dfeb4ed805baf48ef287f97b9058140262f05105769e65decbac6d3df02f712cfb0ad7a2ff65eba13fcc167d94d993f8c3148143731d4eb028ec23902443a9" deposit_data_root: "0x4fc27de5f8c8d68da0bb0258d0151521fbac62e4967c08b8876cd976ba113e59" eth1_data: deposit_root: "0x270aab20e630999f0ebe072b5f955d7d0b6f0919157002eab351eef7873a9b1a" deposit_count: "139" block_hash: "0x294cb83538800d76ddc52bd16c33ff956de7f5b94d9419178b50824aefeed6b5" block_height: 140 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" - "0x4e197bcd1ccf6d1ef8b4b3c658d14cb45b72045390d6afc86479c562d99290ee" - "0x4fc27de5f8c8d68da0bb0258d0151521fbac62e4967c08b8876cd976ba113e59" deposit_root: "0x270aab20e630999f0ebe072b5f955d7d0b6f0919157002eab351eef7873a9b1a" deposit_count: 139 execution_block_hash: "0x294cb83538800d76ddc52bd16c33ff956de7f5b94d9419178b50824aefeed6b5" execution_block_height: 140 - deposit_data: pubkey: "0x93e08f94b3c1e5e9e7454185c5493111db66673fa0f1ba86d7a395858a32fd2c2ccd0c4838affb453112f0e9a8e3a370" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xadf8d364f8bfd7352b5423ec6e9891d9dda14132bb5fca8ec977b3eebda7df0e67a3dbf69e7c470714ef28028cb4190b18c5c998b8ec2d65089e4f1e89ef078c3b3d20f8a1c223a4d19cf7b6fe94be511c6633da6d64f2c60148926bb05f284f" deposit_data_root: "0x394d27e70621db71ab9db062b080a827591c330679e0db882e6086d1ce0004df" eth1_data: deposit_root: "0x6a884aaac611577d4a3e6b1beda285d44e45c7908553df6142fcf83dfb30dfe2" deposit_count: "140" block_hash: "0x2ce6dbcabe45faa4be2c1f491500699fab5011beb8f8edfa6125188d5c75f474" block_height: 141 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" - "0x94db8bffb5c1311bba8a0713a8cb1ae95ce40c9b0dc482ffc6273482df8a11eb" deposit_root: "0x6a884aaac611577d4a3e6b1beda285d44e45c7908553df6142fcf83dfb30dfe2" deposit_count: 140 execution_block_hash: "0x2ce6dbcabe45faa4be2c1f491500699fab5011beb8f8edfa6125188d5c75f474" execution_block_height: 141 - deposit_data: pubkey: "0x907c4f53d28167c96d711746d338b7428e7ffa389ec76497920c25445df3b1ce7e88648a5fa9f4e1b5d2d254938bb65a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb718c98631b6896423bc477b0c6b6c38aad77af35657008c27a760225c17f1d83244c9e67b031d1ff54696774c9e03a70397a5377b9ee1a4f05b4086659fefcad9e8e8992feefa489b51e35063789424dda7cef6c87a5a52ffedd58f87e9e1dc" deposit_data_root: "0x27c015fcfe5104cd1c8d15aefb823bde65e61ea352c3b2d2886eb671caa5e700" eth1_data: deposit_root: "0x34867700acac7b229aa98c88283ca0967e781d7640ffe43521d8f32a43b44521" deposit_count: "141" block_hash: "0xdd2ca2e628c5fe5f8e641e57a076568b40c0a85522cc2e0860f38eeff295e68f" block_height: 142 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" - "0x94db8bffb5c1311bba8a0713a8cb1ae95ce40c9b0dc482ffc6273482df8a11eb" - "0x27c015fcfe5104cd1c8d15aefb823bde65e61ea352c3b2d2886eb671caa5e700" deposit_root: "0x34867700acac7b229aa98c88283ca0967e781d7640ffe43521d8f32a43b44521" deposit_count: 141 execution_block_hash: "0xdd2ca2e628c5fe5f8e641e57a076568b40c0a85522cc2e0860f38eeff295e68f" execution_block_height: 142 - deposit_data: pubkey: "0x987b620dd2ade22c44ac3a642d17ac9009da6c2d989028957da877e5178668216cb9ad2314a520ebeeb8b032614ca2f7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5294d4bad5d63db39d236813cbc1032093b8c7649d28b4b2515c03855f56d78ee8b243e6b29935d83d6a9ce344d2ae618894c91dd7cd82eebe2020938f55ee77b95118ecfc2a80792b23e75251396cb09edad531138fc2129d3442934472fea" deposit_data_root: "0x55bcef5f8cc010243428b8c8d96fa0cade22f5df82fdd813c337482189f7d33e" eth1_data: deposit_root: "0x6343479ad51df7360082d3c7736a119a9cf461dfe40f749490b98cd60c48b1d8" deposit_count: "142" block_hash: "0x3fdc183d26e681a76cb366df8540c48422832c01893da752c20c02764f3e42ef" block_height: 143 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" - "0x94db8bffb5c1311bba8a0713a8cb1ae95ce40c9b0dc482ffc6273482df8a11eb" - "0x61ecb3ba1163a8bd70a0c91060a0d7df5c5f1d429222c6da2628d42f51140b8b" deposit_root: "0x6343479ad51df7360082d3c7736a119a9cf461dfe40f749490b98cd60c48b1d8" deposit_count: 142 execution_block_hash: "0x3fdc183d26e681a76cb366df8540c48422832c01893da752c20c02764f3e42ef" execution_block_height: 143 - deposit_data: pubkey: "0xb4bb3db19f9162fb238ddbdbf5b8e819696e90783775249825d64767625f2b6e9c52edd859bf8afac8a87371e9100d24" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xadbff5ad606002d50ac669f878194974fb3f338b8301fb46426e92b4e65309b1eabf85441ddd75dadd6eec5293ee05df0860040dbf875e698cb23cadd960b8eb23674a86795bca545385e8b03b847ab4ac7970a6b2a73b960e54866b11fbd1ab" deposit_data_root: "0x79b12382ebfde996e7dc957b826c432d14eb7f3a3b61c61800707f60c4bf193a" eth1_data: deposit_root: "0x4095812eaf8df557e3e6c36dd16b99952769d623281342926d22b6d07d270553" deposit_count: "143" block_hash: "0xc782ae505c8831621b6d9afd7fff61d359f1d39248aae61504d561695fbb8d10" block_height: 144 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x52228e1e54f9b75dbb4c3e67d77e36c395d945cb6a4b5494c18eb1218db1ebb2" - "0x94db8bffb5c1311bba8a0713a8cb1ae95ce40c9b0dc482ffc6273482df8a11eb" - "0x61ecb3ba1163a8bd70a0c91060a0d7df5c5f1d429222c6da2628d42f51140b8b" - "0x79b12382ebfde996e7dc957b826c432d14eb7f3a3b61c61800707f60c4bf193a" deposit_root: "0x4095812eaf8df557e3e6c36dd16b99952769d623281342926d22b6d07d270553" deposit_count: 143 execution_block_hash: "0xc782ae505c8831621b6d9afd7fff61d359f1d39248aae61504d561695fbb8d10" execution_block_height: 144 - deposit_data: pubkey: "0xaa083a83471b7938693e54b673d98f90340fe5cd2556b27eeb9c9069b7150e853391d47543dab155f6fdc8ab7f2e185a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaf55c3b8d00ede905a7e5a546aef5e817f540950cfcb04fd86a16f4574897c7118d1a971cb06018ea5a8d59b673a6e19060462b839135255e8790d9c2152fe2497f090027242091f0fa19d957524046f920b4e980631216d9ad88ffae00894ab" deposit_data_root: "0x62f0c56109eaf759c780578e7fa47725568ac9c4b417a79f75e0778b98f8dac6" eth1_data: deposit_root: "0xaab06426f70faa1c4f596a4f42f15dcfff709218d7f4c479835e15d0f7612f82" deposit_count: "144" block_hash: "0xa8bd5909dae96b248a94193373f3ebc4050994aee8ec82e5eaf61530e66ba126" block_height: 145 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" deposit_root: "0xaab06426f70faa1c4f596a4f42f15dcfff709218d7f4c479835e15d0f7612f82" deposit_count: 144 execution_block_hash: "0xa8bd5909dae96b248a94193373f3ebc4050994aee8ec82e5eaf61530e66ba126" execution_block_height: 145 - deposit_data: pubkey: "0x916d306c24956c1a97678695330d240cb492062889dbfbaa6349cf53259c719ef83748b065e4a30fa6edf8a171af326b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c8963319e8e7e3dab0c8048410b8818fa648f4a4e337d06d2226e5732ce99e8089103886812055eee70315a028ea5b3044691168068d150967f6dd432e585fdfc9ac2d5b593add5e671ec6a1ef1fecf265fbe43f564b1d63ca3ed6dc1d1d49d" deposit_data_root: "0xb779d0910d0c595a2fe92c63c2e8882f2e0db6c55f749864cda06e9ab53a1175" eth1_data: deposit_root: "0xd41b2fb56eabbe8a5494e16f53677b85e8329a31bc1b106c57e0d67ec4f08c2b" deposit_count: "145" block_hash: "0x59e61e4cbfabe9ebff9d7632bd4946b9b34b40bd189866c9d3a300f7e88584ff" block_height: 146 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb779d0910d0c595a2fe92c63c2e8882f2e0db6c55f749864cda06e9ab53a1175" deposit_root: "0xd41b2fb56eabbe8a5494e16f53677b85e8329a31bc1b106c57e0d67ec4f08c2b" deposit_count: 145 execution_block_hash: "0x59e61e4cbfabe9ebff9d7632bd4946b9b34b40bd189866c9d3a300f7e88584ff" execution_block_height: 146 - deposit_data: pubkey: "0x89d9aef34711c5ea0787f591e4683f34727391729c0a402702a51de4d6a36a9324e1c77890a1b34c70a06d30bf9cb0c9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa558bdece7dc28e7a68298edb2b4d9277e21c590ec58c8e9cbf85560ce442eb91b5d35be159961dded127f612a232bff0b8df1043e6d592a498d2f672032a443e3a235337b2aeb596cc24bd20aab9001357399c450dd911107e6860e061bc6b2" deposit_data_root: "0x952e03098c3a3e617b2085b2f360883902c7560615ef16f06ad87aeef11d4b13" eth1_data: deposit_root: "0x42a6aa131d749068ece539bb5dd92c0b35abadaf3fdd09e6dbbfbe3a9864a4de" deposit_count: "146" block_hash: "0xdbdcb5286172a0827e2cf09afb3ec1a5edf6210eceed78570a82ec9b985793ef" block_height: 147 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xfcb2cabbd2e78c7299e4090c745a5f70f964f9609e16ef7dbf822ec6be390b5a" deposit_root: "0x42a6aa131d749068ece539bb5dd92c0b35abadaf3fdd09e6dbbfbe3a9864a4de" deposit_count: 146 execution_block_hash: "0xdbdcb5286172a0827e2cf09afb3ec1a5edf6210eceed78570a82ec9b985793ef" execution_block_height: 147 - deposit_data: pubkey: "0xa3cc6919919abf050a3e64b6c5d826148ee3f766e6b67e7e8000645e51ebed1b9c6a20b9b7413a4eb835529cbe4f77a9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5eebafdde0dcf96d9ed536932dac3368f11890a1c9047ce33777dd864b8edb96d627c643dc10a1ad25704bdc94a10d81163c449b7cb1298523fe6817f78d6c99a89bea5c444452057a26a8002b66129b895f24ca1e5594b07fcff0734df654d" deposit_data_root: "0x416f86acf71961090832d765a7a736ecf18cbb6a1fd9f1e42ba0ba99abcc5a1c" eth1_data: deposit_root: "0xd0c5fe81027e3262bf1682a130fb3952371006f707a02c98cef95952e116b566" deposit_count: "147" block_hash: "0x762506294eb00ae05c84543d9b495e2b0b24047aa0ff1d747ff474498d1176eb" block_height: 148 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xfcb2cabbd2e78c7299e4090c745a5f70f964f9609e16ef7dbf822ec6be390b5a" - "0x416f86acf71961090832d765a7a736ecf18cbb6a1fd9f1e42ba0ba99abcc5a1c" deposit_root: "0xd0c5fe81027e3262bf1682a130fb3952371006f707a02c98cef95952e116b566" deposit_count: 147 execution_block_hash: "0x762506294eb00ae05c84543d9b495e2b0b24047aa0ff1d747ff474498d1176eb" execution_block_height: 148 - deposit_data: pubkey: "0xaa70cfdc554a8e67bbd3e6f3d2a0ef61c2a7ce1784acef01e9d7f08ee3a4723c2b7bd789c4bb687f19466a58e6e7bb34" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x937471d746fdc9d2bdc43b70133bf53b8c934685e3a220b02d6615648ff1c2d17afe93e5e8844825a1e71e30269e703d02cf89a01ea5737c58964ecbb42ec4736721f66cf549231b1baf839ad3775665ee3db8f5af6c7abc76fe4985e881f3d9" deposit_data_root: "0x11fa92b165b8cdd90432e623dd16b219357f7258304be89741c3748fc2b07281" eth1_data: deposit_root: "0xabbeb3c7c12ac8ea30a18ca7f4953f788c6d7b6d28375d597ab8188ae4750442" deposit_count: "148" block_hash: "0x49319e6b9bd5b42ee760b78a016ff8c3472c40c0aa015f6f64c26f8ec9b73da4" block_height: 149 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0x2f36ad9e26bd49169087381023a518ca363e37b699bea22fb07fe8fc2da3721a" deposit_root: "0xabbeb3c7c12ac8ea30a18ca7f4953f788c6d7b6d28375d597ab8188ae4750442" deposit_count: 148 execution_block_hash: "0x49319e6b9bd5b42ee760b78a016ff8c3472c40c0aa015f6f64c26f8ec9b73da4" execution_block_height: 149 - deposit_data: pubkey: "0xa1a1b99827c25c1079d4ed035a31478a38c2141db49291d0fcd10b64eb6ee5b0d9e758a9b47f40b2092f1c150bc28e11" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa843d0ca06dc76c42f57ccc9a5f50b5c17f39135ed33d3eef9a9b88826c3cf5dae2e1991f40163184ed4cf375d37ac2f147c75eb8b4e3790ff510008c0960eec1c5bca5af9c7e4ddf81277acdfe4f264cbd5d1cc1608b0f3db2fe000e2edb789" deposit_data_root: "0x1bc04fb54834e25adfacf21f8408527b4ada1fb47d5355cf0024436cadb5df12" eth1_data: deposit_root: "0x4165f4725bc2e58cef28e6a287ba3fd6bf46f445fc65b67d383d7d6b7bf709cd" deposit_count: "149" block_hash: "0xc5a9ec49e34f270b82dd423e53c924b72387fe2987f8b0ba039efaea92a57b63" block_height: 150 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0x2f36ad9e26bd49169087381023a518ca363e37b699bea22fb07fe8fc2da3721a" - "0x1bc04fb54834e25adfacf21f8408527b4ada1fb47d5355cf0024436cadb5df12" deposit_root: "0x4165f4725bc2e58cef28e6a287ba3fd6bf46f445fc65b67d383d7d6b7bf709cd" deposit_count: 149 execution_block_hash: "0xc5a9ec49e34f270b82dd423e53c924b72387fe2987f8b0ba039efaea92a57b63" execution_block_height: 150 - deposit_data: pubkey: "0x87af7702ff5e6e9a4416bbb516c3aeec7827408b75e3d1a8d420031157ba7a5a4d1eb565d29f100c5cdaddc05399bce1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xad97e9253436103fbb79067fea41d3db0b36abbbf2c9a345ac838a16b93ebc6fa0414bbe4c96514c67dfb5e4d207df200bb413b4ea1be94dbaf9d008c49aeb2fdd0552dbcf171e0f8a6fa89bfb6139d606b5ed0765b4047c489999bcbac53c24" deposit_data_root: "0x1d331b2e13e8ff1333f00c80b5de05a294bfeb904d782e6636461a4ec01cca24" eth1_data: deposit_root: "0x5f04ee7b040e36e61c3abf826d86c178cadd08541f545298c02d6fcfe7defae5" deposit_count: "150" block_hash: "0xe44b8c19d80353eaaebdbad5689d94f2c68ce2977dd2c687ee64560e75bd46e4" block_height: 151 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0x2f36ad9e26bd49169087381023a518ca363e37b699bea22fb07fe8fc2da3721a" - "0xdecd5c32fc1a5a55f4b2dff4cefc1b493884d7c78f74b3d9c399f3a583ba4aa8" deposit_root: "0x5f04ee7b040e36e61c3abf826d86c178cadd08541f545298c02d6fcfe7defae5" deposit_count: 150 execution_block_hash: "0xe44b8c19d80353eaaebdbad5689d94f2c68ce2977dd2c687ee64560e75bd46e4" execution_block_height: 151 - deposit_data: pubkey: "0x8db57d195b1216309f3182f522ee9c6a724af5eebfc8faf058edb4e444a74f7ca9fb0f227a7960887abf8ec4697ef4d2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xac2c9dfc4a9bfb53a71b7647109bcf478924d240e2501655e30e4fa4db22bd7f004513f5600dc19cd66141ecd1ff775904b8085d23885c3a414fb8883bd7676b32f008dd84beb2e32ff444a9e7c047cb2884ff998644aa5ffde04acb7a1a952a" deposit_data_root: "0x664b99054c780ab51854845d95d8ccad24d1f9a45fbadf4f04664f9e533da249" eth1_data: deposit_root: "0x1bece2bb88b659bbafbd110cbc8d8765c5488f30389cc03a4b48730f8324f501" deposit_count: "151" block_hash: "0xc5ed7232fa2461e41d333f13bfd2e3e7f113aef12fe4e465f1c9ad345f140679" block_height: 152 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0x2f36ad9e26bd49169087381023a518ca363e37b699bea22fb07fe8fc2da3721a" - "0xdecd5c32fc1a5a55f4b2dff4cefc1b493884d7c78f74b3d9c399f3a583ba4aa8" - "0x664b99054c780ab51854845d95d8ccad24d1f9a45fbadf4f04664f9e533da249" deposit_root: "0x1bece2bb88b659bbafbd110cbc8d8765c5488f30389cc03a4b48730f8324f501" deposit_count: 151 execution_block_hash: "0xc5ed7232fa2461e41d333f13bfd2e3e7f113aef12fe4e465f1c9ad345f140679" execution_block_height: 152 - deposit_data: pubkey: "0x8cd26495562e8fa526dd3dd5ccf7706e0b802747a2858ca76e4be7e9188ecaaf095b7ba58cf504057c4039e990f88618" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8370ace5a4fcd6231c5bab72652d4f508a407e5d7b177ff034ca82a1efd0d06b23b618f17268d7ab67f5a964beec59e0d929c6b611092e67099be102b77782d704d63da4e6137bdff977eed1e526332624e5c052bfa16e71b9296ffd5f4e1ad" deposit_data_root: "0x82ae1b44b3e9bdcf2b48fdf000acbfbb762153634aac9d5ed5663bd6fe57ddd5" eth1_data: deposit_root: "0xa0a5548e34617b4b07307f5e80a50b88320c59ad0b655a8b3d01f7e77b96cedc" deposit_count: "152" block_hash: "0x42f0b6cc26d7613b3658fa113804dfc7624a3672887ca41229f9000a5f1eade3" block_height: 153 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" deposit_root: "0xa0a5548e34617b4b07307f5e80a50b88320c59ad0b655a8b3d01f7e77b96cedc" deposit_count: 152 execution_block_hash: "0x42f0b6cc26d7613b3658fa113804dfc7624a3672887ca41229f9000a5f1eade3" execution_block_height: 153 - deposit_data: pubkey: "0x95d668e777610672265275332a570af04c1a6090d9caae5152b66d476a7ac895c120e68724bdf30d3a51ece24a76b225" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb0bd20a856159c8ce771848cc33ca90aebe6bd56f8537a2ceed4a3a043cb448d489342b299bfcca3333a3f10c7c483780b335c78197a348eb2d0d28cf16e2a50368478693799d9b46076fbae6981732deacabac0bfe9747c5642477fa3718e59" deposit_data_root: "0xf952d77f6747501c8f12ac319fc9b537ffeb20e38afc5ff9046521c27076607a" eth1_data: deposit_root: "0x77bd65842bb2ab1513449bbe102333c0bd621424fde5d37257a32c3d26eaeb5f" deposit_count: "153" block_hash: "0x9af33652ee1b895df878aec4adb356e1bee86181c4c6117a1bf4ad21c1258669" block_height: 154 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" - "0xf952d77f6747501c8f12ac319fc9b537ffeb20e38afc5ff9046521c27076607a" deposit_root: "0x77bd65842bb2ab1513449bbe102333c0bd621424fde5d37257a32c3d26eaeb5f" deposit_count: 153 execution_block_hash: "0x9af33652ee1b895df878aec4adb356e1bee86181c4c6117a1bf4ad21c1258669" execution_block_height: 154 - deposit_data: pubkey: "0xb37c32301c15cf9a62fdf10ac221d751918f78ca95cf7f79b5a3828fe77c88561cdf863454133bc4bf56e6209b53d0d8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8938e16203e369321f5e88d883f7ee521005230d74981fc6ccde25b775982cefbe88888ca720bfb48b2f77aed3d849221874fb97dde7bbe699cb17b397bdf72fbe580302fdcde9dff66c2567a1c518c63eb4a923619918ff18e76167c184c017" deposit_data_root: "0xbcb802dd617c023460f14a9e490207b829016a9b88cbb44b87fbd9fed9a00452" eth1_data: deposit_root: "0xece431b6b5a2d074c528e73dd8a1fc686e167dcf3575e118deb1c012e2beba56" deposit_count: "154" block_hash: "0xacd9c61ebeadae453909aac86b39107821848a4c7e85e7ae99fad8f46c09c5dd" block_height: 155 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" - "0x11665987a6e900976d175d96c7ec5ddf750a00e89237cba75d596b7355553279" deposit_root: "0xece431b6b5a2d074c528e73dd8a1fc686e167dcf3575e118deb1c012e2beba56" deposit_count: 154 execution_block_hash: "0xacd9c61ebeadae453909aac86b39107821848a4c7e85e7ae99fad8f46c09c5dd" execution_block_height: 155 - deposit_data: pubkey: "0xb923cab7abb3e0b5a8ca7b841662262014e59dd8ab24ef4513ef5fc1c85dc1860bf4fee2565a732a7df4dd73ff638403" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89fb7bcb413178f88f843949a819180630d0651d184fea6bbba521e241c52834e9c9b1ab7496d6791f99b3cd4c0d23cc15b3ccb9893badbc524e1e67b027961c3d43661348c6a938c87f573d0f59919db632ef38279b28e03593e4bb9d1587bd" deposit_data_root: "0x0c4afbd64a8f690f413bb4eb4ba458f8af3c57cb27ef5043155e5ae329db963b" eth1_data: deposit_root: "0x5699749c403acccf444931ff8920ea52316ce8ba01b47566db967ac82998be4b" deposit_count: "155" block_hash: "0x5b56da2713e1546d90efde2fce7553310399d03774f4495e3ddfab74615c91e1" block_height: 156 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" - "0x11665987a6e900976d175d96c7ec5ddf750a00e89237cba75d596b7355553279" - "0x0c4afbd64a8f690f413bb4eb4ba458f8af3c57cb27ef5043155e5ae329db963b" deposit_root: "0x5699749c403acccf444931ff8920ea52316ce8ba01b47566db967ac82998be4b" deposit_count: 155 execution_block_hash: "0x5b56da2713e1546d90efde2fce7553310399d03774f4495e3ddfab74615c91e1" execution_block_height: 156 - deposit_data: pubkey: "0xa25d1dd7f5dc5ed5aaba0187d33ee72921d6455b6052c657d87e108aaeee9c31c53701e7b288ae0f9ca74cae34a1f49c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x918558e2fb2ed8d33bc35cbb6794dce54fdc363d07eb66d2b8def16d8ff28be953d0d2b9d4207e6f1b4157aecfba99810472a8ad6fcb41a6f968a83c82cb140ba8bf1bb947f742ad470f4f3b83d447e38b925578e07f421c6a518a57b23dc84c" deposit_data_root: "0x069c4690e4914d5b8fb41fbd74c9205c5ef329affcaf903ec8293ccbf3943bcf" eth1_data: deposit_root: "0xf287114b93614b301a10c43ed09504c14298377eef05000f902e4cc5ec7daef6" deposit_count: "156" block_hash: "0x9bdce9e95c9fb72c2018eddd357e19ad47107c224bae328531bdd0716e7e500f" block_height: 157 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" - "0x5cf0c39a7fa083994f7baf809c387f9ab82024f5f1bb1e9badc5d3b26c5c2973" deposit_root: "0xf287114b93614b301a10c43ed09504c14298377eef05000f902e4cc5ec7daef6" deposit_count: 156 execution_block_hash: "0x9bdce9e95c9fb72c2018eddd357e19ad47107c224bae328531bdd0716e7e500f" execution_block_height: 157 - deposit_data: pubkey: "0x824904d20a5620ca46c015ff630e1e26fead9df53243354ace937f01a971916e8883687a8e5f087598c633a91d0d6fbd" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb238a8b1da5862bfce25d25b502130c2809263d257efdf8eef3da05a7b75b70f463f57a7c14e21b5853dfb404a6e3e66017f1d987fb634500fe403fe0ee06f0a329108af069c05b429dfc2b0ef87d7a384dfd10ed0d7b0ab82d335ed33bef84d" deposit_data_root: "0x1147a26009ddb6d159aad698f440619d7503b848807e09679dcbd58bf1b3a899" eth1_data: deposit_root: "0xc7307a5a78027139f9a0fcb9ec77193528b7067f2468b26ba79f6155fa579205" deposit_count: "157" block_hash: "0x1f02f863183c9f6f57bf3146745f7461290f64f73065bcd52e065e97ca1f4ecb" block_height: 158 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" - "0x5cf0c39a7fa083994f7baf809c387f9ab82024f5f1bb1e9badc5d3b26c5c2973" - "0x1147a26009ddb6d159aad698f440619d7503b848807e09679dcbd58bf1b3a899" deposit_root: "0xc7307a5a78027139f9a0fcb9ec77193528b7067f2468b26ba79f6155fa579205" deposit_count: 157 execution_block_hash: "0x1f02f863183c9f6f57bf3146745f7461290f64f73065bcd52e065e97ca1f4ecb" execution_block_height: 158 - deposit_data: pubkey: "0xaed2a3ef693d13698e77966b8125442ac40ee0a62e8d97f71493c966da3c8604932dcee09606c2394afed25f8ad4f31c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8e2b32b5180bba930cd1d405258ec2cd4a7dcc0bba374a4da4e57ba6084db5341db349348413d6385fd336cd476eb1e41396bfb8201727239547f3f175b8baa7b0c98de9aca97fe7226a5fc354e7d16c39275ac3ce5bd36f3fa5ffbbbba1e4ab" deposit_data_root: "0x1e35604482803af5afed89b925dcb5e9f41ab291388918e7b317d467e8bf2aa8" eth1_data: deposit_root: "0x6858813a05b486da3ccdcc7c09b56d5a96b1396a594ecf561ca209e7273d2153" deposit_count: "158" block_hash: "0xd52fe7ca49fb3425010be4c5fc698606361cdbecd68ef63800d013391b53939c" block_height: 159 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" - "0x5cf0c39a7fa083994f7baf809c387f9ab82024f5f1bb1e9badc5d3b26c5c2973" - "0x431fb43239425b2f4faf58bbfc2e8bf64202d513954ef412ee9154052f667c4b" deposit_root: "0x6858813a05b486da3ccdcc7c09b56d5a96b1396a594ecf561ca209e7273d2153" deposit_count: 158 execution_block_hash: "0xd52fe7ca49fb3425010be4c5fc698606361cdbecd68ef63800d013391b53939c" execution_block_height: 159 - deposit_data: pubkey: "0x8f8ac057107bc490de273453730753b9e2b69df03917a0addbfb13c5152d93fa05702cf21d8b58ed7c08ac3295c1de3e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb799bc548db09f68b31bc25159d865b5925ace14d63cfa21af51f8e822d85b6221ad968839f1bc57e8218e5a8c093fe6030098d5c8c43a59bea334048bedcc511b3ffb6c1d64876d0214238f70b27267e606afb1747423b1aa254209bea36e8e" deposit_data_root: "0xcc6561589f174b04b6adcf0b2a893667c65f3443bed0e5c8a3af84d3157c3baf" eth1_data: deposit_root: "0x28bfff0f74194d7bfcc9ba76c21cfe0c2908f605b8017e023792ece9d9b1c1eb" deposit_count: "159" block_hash: "0xe93ddeb537374b4dbb453dc08411c26a02c36c9d3b77f4b9679a89bd75b70dae" block_height: 160 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xaf12585229c24dfcac5f5fa3ac66011dabdfd39529f6d98c07abfa998c1b4e52" - "0xb691ba9f86444f0a58a7e0becd7c3bad9b44e5bf6a88b85a7cfc6f243f6e2fb8" - "0x5cf0c39a7fa083994f7baf809c387f9ab82024f5f1bb1e9badc5d3b26c5c2973" - "0x431fb43239425b2f4faf58bbfc2e8bf64202d513954ef412ee9154052f667c4b" - "0xcc6561589f174b04b6adcf0b2a893667c65f3443bed0e5c8a3af84d3157c3baf" deposit_root: "0x28bfff0f74194d7bfcc9ba76c21cfe0c2908f605b8017e023792ece9d9b1c1eb" deposit_count: 159 execution_block_hash: "0xe93ddeb537374b4dbb453dc08411c26a02c36c9d3b77f4b9679a89bd75b70dae" execution_block_height: 160 - deposit_data: pubkey: "0x8fe63d0f0da14a975a69446571eaa08409b6b4d091c720ca26519156a1cbd9e0fd44de574d8486ff98ad4086e0d96f59" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa80cc551d9eb7d869858e173eb701e706fa8bb1fd82e798bf19085c1b07d1b4807681fa0fa34ab3f802ddb664933a43513a14975a33d720b949c4873ce646f8f80ea6e8a645e404c81441b7ef30076650694972b8cbc3ff2062ff4772dca91c2" deposit_data_root: "0x59822146ece6a1e35fa5c3b0b38f1a7ccfb6cea652ae7d6d6867a0cd2298276c" eth1_data: deposit_root: "0xf125f86aaf7df54e79f43355d6be50d55daab4addaaabae4c58e7a977f3b1cc2" deposit_count: "160" block_hash: "0xb6bbba5e6a9fd9d2972588347d65cfc8633717b19e2c059aeae1c55f790b6ea0" block_height: 161 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" deposit_root: "0xf125f86aaf7df54e79f43355d6be50d55daab4addaaabae4c58e7a977f3b1cc2" deposit_count: 160 execution_block_hash: "0xb6bbba5e6a9fd9d2972588347d65cfc8633717b19e2c059aeae1c55f790b6ea0" execution_block_height: 161 - deposit_data: pubkey: "0xb249899bfe2b0b123c7a151b5041d5e994c57568a6b427e38b25f2ef04ef0c30b4577e66fa7b499ef14d8d24563ef06e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8ea309386ac878fe5d5b3e6c4dadd85302bc9432ceeb7ddaa95ec3414d7f2cccd0792606dd481c49dd4f1d3455847b9b0e07bc4726118afe68116701d4641e0ecf9caf7be829cd0dcb7651801c9bc0ad18b7592b5f95012802f1e7b14e9cdefd" deposit_data_root: "0xe3149b68de3b804bb8ecdfaf36696dd76fcb801e7e47142e5beafd06b8c96c31" eth1_data: deposit_root: "0xaee25dee2d482203030ad50d3f0731d4b215bf84f1c60b875e88e19125482a75" deposit_count: "161" block_hash: "0x13c72c657d79ba0f34266ace9d2e195cfb91257db5853010df831bde22774d4a" block_height: 162 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0xe3149b68de3b804bb8ecdfaf36696dd76fcb801e7e47142e5beafd06b8c96c31" deposit_root: "0xaee25dee2d482203030ad50d3f0731d4b215bf84f1c60b875e88e19125482a75" deposit_count: 161 execution_block_hash: "0x13c72c657d79ba0f34266ace9d2e195cfb91257db5853010df831bde22774d4a" execution_block_height: 162 - deposit_data: pubkey: "0x965ce54aa0e435602fe222441ea4ac7b227948ea37e927f9816d89d779dbeba426dc68ba6829ab8da33a565a6b879c65" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb0352350082b57df3eb8cacc48bd3e999a1b2719ef218cb2a5189291e0234f4678b21b037392c37b724ff82a6a42727b103809bea4cc34cf9c8f86675d0a40adbf65b467e9128358802e0079a0cdb100b9206a4475b97e7129272a8c36e51b9c" deposit_data_root: "0x8b1968fceaf4e3214998a64db92e35e11a383ca34a1e8d37a4f07588debb444c" eth1_data: deposit_root: "0x81cbc850d30b5486ca44fc0f2368100fa3673575e87fb5635485fbd553ceb59a" deposit_count: "162" block_hash: "0x95088152d0c1114f167cb7b65078019b8bd5f2023e889e18c201c0bf6cca138c" block_height: 163 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x2e6b570d265740ee405e8ebdf6c5e228efe005294f62cf1af23affc7b72a38e6" deposit_root: "0x81cbc850d30b5486ca44fc0f2368100fa3673575e87fb5635485fbd553ceb59a" deposit_count: 162 execution_block_hash: "0x95088152d0c1114f167cb7b65078019b8bd5f2023e889e18c201c0bf6cca138c" execution_block_height: 163 - deposit_data: pubkey: "0xaea84e54336d09257061a8b23f419438c2e3d2659de36b993033bb30e396d9c9ee8b6f1b66261a6a060c3ab706827afb" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x82804e80f3e381cec665c1f51b1015500a0eb2b35085c1b1365156e4fbb5ab82d7d4af7af12e8cfc2a73026e6aa8e3440cc9babfa8480efd255b15f1097fc8a2283d76b02f225a1d7105e44f9daffe9794208e97bbb19907dd83a0608095c127" deposit_data_root: "0xe374e9bd5c51394fcdc6852e98614127fe095a5192cf53d340cf519bf20cfb59" eth1_data: deposit_root: "0xdcd46c40bcbbde1ad6887dc6099f6109980c4dd6bb67d03e7534dd7d87038867" deposit_count: "163" block_hash: "0xdbc232ce7aff4b99b9ae5e05a47ef313d62affb1f08328157161c00a218575b2" block_height: 164 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x2e6b570d265740ee405e8ebdf6c5e228efe005294f62cf1af23affc7b72a38e6" - "0xe374e9bd5c51394fcdc6852e98614127fe095a5192cf53d340cf519bf20cfb59" deposit_root: "0xdcd46c40bcbbde1ad6887dc6099f6109980c4dd6bb67d03e7534dd7d87038867" deposit_count: 163 execution_block_hash: "0xdbc232ce7aff4b99b9ae5e05a47ef313d62affb1f08328157161c00a218575b2" execution_block_height: 164 - deposit_data: pubkey: "0xa90dfa8114a00b3fde7cdddfb2fab9a6d113500aee32f08786634bc5c99ccd7730417e4ae4a05299b62342c1ab98ada3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x993aaf734e6ea9848eb8b581d8349a780dcd2689bd341c984ed7f291efb035c1bb6a7be47bd9904aeb1d9bc595596b670b011d2e36bf1b4a1e3f83bd87ee5d1a2b8e10d93825bdafe498155fa3b39cd1d929e858e14cae16dccac990a918b407" deposit_data_root: "0x7b4c8cd4bdd1696c9acee551bc67972ee101a70a05d7e80e327867bf9c2cca75" eth1_data: deposit_root: "0xcbe12098660ef62edb564991133409b98044b1f3e79ad49c9b26a29d990694ff" deposit_count: "164" block_hash: "0xe2797260931e52abe1abde79d64ef6760785f83401180a0799ef7688f4118150" block_height: 165 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x582e9a6fd990c0d996070550f2ed7e8e8cd420dd85740a5a6e53f4f0c300d47c" deposit_root: "0xcbe12098660ef62edb564991133409b98044b1f3e79ad49c9b26a29d990694ff" deposit_count: 164 execution_block_hash: "0xe2797260931e52abe1abde79d64ef6760785f83401180a0799ef7688f4118150" execution_block_height: 165 - deposit_data: pubkey: "0x9346419f620830d6535546fe2ddd827b69156ea9c29194780c63a8f07b6fdcb0568282914ce3cc06a2ba44e2ee1a6e9e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb243d10f9864d3abcc933b7ca0cdb2e40fa08a1631ecb702c41dab1113f0e689677ba1e8b078618989b65548103adc5d0d7531c102f22f4d502504c64148b8aded9cf314ea6d8336b5f36329e90f79298efe0d48fe6f84647dbf3952247b1f93" deposit_data_root: "0x9843715212db9556a5ae4aebc9cd03db21467bdb82a6b0b7c8aad1e03e7c0db9" eth1_data: deposit_root: "0x62657a90eb6dda61c00c5b33dca2b652a03fba9f0aa4090c0711418945d8444e" deposit_count: "165" block_hash: "0x8090b1b61be967d73abea99aabd3a2df3ea098eee99126ff117aa1e3b0581543" block_height: 166 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x582e9a6fd990c0d996070550f2ed7e8e8cd420dd85740a5a6e53f4f0c300d47c" - "0x9843715212db9556a5ae4aebc9cd03db21467bdb82a6b0b7c8aad1e03e7c0db9" deposit_root: "0x62657a90eb6dda61c00c5b33dca2b652a03fba9f0aa4090c0711418945d8444e" deposit_count: 165 execution_block_hash: "0x8090b1b61be967d73abea99aabd3a2df3ea098eee99126ff117aa1e3b0581543" execution_block_height: 166 - deposit_data: pubkey: "0xa399755dad117a369409206196a9e3a1637a625dc22d0da18583827dbc487ab9a2ba6c995927df9d8560e07860ae8b0f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa6f0fc1f51494308f876cb2391f625009d4761871c69af305712751e35cf0f3c026e06c159e3c82988b9f97fff4d1d99078f3bd6c8b7d3d308e36eae49ac1b79ace6e04656b0fcd3d8daaf2ce6333c0ec0ca998ce3c08ea86e73fda1c8d25bbd" deposit_data_root: "0x4e25083e3dccff55e85eaef37ccc737c720ecc898a98e8ca0c52b897431a315a" eth1_data: deposit_root: "0x4619beded7d11311791dcef425b8027ea14e383d8c2cd5c742879c134637ee91" deposit_count: "166" block_hash: "0x3c684054459e115db8518ed799e879a579a049bc9994c1727e568d3e9dbe2767" block_height: 167 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x582e9a6fd990c0d996070550f2ed7e8e8cd420dd85740a5a6e53f4f0c300d47c" - "0xd9c72e2b3770f12ee0e9f7d83243ab36680e0b9483eaf7a537848aae96531edd" deposit_root: "0x4619beded7d11311791dcef425b8027ea14e383d8c2cd5c742879c134637ee91" deposit_count: 166 execution_block_hash: "0x3c684054459e115db8518ed799e879a579a049bc9994c1727e568d3e9dbe2767" execution_block_height: 167 - deposit_data: pubkey: "0xa4695dc25f6cd20e48edd948321a09ebe2884b1d6ebf622aa02a023e96f9a1d365be7f2c6668444b347aee678fc7bc5d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x93375360b97a238600161ddf1096b86637d2bb9cf4453450804fca3b16bbc74e1aac6d9a9ece486250461b0492a68470164b8f779c6eb89f59233ec304af5cf3f76d4d5ad6508599bf569927eb97096f422051e33c4137df737eb4db9a4e421b" deposit_data_root: "0x468fd4b82322e73a7470baa353b8931947a2bf6fe3cb62cb1b0f126973a2df1a" eth1_data: deposit_root: "0xb2d04fea4f590b0f56e5a7fa576d4b2cd2d88b99c09dccb2b4aa560eb0885c9b" deposit_count: "167" block_hash: "0x06c9e6315169cf6fbbb198a180cc67111550846dcc2b78e2265dbcb5d29b17f3" block_height: 168 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x582e9a6fd990c0d996070550f2ed7e8e8cd420dd85740a5a6e53f4f0c300d47c" - "0xd9c72e2b3770f12ee0e9f7d83243ab36680e0b9483eaf7a537848aae96531edd" - "0x468fd4b82322e73a7470baa353b8931947a2bf6fe3cb62cb1b0f126973a2df1a" deposit_root: "0xb2d04fea4f590b0f56e5a7fa576d4b2cd2d88b99c09dccb2b4aa560eb0885c9b" deposit_count: 167 execution_block_hash: "0x06c9e6315169cf6fbbb198a180cc67111550846dcc2b78e2265dbcb5d29b17f3" execution_block_height: 168 - deposit_data: pubkey: "0xa8c0966a8c0869e28110ea5587321cb26af1bc49591fdaab24b37c77feed399439515d2aca8f2483a3d666be8b4eeef5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xace818afa05a123b98626d805d1b747f09b1d2e41c826b607da97cd28c41ca78d2514e2d4e4a0a1a98cb6034a1ace05f033e4091dfbe40eb7eb6943b682c7ed8b26b8a68f731f908ca7c18f5f8568a1c39648bb94870066275245e42e44ecd03" deposit_data_root: "0x9dae7719d40b642b28d8de5358c902e0e7b6dcddeb88a29cc2583600c15ad2eb" eth1_data: deposit_root: "0x847f32ad10d7b3de3275fc8a8730008ec5f12a89142209a4ba63c8cbdb022ea3" deposit_count: "168" block_hash: "0x619b700d81b9b1216b6b9ff1f0eb4f7b11c4ffd3c4cf781af2a9cd47ef42a7e5" block_height: 169 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" deposit_root: "0x847f32ad10d7b3de3275fc8a8730008ec5f12a89142209a4ba63c8cbdb022ea3" deposit_count: 168 execution_block_hash: "0x619b700d81b9b1216b6b9ff1f0eb4f7b11c4ffd3c4cf781af2a9cd47ef42a7e5" execution_block_height: 169 - deposit_data: pubkey: "0xb210d799f2cc4d87df36b60fe1d7408d9e4b5124aeed740eb42227dc1f456d9e13bcecf309e068f9775996c71b55ca8d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa59636627fd11a272aac90b9ae21cbe3156c8e347f34c6a92d6078f1a130864026c4fd8149df5c0808c9d8be6e7257960c627011fa459fed2d513ac91bc10ef3858e27ea6b88aa3d1f566ada6075daf2f3306fed983353dc6593375f9a2af410" deposit_data_root: "0xd2ff2f73a25e4c4de82d2bc2f1fe937bdaecc03fddfb5f971df8c65a6fd9d93f" eth1_data: deposit_root: "0x7e03a31121d9081c87abc7e9789a6ba49abf30fa5e5b0e2245cd75c76869ad5a" deposit_count: "169" block_hash: "0x307cdbb86ebbce74ab00d13e63aaf58c789c1fe21b037234c2798cf2e44ac41b" block_height: 170 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" - "0xd2ff2f73a25e4c4de82d2bc2f1fe937bdaecc03fddfb5f971df8c65a6fd9d93f" deposit_root: "0x7e03a31121d9081c87abc7e9789a6ba49abf30fa5e5b0e2245cd75c76869ad5a" deposit_count: 169 execution_block_hash: "0x307cdbb86ebbce74ab00d13e63aaf58c789c1fe21b037234c2798cf2e44ac41b" execution_block_height: 170 - deposit_data: pubkey: "0x83af2f04a869d856df934893edd7f15dae94ef74d78139e0556e1166e81f8ab2c294708af67f194e854946f2da4e87da" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x944859b17259fedb50e94bf3fbee57b0d5c7f43401fb611258a599696f24d94622a71d179d540fb83b475122c406c85113f84ba8684096c38accf6d171ae2abefb725a638207dd12d12099a7bdeddb832a05f4707797d724deea9570679dab0e" deposit_data_root: "0x9aad59fe2860067c1859e09c5a0cbd41a482389f2457b3ddf246b065d2b797e5" eth1_data: deposit_root: "0x0507a6d86c34e8fb6f2e644d93bea484d395eb00f747aa4185e15e67741708f8" deposit_count: "170" block_hash: "0x4840cbf1750adce5ef26a3b6e0251a60f5998a1bb4109a3918410e2f459edd2c" block_height: 171 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" - "0x0243f87cc01998a622e06a46d90ff0e2c2f4e0457b4e0c418a13a3183743df4e" deposit_root: "0x0507a6d86c34e8fb6f2e644d93bea484d395eb00f747aa4185e15e67741708f8" deposit_count: 170 execution_block_hash: "0x4840cbf1750adce5ef26a3b6e0251a60f5998a1bb4109a3918410e2f459edd2c" execution_block_height: 171 - deposit_data: pubkey: "0xad69af5d2ee0d68b32e6c4ebafc348a0c509aeed7e4f5c24c236dad4a8f91129cb9f8ee521de07c8199807e36e6a84f9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8a8c6e627da5d712418638f0a31f9671f753d44f5b9439ba0ebacd3a4cfbe41b6ec1c75eb70e0e57bc3535409e7f949f01dbafa227b0b87d44ebc5dd63083e3848b36f4b1821f0f3c1ff2a9878c5ba2cdcc16e39b01e0f4a924aa8c14278c447" deposit_data_root: "0x41deea4572826ab6dba52032eeabd9996d80e3a5725ebba8a8a20726fd16d10a" eth1_data: deposit_root: "0x73170edf9923bea7b1203c4701f3023cb42ab5a8c15e7a5310fdae89f49a10e8" deposit_count: "171" block_hash: "0x409571a87e6260ebf8a4b04e70a01d1276eb29c3ea26ec4f85561f1b15089ea6" block_height: 172 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" - "0x0243f87cc01998a622e06a46d90ff0e2c2f4e0457b4e0c418a13a3183743df4e" - "0x41deea4572826ab6dba52032eeabd9996d80e3a5725ebba8a8a20726fd16d10a" deposit_root: "0x73170edf9923bea7b1203c4701f3023cb42ab5a8c15e7a5310fdae89f49a10e8" deposit_count: 171 execution_block_hash: "0x409571a87e6260ebf8a4b04e70a01d1276eb29c3ea26ec4f85561f1b15089ea6" execution_block_height: 172 - deposit_data: pubkey: "0x93568c9c40bb362329367dfc26a65567481a03c35fcaab51f781c9f364b7e676cfc3d2c08633888b29715a6731dfb6b0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8afaca7a98ed1bbe7d5ad827d9dfb25e22983515a8cb7bbf9660b8bc965dbd22cddcf301be0b8ea07773716cd6bb40c0939ee4236b1048b327b51dc56eeec3333296519c33ba8b42671c2e64941d3c0274204eff17c255729a6ff036dca11d2" deposit_data_root: "0x3ce86437d73f789ed89cc006c250d5ae9ebe44e25ce3df3b8a87c511f3252ab3" eth1_data: deposit_root: "0x5f0c1f7e6a02232a6a1d7aa1c7a94f9d46700a5715138165282542665559fe6a" deposit_count: "172" block_hash: "0x4f2e4afd489e40fdb8ecfe276f4a028e550ae9f2224c29aff14670bff6732ac1" block_height: 173 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" - "0x6706f41e298f5bf853c88ba459952003db6fa9dd7a4c36b72fdca4b7d831d42f" deposit_root: "0x5f0c1f7e6a02232a6a1d7aa1c7a94f9d46700a5715138165282542665559fe6a" deposit_count: 172 execution_block_hash: "0x4f2e4afd489e40fdb8ecfe276f4a028e550ae9f2224c29aff14670bff6732ac1" execution_block_height: 173 - deposit_data: pubkey: "0x8509086b192c039cc84d145fd6a2b2cc3e3a3d46092e928cc1ca9a66dd663550a2782ab32d677785e02c23b6637df70d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9055741c269436e5cb5eb9560441a9dd62dc3605913b6b83b207e49eb2c9f3837b2c877c8e937ce326ddfda973a031920f60331a5eaadc52555cf37c6a0216ca8ac3ba965a2c0060b1b9729472e977a5fd23b23c0a39286b849a7ee22d76fe5e" deposit_data_root: "0xc9ca71afaa9631f5c9645212720807c19c302df3a5911504c49fc87f78011862" eth1_data: deposit_root: "0xda5ea898120a262741057304c7596b6a34af9ca93abc2a162c738cbf30613c57" deposit_count: "173" block_hash: "0xd53d21964f2af07692e1fa7c1886d583dd28693ea39b391d4ebb18e603d0ecb2" block_height: 174 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" - "0x6706f41e298f5bf853c88ba459952003db6fa9dd7a4c36b72fdca4b7d831d42f" - "0xc9ca71afaa9631f5c9645212720807c19c302df3a5911504c49fc87f78011862" deposit_root: "0xda5ea898120a262741057304c7596b6a34af9ca93abc2a162c738cbf30613c57" deposit_count: 173 execution_block_hash: "0xd53d21964f2af07692e1fa7c1886d583dd28693ea39b391d4ebb18e603d0ecb2" execution_block_height: 174 - deposit_data: pubkey: "0x89494e98d8cc4c763b3b138e21d6cc1c86f7eeb69315cf6a4b8b5b7018dd59e3b82c0b7c785a381ffd1b809e5bbf4625" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa937d3c9c04bf31b388af13d98636e1339e5e9cf3d8dfe50dff7722be110fb42e68efd406af92b5e3c0ed4f73959c89502c84a8ef20410120d5344b7441872686652f642ccc7b2d944e3a6937670e166795535e65fc66204fbc61a9e846a9950" deposit_data_root: "0x000a7e1720ce430ce6344f7add0f7e4b43ca5ca57be2a8efbf63c0746787cea2" eth1_data: deposit_root: "0xb349cf11fad3f0efcc1b018ea084cc30ff6ce11e8c13ff066a548ca67bb03906" deposit_count: "174" block_hash: "0x446efd92f90c3861d7acb8deccea5b7c28036a54dd441584508a5c8a52f905c2" block_height: 175 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" - "0x6706f41e298f5bf853c88ba459952003db6fa9dd7a4c36b72fdca4b7d831d42f" - "0xdc8f10386657c08bb0d17aba01f7647252ad4c6db5a36fe938283fe819b0c9d0" deposit_root: "0xb349cf11fad3f0efcc1b018ea084cc30ff6ce11e8c13ff066a548ca67bb03906" deposit_count: 174 execution_block_hash: "0x446efd92f90c3861d7acb8deccea5b7c28036a54dd441584508a5c8a52f905c2" execution_block_height: 175 - deposit_data: pubkey: "0x8451860d32c95e30f685cf31fccb967b0cd172566ff7b7d2c5ff35130bd1232cb1a216c9f0cd355ad69a93469b78e8ba" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaaeaad75e6abb6123819f1f01b636a91f85f28c38fe57833e38e555f0a78546a151c02dad44fce569eb89212879c381c18a516d9256ca79afde66a5fc334005b470dd2e3d704248cd7f61203ede9fffe343dfbd0b55f0a24b1c832be7ae68cd6" deposit_data_root: "0x38d3cf596f6aff5b5603a02e0cab7770a129d72499ec88ae2cf89bf01ba15b8a" eth1_data: deposit_root: "0xa927a1cd6a0fd5bfcbdc12921e8197df198e82b0fd4ec52051885184f7105703" deposit_count: "175" block_hash: "0xbce83de010f32cd9de9e1af87710aa65227fb59b04ae6825ffe42bbca51ad8fe" block_height: 176 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x51ed246dd0a98ad17d95eb60d315ce5433d7a022cd5db0a6d4f1be5b3bbae2c1" - "0x6706f41e298f5bf853c88ba459952003db6fa9dd7a4c36b72fdca4b7d831d42f" - "0xdc8f10386657c08bb0d17aba01f7647252ad4c6db5a36fe938283fe819b0c9d0" - "0x38d3cf596f6aff5b5603a02e0cab7770a129d72499ec88ae2cf89bf01ba15b8a" deposit_root: "0xa927a1cd6a0fd5bfcbdc12921e8197df198e82b0fd4ec52051885184f7105703" deposit_count: 175 execution_block_hash: "0xbce83de010f32cd9de9e1af87710aa65227fb59b04ae6825ffe42bbca51ad8fe" execution_block_height: 176 - deposit_data: pubkey: "0xb48c495c19082d892f38227bced89f7199f4e9b642bf94c7f2f1ccf29c0e6a6f54d653002513aa7cd3b56c88368797ec" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xab221d4174ca55a27aa072b675ee700d63edd048d4f417b79bce310c3bc3f5aa214eca529c4624accb014bad5d1f79e50ea67c82e4b3daea65dda4de263c0131eff1ab811e5716eca36bc2409495ae2795abbeb161311df4a3289cf1aff624e8" deposit_data_root: "0x960ceb47ae45f726f760f1a6e4c501a1e539f332f3cfad2dcd22be596fc8c126" eth1_data: deposit_root: "0xe95f5528ca45a8860a620ea21eda926f6f153cbaaa6b9324ae5ea82aff8dc2b3" deposit_count: "176" block_hash: "0x3f7e984a3ba436e0ed8fbfdb1bca8308e6ec5b1060400a1c5156af6ef110bc5d" block_height: 177 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" deposit_root: "0xe95f5528ca45a8860a620ea21eda926f6f153cbaaa6b9324ae5ea82aff8dc2b3" deposit_count: 176 execution_block_hash: "0x3f7e984a3ba436e0ed8fbfdb1bca8308e6ec5b1060400a1c5156af6ef110bc5d" execution_block_height: 177 - deposit_data: pubkey: "0x8bd22839c85ec58af4303cde58674394247fbe1f51b4e30ebcdf86aa861ebef2ac9239aa21bd9b07fd03f28dc4806780" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x81fb9baf8c52a4888566448ed653d4e199b40bbf4053c34ea0105554f96a4dd245df81a2ed37e900b73ac954c7001f7009a2240737f034d9e4ca6874f3913d06efbfc2eea789f86ad5a353b37b755ba73aae5dcb5f3f44fb155410807d44bbc0" deposit_data_root: "0xfe4956baff4bc251951ba1c955db9f46821ab844d6a031ef7db7b68de6959856" eth1_data: deposit_root: "0x76342485c471517c60dce8cf762fffbf3f06f93202e98682c7078618c4eb0e88" deposit_count: "177" block_hash: "0x66c1f5247e10372a47af81e6e30ffdccc3f0d64f7fde478420394289c435dec7" block_height: 178 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xfe4956baff4bc251951ba1c955db9f46821ab844d6a031ef7db7b68de6959856" deposit_root: "0x76342485c471517c60dce8cf762fffbf3f06f93202e98682c7078618c4eb0e88" deposit_count: 177 execution_block_hash: "0x66c1f5247e10372a47af81e6e30ffdccc3f0d64f7fde478420394289c435dec7" execution_block_height: 178 - deposit_data: pubkey: "0xaace874118a4ea9cfec8d7979dbb4618f4833dde4cfc493a403ee5cedb67f294bcac4aaa2d626ff25f4fc7ee9fa61401" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x859e833217c0fd90fc641745e75e0d100d6b3cdfc1fc98dcd92dd0838a22c3bb3508ffbfc41662ec93134881f4a75a7d01661c1eb91d302c8ad28463703fa445276f9a7ce810a0fe475e18631ba1b81084f2b0c65008b37eccffbc01eca98143" deposit_data_root: "0x2325c1ee7ee609107dc5df1c7445e7d02a00e48798fe06f73e48705e0357e8b4" eth1_data: deposit_root: "0x95111c86ff2b172022650c8d000331c7c57d98b2f330aa9bd6bd417f94547739" deposit_count: "178" block_hash: "0x0c95d8c50c7fa3299c3ffd7ac683ef683fc907c39997b8b606bc8210c71c1b9b" block_height: 179 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0x452e7913b4f3ad6bc209cce6fc61588821ad6494282520a51e00926d913aac94" deposit_root: "0x95111c86ff2b172022650c8d000331c7c57d98b2f330aa9bd6bd417f94547739" deposit_count: 178 execution_block_hash: "0x0c95d8c50c7fa3299c3ffd7ac683ef683fc907c39997b8b606bc8210c71c1b9b" execution_block_height: 179 - deposit_data: pubkey: "0x956851460cb809871966cc4dd44d0b58dc68a1c22110864f374cd3aca743ee63b0743999d35b473e3f95ea38a276eaea" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa22edc0fab4e7099060fb062f9ac88bc08e2903dba9c9243dae581b169e91a3a8a823fe5a429d0d459d6499fd70c1c240d33cd4f5d7053ba9278234fbced8df69ed82849f3fd8510658918a00720c80d8453044bad1c4bdbdb20ca5ff75ffa5f" deposit_data_root: "0x9567c1a847009105673244cbcccff11184117f0b3e465f48e1771ead7976779b" eth1_data: deposit_root: "0x358b5a17f9a64b0a891cf6741ceebd0b615dfb89490550c9b601551d13781068" deposit_count: "179" block_hash: "0xd6917e5c5a35c21ea97cb5bd1f9070427106bf4980bb247d8a25fed86a6d09cb" block_height: 180 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0x452e7913b4f3ad6bc209cce6fc61588821ad6494282520a51e00926d913aac94" - "0x9567c1a847009105673244cbcccff11184117f0b3e465f48e1771ead7976779b" deposit_root: "0x358b5a17f9a64b0a891cf6741ceebd0b615dfb89490550c9b601551d13781068" deposit_count: 179 execution_block_hash: "0xd6917e5c5a35c21ea97cb5bd1f9070427106bf4980bb247d8a25fed86a6d09cb" execution_block_height: 180 - deposit_data: pubkey: "0xb8cd27d87c94a69cecd953999908640b437f6215ddae069a1ad403f995dfde6e4ac46e5c85fdd8bd4fa655f74cc2bc80" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x986d671909e02d5efe0689ec87b8add58331b963e14b4ed9d989b586f1bbd1c5f119360e1bff27fe64e598601545c52d08386c175a1fff8acf5f6760d12acfb51027523ae9e7afd69ff4db75a1e580904ecf93a22da7ef83c5cbf08f92bc85cd" deposit_data_root: "0x9c0182b4b9d2a650eee485c0a5b6c743d4377dfb2dad1094972ecb50271f65a6" eth1_data: deposit_root: "0xfa89ade12d8c6d2a1d9800b7bb254622b424c40067e2b0b9e569bab078c024e6" deposit_count: "180" block_hash: "0x6c27c6e514081d3f51296640528a1da12d22a3462cb44810dad190c782f7cbde" block_height: 181 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0x2d162bc4799fcfca576dc1ddf85c96c62bf3506922863de03d99b21d5d57b1fc" deposit_root: "0xfa89ade12d8c6d2a1d9800b7bb254622b424c40067e2b0b9e569bab078c024e6" deposit_count: 180 execution_block_hash: "0x6c27c6e514081d3f51296640528a1da12d22a3462cb44810dad190c782f7cbde" execution_block_height: 181 - deposit_data: pubkey: "0xae37d415dda04db4f1abcf52c080c1c7a1921a819181161c4c2c18f809cdcf695de3f0f793c78802bacc1f4a32bd921a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x97d0c9476aeb800a3e27f0b60f371679789e6bb03919bd65503eea6ee138275da5ea35f8a21352d68f1e5cde6be870d50c5356047cca0a2f043d83acfe44d3732e19f2aa54e844ccc57bb72b2061b00100cd28593eeab5601f35a594a2e82a98" deposit_data_root: "0x0da07a675920dd21e72440e13ac21d1d8d9864c92db43ffbb3bb100d6d112923" eth1_data: deposit_root: "0x46cb3dd3672791d77dadce6782dff84a88f34d594a9dd8441473f26bbff0e3fb" deposit_count: "181" block_hash: "0x7e23db8c0087f9044534d05457249a8f3bf7d50496eb005325709a44bc102b32" block_height: 182 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0x2d162bc4799fcfca576dc1ddf85c96c62bf3506922863de03d99b21d5d57b1fc" - "0x0da07a675920dd21e72440e13ac21d1d8d9864c92db43ffbb3bb100d6d112923" deposit_root: "0x46cb3dd3672791d77dadce6782dff84a88f34d594a9dd8441473f26bbff0e3fb" deposit_count: 181 execution_block_hash: "0x7e23db8c0087f9044534d05457249a8f3bf7d50496eb005325709a44bc102b32" execution_block_height: 182 - deposit_data: pubkey: "0xa7c674e6660a1930c546b4a7e345265a51527fbd53327f90cf7edce01ec2a9c9470c9d9f0a2e4dcfe4c0c5df4382aafa" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9765a98cfa6c562e97d0d18e26d20649229ecc001700852fcebdc804c14ad8fd6a9e4169972e16c0abcc07912469267d0f62d285abb659530eaac69c14dbace530e4f3d37b89ff58242c534c1e87a993dd0e53e52151f0021a699827196ab3fb" deposit_data_root: "0x3c02d11665be2b3121a49de3fc627ae4d2728050be2857acab0ab6800d30702f" eth1_data: deposit_root: "0xc2bd6a75ddac26bebb1dedff17e01e7388ba0d1daacad735c06dadf4d1497ab8" deposit_count: "182" block_hash: "0x24b5eec3f6b3ca56fe7e893edabe438ac14e338fae43ac6ad28b231a79e66768" block_height: 183 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0x2d162bc4799fcfca576dc1ddf85c96c62bf3506922863de03d99b21d5d57b1fc" - "0x3a0f8fa7a03d6c1c8c53c26f944126d830c08b1cea4019c7980dc8d3cca5aeaf" deposit_root: "0xc2bd6a75ddac26bebb1dedff17e01e7388ba0d1daacad735c06dadf4d1497ab8" deposit_count: 182 execution_block_hash: "0x24b5eec3f6b3ca56fe7e893edabe438ac14e338fae43ac6ad28b231a79e66768" execution_block_height: 183 - deposit_data: pubkey: "0xb2c9669a6f3e64a5f8b37c210c88adb507ce396042921b1aefd5bf52a3089f0ab0b5695cddf9b1a1157fe5dd43558e54" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8602ae96ab5650a7e477de5f00e10cb53826e3a268d96dbc0bd925e7370ff3f3fa7258261eb75a58d74c4de64db6713d19293e04d0cab40c1bd0c4669a7dd87a2b6272b8dd3c8f6414290843a4fbb945638eaf09594d44f502e2da1229d0ec3b" deposit_data_root: "0x68d5efabced0e3a67465028e2e9786d3626da8f47164112799f6280044e1da6d" eth1_data: deposit_root: "0x0e02f967291a37a27493d09d2cd5b530d83b67accb29fa7378acb5294b878af2" deposit_count: "183" block_hash: "0x392303f20a0d6202e844fffb6ac069f6a9dbaaa3f4447a7997afc74f1a83ee13" block_height: 184 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0x2d162bc4799fcfca576dc1ddf85c96c62bf3506922863de03d99b21d5d57b1fc" - "0x3a0f8fa7a03d6c1c8c53c26f944126d830c08b1cea4019c7980dc8d3cca5aeaf" - "0x68d5efabced0e3a67465028e2e9786d3626da8f47164112799f6280044e1da6d" deposit_root: "0x0e02f967291a37a27493d09d2cd5b530d83b67accb29fa7378acb5294b878af2" deposit_count: 183 execution_block_hash: "0x392303f20a0d6202e844fffb6ac069f6a9dbaaa3f4447a7997afc74f1a83ee13" execution_block_height: 184 - deposit_data: pubkey: "0xb00c6d2cf271b167f17135bf7bd14b7df669194045eb6f09b9dec787c7b608dcd42613dab0f857fbfa3fb84792a3e63e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x81bf33d08664f53464ad3fffff9475069948094c54b61edba63fb435969b7e621f7349991d72b43c8dd1bc48f20ccf1800e20a812f9996e115e9a98c98024186c4ba49722dbe463ea6c1c897105f24f5f983b2bf911c3af59123e43edfffefc0" deposit_data_root: "0xe2a3b3697c4174b669c5c9c3ce72ee244719fad0e9f198234cc3a13b7afcf5ef" eth1_data: deposit_root: "0x35db931e35f47dd387ae57bba681831b91a6579f034a754e7df92a8616679861" deposit_count: "184" block_hash: "0xa3d47fe70c8d2099b59a84c9f42bbc91c5bffe370010d5e535657fa3a1c4c816" block_height: 185 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" deposit_root: "0x35db931e35f47dd387ae57bba681831b91a6579f034a754e7df92a8616679861" deposit_count: 184 execution_block_hash: "0xa3d47fe70c8d2099b59a84c9f42bbc91c5bffe370010d5e535657fa3a1c4c816" execution_block_height: 185 - deposit_data: pubkey: "0xa5e5e5af2ef8b65bf9b7575606f81e99d1fa645078544b0fcd4e0b506670e6a75504e6ba4001e6cec25632633d050276" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb05a3fcac399a997e7ada5181638bdd95668dbef59f2a62b9c45a85857a42afa5f885748f6d07ecdefcae45e736ec3b512a94bccd7be7bbaec688d9449f586ffb48a82f3c693d1248932d7b7026082ccd7c0a97aae7e714f39484614690abd72" deposit_data_root: "0x2c3e00b8923d7c7bba4859372c106c9aa052b00d19a1cd9fa3aedab4a5511741" eth1_data: deposit_root: "0x87e828349d121957dab0e13448ba28216514999e6dfff614978f171578e27e2b" deposit_count: "185" block_hash: "0xc2320a2fc8b6dd2243c3abcdde3847e2598ffb7aaf303ce46cb2416d8e3be4cb" block_height: 186 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" - "0x2c3e00b8923d7c7bba4859372c106c9aa052b00d19a1cd9fa3aedab4a5511741" deposit_root: "0x87e828349d121957dab0e13448ba28216514999e6dfff614978f171578e27e2b" deposit_count: 185 execution_block_hash: "0xc2320a2fc8b6dd2243c3abcdde3847e2598ffb7aaf303ce46cb2416d8e3be4cb" execution_block_height: 186 - deposit_data: pubkey: "0xb7ad21b3cc61c96c4ea90e81cb5a39836f114dc477bb63da54af20f60d42dffb99aac4ae12ecb70288b1d226ca7c2522" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x80714ff567371483af7418f8d43a7e4adfd10d8d464e3fad6f72ca3d981920aa58d71235f1ffc6296b89a8744b66b23519367b3f5691e4410ca3bd068d28d88b4fedfdd91ac4ebbfe5a176827576c3a7176d4bb04f28c854051354db197d4112" deposit_data_root: "0x56f3cf8c6f87ca6f6298746c6aebf716e8d2387075aa400a69746cc5dbc31815" eth1_data: deposit_root: "0x7ac99b76e5fc809c4327f6edf9142d7bc55e12c3f9089a53066ec41500dfb5a0" deposit_count: "186" block_hash: "0x92708be0274d0ac8798c19482761e0a59edeb96edaf6e5fc2c1588a3365394b0" block_height: 187 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" - "0x9856919205a162db29485432bba026c979f7d89cfce702fc09657632a7a4f14a" deposit_root: "0x7ac99b76e5fc809c4327f6edf9142d7bc55e12c3f9089a53066ec41500dfb5a0" deposit_count: 186 execution_block_hash: "0x92708be0274d0ac8798c19482761e0a59edeb96edaf6e5fc2c1588a3365394b0" execution_block_height: 187 - deposit_data: pubkey: "0xb3eea1ef03b3cd28709513f691d9b7aefcb9908efc7114e20e302598cc8dfcea02fd9423045f246112e4db1bdcfa9e14" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9576775970091bad8e182acfa971d69815b901f7818738490d7a94bf3b7fd5de9810aface9670ad6d4074295cd91c3fe073a989aaaf4143cdb6da3a0a6545e749cdbb914b38c9d3dddbcc5b57552ac5711f91fa2c59fe7ee52fca41c248dd7d4" deposit_data_root: "0x0fcd143f7e8ffc456987f9c887bb46743be683a31a84fbbfead37a6929f1d0be" eth1_data: deposit_root: "0x4a796a1cd10ad42e890c811c5261325c80df56afcfdb45b36ca98eca59d1cc1d" deposit_count: "187" block_hash: "0x8f679f6f3487c47c32be42dc94ca7d0bdad809ac30d9c8c38ad5010c046af1e1" block_height: 188 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" - "0x9856919205a162db29485432bba026c979f7d89cfce702fc09657632a7a4f14a" - "0x0fcd143f7e8ffc456987f9c887bb46743be683a31a84fbbfead37a6929f1d0be" deposit_root: "0x4a796a1cd10ad42e890c811c5261325c80df56afcfdb45b36ca98eca59d1cc1d" deposit_count: 187 execution_block_hash: "0x8f679f6f3487c47c32be42dc94ca7d0bdad809ac30d9c8c38ad5010c046af1e1" execution_block_height: 188 - deposit_data: pubkey: "0xb0f147fdb3e17379f4933c18e6dd3e3c9e9414ed5920ab029dc5907c01f671f664e4bfde8a4bcfa273a57daeb824f695" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xadcea3abcac1ad298bc1711dd9555c2f9802e83e406debfc65ba54af21f99d652f440ebcf584d55915905dc5608c8e8a03081a51dd172d8cb0d11739ed1d6ffc7e9c0100cc4c565cdf7ca8d287f121dc7892583490629aaa93d2da2b8cc57d8e" deposit_data_root: "0x35cb7c2582792d09b08d2b5da3edb333de2b9074576999f0bbb0891adf6fb9b1" eth1_data: deposit_root: "0xab52ed24e0e69808c8d21fb5ca3ad3ec64c02344b953dd830261b97e3d7356d5" deposit_count: "188" block_hash: "0xe762ae9acb10f13c7f8e344c9fef7ee760577fe56c516050e1921cfa41e339c1" block_height: 189 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" - "0x1ad4ff6de258418fe600f0c8dabec3d6665177e5929c3570071111e85c21a90c" deposit_root: "0xab52ed24e0e69808c8d21fb5ca3ad3ec64c02344b953dd830261b97e3d7356d5" deposit_count: 188 execution_block_hash: "0xe762ae9acb10f13c7f8e344c9fef7ee760577fe56c516050e1921cfa41e339c1" execution_block_height: 189 - deposit_data: pubkey: "0xae04fca0e06b256e03d4173d7f772e2106efe6f72d469243dba695179b5d2be8b61052c2844247ce49ec3b6cfd18c73d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb32e41533c45bff774de491d8b06cf576a27225dcd8b7713e980a7f61eb6bd4e53ba34484c0e061e38448e4bd4859868172fd3f4da5ebedcc4cb322f675ace60d7272cef4e7c27afaf8aa6f46d2b575bc14208ce19c6d1a29e759b883d70f590" deposit_data_root: "0x9426eb1a7383fe76d2759e9482e7cb6aca0b0b7afe88bde72a55c4a1c54d56b1" eth1_data: deposit_root: "0xe4ac94ad06eaff8884701227e53fc6cc79a3471f92bd7891f31432c1ad4b1e6d" deposit_count: "189" block_hash: "0x167dbceea97680bfd280469520320efcef8881d4f735bbee384fd13f0b8b6d48" block_height: 190 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" - "0x1ad4ff6de258418fe600f0c8dabec3d6665177e5929c3570071111e85c21a90c" - "0x9426eb1a7383fe76d2759e9482e7cb6aca0b0b7afe88bde72a55c4a1c54d56b1" deposit_root: "0xe4ac94ad06eaff8884701227e53fc6cc79a3471f92bd7891f31432c1ad4b1e6d" deposit_count: 189 execution_block_hash: "0x167dbceea97680bfd280469520320efcef8881d4f735bbee384fd13f0b8b6d48" execution_block_height: 190 - deposit_data: pubkey: "0x98c4e0f20616fa174bb221011e731650cb841ec29305f074fdafbed1d04b761c107a854722d4a6d69d6a15f7bf85c7d0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x974f103ca1b3e597a8edb9ddc0a26388902a3d016d25322bbbd3f8160117472cf6a8642f9ba00b40a364463e2598226607ddd490c88f48878dfe288bfd1eafeb1216d7702b80180afce9c3c891fb566795a6cf7a29ebabbcd729e735ae999c15" deposit_data_root: "0xa35b4a77af8ce0b6db5f6d71cfea7feae8cb334d1d8bf25b954c9c5e46ca812b" eth1_data: deposit_root: "0x3f7a7f8f15b24ce7b68da0583b9a3ea05e4eb68a97db64aecaf1be63dda51842" deposit_count: "190" block_hash: "0xc6adc26aa6328f1ba0efacfa64978e016f0cb79732f8d0030e5c5a908cde788f" block_height: 191 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" - "0x1ad4ff6de258418fe600f0c8dabec3d6665177e5929c3570071111e85c21a90c" - "0xd3cdd6fba6102cf506ca28a01aff74996a181dadaa9bf9819ff0fbffa9461e53" deposit_root: "0x3f7a7f8f15b24ce7b68da0583b9a3ea05e4eb68a97db64aecaf1be63dda51842" deposit_count: 190 execution_block_hash: "0xc6adc26aa6328f1ba0efacfa64978e016f0cb79732f8d0030e5c5a908cde788f" execution_block_height: 191 - deposit_data: pubkey: "0x8800aa633b5ab60ea1da84e04e4a2fe6fb19c1d90197791ae6212e5349d306ff58afe02d4dfad739b07171ab5757d26b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x98f03706cdb826e0909662f03081bd021f6c9e45eee0ca23ee0d99af23b1aee1b89f7f416a54ec69060f8ae12e28da4411cb16e3395d670c2ec8391e334a7de5691c5b2580f60929ec0c6b3cbefd4c98af66fbe609461338aced45e3e78b7c6a" deposit_data_root: "0xe0b69fa6a6be23e2f39b421d4f53ca95608f755be6f1e6f3cd131e4845a9557e" eth1_data: deposit_root: "0x3f9f9fcb0d2dddda55497b58cadb8ea93f1f3b741656a4849bb7fb0fa6722521" deposit_count: "191" block_hash: "0xc5f1e8d399f145ef92628f2d687619db3d5981fbf51dae54ff28b1f6641dce22" block_height: 192 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0x01a4a7e7ce6c883eaa125ca6fd50f1342b9d35c305634bf843d7a609cc8b36f8" - "0x3bdcdb12a251d536acdb1af1c54acb37cd882c8fefa579587efd7828584f5422" - "0xc81cb8f54677d5a3e4f8f079429f97cf7ea6fb35b82afc3d691763085cb8c78e" - "0x1ad4ff6de258418fe600f0c8dabec3d6665177e5929c3570071111e85c21a90c" - "0xd3cdd6fba6102cf506ca28a01aff74996a181dadaa9bf9819ff0fbffa9461e53" - "0xe0b69fa6a6be23e2f39b421d4f53ca95608f755be6f1e6f3cd131e4845a9557e" deposit_root: "0x3f9f9fcb0d2dddda55497b58cadb8ea93f1f3b741656a4849bb7fb0fa6722521" deposit_count: 191 execution_block_hash: "0xc5f1e8d399f145ef92628f2d687619db3d5981fbf51dae54ff28b1f6641dce22" execution_block_height: 192 - deposit_data: pubkey: "0x9474c26852bc2adfc52d093351dbf7ea822a2639d99db5b0d344e440e0ebbd1e856ae37daf3d91a05cf62f33342bd790" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x906782c06b770529831187f04df19f8c727112b36499e90e0ad918cfb44318fc0c3eb8e76184c0b5e40b088d93ff645a1903c216805754913fccff7f99c705fa735ef28f0343a7fc0f416bff0855368ab5d168e5b1a4002d149dddf9a7fbfe6c" deposit_data_root: "0x36a01af91aeb0f7858b003955815f552bdec183db519e9c8210c18560fdb8d1b" eth1_data: deposit_root: "0xa0fb785cecda8d27d5ce055f5cab99945fd8fb66281532c8d8b51e7596117bc0" deposit_count: "192" block_hash: "0x69d947eb6e6297a9449d82c807920062fc057f18e168cc0bc06bf5a89a8aa275" block_height: 193 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" deposit_root: "0xa0fb785cecda8d27d5ce055f5cab99945fd8fb66281532c8d8b51e7596117bc0" deposit_count: 192 execution_block_hash: "0x69d947eb6e6297a9449d82c807920062fc057f18e168cc0bc06bf5a89a8aa275" execution_block_height: 193 - deposit_data: pubkey: "0x86c82451f5ea5981c9031b3871e1463b10875934eda1c2520752d03bd51e71d943037b1a902979b6821eee7bd5779f78" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa9fe9f4af4705bda5e0ce2a369ebeef5ee8cde8cd9a66303e0f8100f282b23a5441a9c5be3c4ba6462d28117626fbdb6157951056078532b6e1717b5d5e44fc0839cefc1e34983900027caddcbffa2404014a35b16a3f6adf6cdcf35d8cdb396" deposit_data_root: "0x165cd78151e962dad0f4d9de56e66436d07d08beca179d0bf92a9b534791aab8" eth1_data: deposit_root: "0xc9fe80c8ecada066e8d0fdb2edec4b23b5f6d116bd65b980a9000c9fc251031e" deposit_count: "193" block_hash: "0xe2aade60b0fbbbad2f998e5badd1b8d3ced7fc0f7ec6f52ad7be45be91f38ec7" block_height: 194 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x165cd78151e962dad0f4d9de56e66436d07d08beca179d0bf92a9b534791aab8" deposit_root: "0xc9fe80c8ecada066e8d0fdb2edec4b23b5f6d116bd65b980a9000c9fc251031e" deposit_count: 193 execution_block_hash: "0xe2aade60b0fbbbad2f998e5badd1b8d3ced7fc0f7ec6f52ad7be45be91f38ec7" execution_block_height: 194 - deposit_data: pubkey: "0x864a08f5f022ce7757cb73be7ebf54e387fb3d5d4b0371d01ed493270be3236c5bc3b1272e42d2628f8f3c000d60eeaf" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x91b20dfe5a0f41fc5e8cb0b591faeed60ccf42c7d7ead8c17ba7075c6349bef80a3f263f175a57b6b3a4a1fc2ebb1a800d2f1c4f5d45713d1ee418fd903c01c168c507a01c207d182cfe012342bc0f57707a24c7c0df942e247540bb97fd824d" deposit_data_root: "0xdc1915b04568269a1f5dc65e91d8b380c104621822d27c6e4233a878ae0fef5e" eth1_data: deposit_root: "0x5f5a8158ce7e1a776c1b6187d70abb5f6676b608626c8d051abe7795c8435946" deposit_count: "194" block_hash: "0x32c72593ddc2739d5eae88440cee25dd36d46751816d1e6f8eed0ef30de97fcf" block_height: 195 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x735a400964fac7b2378423de5960b50eaa02589ac565a271de0129a009f66614" deposit_root: "0x5f5a8158ce7e1a776c1b6187d70abb5f6676b608626c8d051abe7795c8435946" deposit_count: 194 execution_block_hash: "0x32c72593ddc2739d5eae88440cee25dd36d46751816d1e6f8eed0ef30de97fcf" execution_block_height: 195 - deposit_data: pubkey: "0xa38e925dd3c45de24e8d73e9170168dc8206035ea711741d91a35c24fa71bb7981b89bdca545ee68e8680307a754e801" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x86bb5e37880c4338cf71f6e8712bb644c536d42369c715067ccbf57195781d66d6c321343cc2012d8384d22de7d1b1ff16d9cf7f6c4fbd3c0a5c78bfd15e3c88c3177d54b8967dba46627ab28f2ce2a0c7864d73364be3459fda509352129739" deposit_data_root: "0xf0715cc57042701d7d885798175984ad28a7034f132792da09509aa9df0ddc57" eth1_data: deposit_root: "0x2215ed2c63f505ac6fa32a11161d46f18db19bd56aed182298505b91366adb61" deposit_count: "195" block_hash: "0x04f7e15ab5591a7e1931772b057c38e3e385c6376d0e78dc0487be63de1d0ae9" block_height: 196 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x735a400964fac7b2378423de5960b50eaa02589ac565a271de0129a009f66614" - "0xf0715cc57042701d7d885798175984ad28a7034f132792da09509aa9df0ddc57" deposit_root: "0x2215ed2c63f505ac6fa32a11161d46f18db19bd56aed182298505b91366adb61" deposit_count: 195 execution_block_hash: "0x04f7e15ab5591a7e1931772b057c38e3e385c6376d0e78dc0487be63de1d0ae9" execution_block_height: 196 - deposit_data: pubkey: "0xa626ce67a47dea646ca21759fb026c6a258cc6ea8db330ee68cbd2455d1c347bbab51f3c08423eedecfa9e36920ef80e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaf63ef6fdc71c6e3adb00df9284be7862cd48ce1a48e8c46b8d2640f72de9a290e160ff1535277594ff03785112e245514287bda41fcde5e4f41099b651467c5e1e580ce2de799e2740a074386c99c7778ef7e4c2a945e40f6e553e152db4f1a" deposit_data_root: "0x11c9f14e452b20440a56ff34917760d8dcd5a8e630dc7287357181cd486facb8" eth1_data: deposit_root: "0x0fa3a4dc90fb01188e00d9df9f45687f0c8a947228db2d315bcf554f2f4244e0" deposit_count: "196" block_hash: "0x5c247a56ac7270505ea91e5701c596d8ca2ff96acc269238ad57898ec20b900e" block_height: 197 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x7a988bd4f4f2f44e82e3b09c2bfc32c9b2eeea372287b0222e2b1d9aaf4aa6d3" deposit_root: "0x0fa3a4dc90fb01188e00d9df9f45687f0c8a947228db2d315bcf554f2f4244e0" deposit_count: 196 execution_block_hash: "0x5c247a56ac7270505ea91e5701c596d8ca2ff96acc269238ad57898ec20b900e" execution_block_height: 197 - deposit_data: pubkey: "0xaae22c365554eb37e2f402f6e6e4bfb0aa9416d8dda0a2f8ea5647ba7dd32023089f4dcc111121e56b52b1fdc29067b3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2f3d0bd66262806b2e9d0683f26016d1b7aa719d3f2739b43516900f126fa7b05f45376bf968769bf9d23cc47124f961960c17f9ce4e1b8f32544aefcedb5711327128e0d54ab20c31c7e11bc6b16dc8360107276385a30180b225aaa3a5cce" deposit_data_root: "0xdcd3b1b400746a2b3933c4a326f05ae8eab21177b548c9a4b23991d67221db2b" eth1_data: deposit_root: "0xf0767d7bb07aac096d4fc126f24e653dae0ed20d2e78a537239aeb416bd9f61c" deposit_count: "197" block_hash: "0x9e2658d320b979325eaefb9a6bc7f8bb8d993ffe01dc5048a598f5532a2f7868" block_height: 198 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x7a988bd4f4f2f44e82e3b09c2bfc32c9b2eeea372287b0222e2b1d9aaf4aa6d3" - "0xdcd3b1b400746a2b3933c4a326f05ae8eab21177b548c9a4b23991d67221db2b" deposit_root: "0xf0767d7bb07aac096d4fc126f24e653dae0ed20d2e78a537239aeb416bd9f61c" deposit_count: 197 execution_block_hash: "0x9e2658d320b979325eaefb9a6bc7f8bb8d993ffe01dc5048a598f5532a2f7868" execution_block_height: 198 - deposit_data: pubkey: "0xa5c3572c3b770214c14beb4d403d00ffa981480eb850195c99f3b6a2418cef98df28b7f1543d48a2500bfbe25e18ad80" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c50c39e613fa154f1f7b0afd09e716982aa305d5b14fa151a387ecbf172ddb5072311ba32e850725bef0fbacd85fb701822a16e22c408af47500cc33b52c1f40c4ca15d2fb23b90da304e5d4c14ee828ba64556f0e3a4ba95b949ad0b050613" deposit_data_root: "0xd4386ba3269154bcebcf9be99f15c4a3c5cbb29f1233f4c8392610bf378bc7b1" eth1_data: deposit_root: "0xb900dfc08320f9c098a4eada49948bcd336be1f0b018ad9e741049dfb7b8ed93" deposit_count: "198" block_hash: "0xb7d727f382dcbb633b6354371ba93f697e4ee8974356879ad1e9071d041cab9e" block_height: 199 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x7a988bd4f4f2f44e82e3b09c2bfc32c9b2eeea372287b0222e2b1d9aaf4aa6d3" - "0xd6fd367da921cad3a94901ae5bd5b3cbc3dfd1462326a6d78aa556797d2a4637" deposit_root: "0xb900dfc08320f9c098a4eada49948bcd336be1f0b018ad9e741049dfb7b8ed93" deposit_count: 198 execution_block_hash: "0xb7d727f382dcbb633b6354371ba93f697e4ee8974356879ad1e9071d041cab9e" execution_block_height: 199 - deposit_data: pubkey: "0x8e793a86453b578e9b2f4c252e9ff18a8fb1af36fdd09d9144aea8e2b172738fde30faff3e9391d00827df5efb534821" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x80b57d9e5602fdf0ea42b3ed7eec2f69921264575bd8a63a685cb796db3eb8009bd89f080548ccf9982aca0e475990b90e89e0f2ee025eb3a28f3a928924e79025d6f123bfefc6739685068bb7c41d44c39101612cd65f779c64e9b94b3aae80" deposit_data_root: "0x705b49ff60a831179dc633062c11329e0fc800bffd91cd2162ee5f9824bd436d" eth1_data: deposit_root: "0x90211ebb48dc63aec0f43b619b9de255f716983c02de0f14a5b22e002cf8e2bd" deposit_count: "199" block_hash: "0x7889af3b1bec5acaba75ac39a3d3b9e95ca78aca797f305510409b9b468719c9" block_height: 200 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x7a988bd4f4f2f44e82e3b09c2bfc32c9b2eeea372287b0222e2b1d9aaf4aa6d3" - "0xd6fd367da921cad3a94901ae5bd5b3cbc3dfd1462326a6d78aa556797d2a4637" - "0x705b49ff60a831179dc633062c11329e0fc800bffd91cd2162ee5f9824bd436d" deposit_root: "0x90211ebb48dc63aec0f43b619b9de255f716983c02de0f14a5b22e002cf8e2bd" deposit_count: 199 execution_block_hash: "0x7889af3b1bec5acaba75ac39a3d3b9e95ca78aca797f305510409b9b468719c9" execution_block_height: 200 - deposit_data: pubkey: "0x969ca05ea6e49aa9b35d41c3354096f022e9a86718ac454cc8140419dd2ef5c19af37d42733a434a0e77970117ab884f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa809d95bf1d42854575411ce2e535ea3b3cb263c07dffb715044442b196cd701ab25c79a5ae2440783f447c542f518680bbf949ba63ebd1f67bdbe832731a70fcfc6c3b549d2b160239ac852b41b4bd2bd23c88328bcbc6a20590a3fdaa8a3c2" deposit_data_root: "0xb2150789ea91596d6a1e50fe9841761330fdb7d4a8ad45528f7646684d9cc52a" eth1_data: deposit_root: "0xad8875e0af2f6d20643e3670fe9b991c24f3c0fecc85a59a41fb25c0e791fa17" deposit_count: "200" block_hash: "0xe9365f98552e964ec79bc2c5d2b0c741b2579c9558480d9ffaa1ee1d3df642b2" block_height: 201 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" deposit_root: "0xad8875e0af2f6d20643e3670fe9b991c24f3c0fecc85a59a41fb25c0e791fa17" deposit_count: 200 execution_block_hash: "0xe9365f98552e964ec79bc2c5d2b0c741b2579c9558480d9ffaa1ee1d3df642b2" execution_block_height: 201 - deposit_data: pubkey: "0x8b4ff71ee947785f545c017bbb9ce84c3f6a90097368cf79663b2e11acc53e18e8f7159919784f4d28282cb39a7113f7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4d04ea08df7c81fd63b7c08aabfc91858eeeebf022ee8dc1eb85b2d092555df04d55cc4c1c4994dc040493b1e310ea10afaf3631c04556b99c22cca3f4b51fc07b63d8eafc136d9dc25729de2b157493277de3ce6427a7828c7aee03ea73c54" deposit_data_root: "0xd543fb17cd7258052cfa9c1f3fba1a8a858ca4228f5d612b517030a0bf95badd" eth1_data: deposit_root: "0x15a652c1b3b70a8a66292accc0392096462bb6655e9d8528afb93d25732e75a7" deposit_count: "201" block_hash: "0xae4a7f8e521201b9b74056012a8bdb16a12ca537009ee7b2825cbf5277efbcd6" block_height: 202 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" - "0xd543fb17cd7258052cfa9c1f3fba1a8a858ca4228f5d612b517030a0bf95badd" deposit_root: "0x15a652c1b3b70a8a66292accc0392096462bb6655e9d8528afb93d25732e75a7" deposit_count: 201 execution_block_hash: "0xae4a7f8e521201b9b74056012a8bdb16a12ca537009ee7b2825cbf5277efbcd6" execution_block_height: 202 - deposit_data: pubkey: "0x984a6c8f4b7545aabbe9e0341c5ff990a05508c94e3757da474daf1d70124c8213ba2457718ec2d1fc562fc0bb36213d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaf9e0247ecdab1f08ffeabf0b753f08007a14506b72377dbfb7d08069b43537995bee0d17a36be683d1d76d1f31218760ed3d72a992bcc4b8e33e1fee223c0614cca7f850d80e651628a3f1f0a129e5a2154e87e6f4c98978063f329eaeecf6f" deposit_data_root: "0xd4ff330e73b1afb26efcd9f7db884f99e14121b778ff54ed0f4cfdf5585d821d" eth1_data: deposit_root: "0x9c5993864595eabaeff8b60957115c80be20df7e4077c9799bc2718b85d31af4" deposit_count: "202" block_hash: "0x034d3912b8d10a6c82bff870992b671dd6053602d8b2ec63f5da2d533bbec9cd" block_height: 203 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" - "0xd74dd49dc28c9adbab7fb5dd05c11f09a6c2ef7289e6d45b56462a2dc7879a0e" deposit_root: "0x9c5993864595eabaeff8b60957115c80be20df7e4077c9799bc2718b85d31af4" deposit_count: 202 execution_block_hash: "0x034d3912b8d10a6c82bff870992b671dd6053602d8b2ec63f5da2d533bbec9cd" execution_block_height: 203 - deposit_data: pubkey: "0xa14cc20155f6fce0f248f9c306a32cbff425272829f7d920073c599b48168fb018c82b2aaf7cbb8b5f6449340023c37b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa993e3a47f18a67b4c866ef09bc402471a32422eb2181c53dfbfe6636f8a67bda4ba86ed22d3c480f796f70a56c6b20914c4b80a014199f8b35ea115a9f6f2539283479d545d9a33dd5f6babc3d861d5b03cec90bac204239f074c08dbe9cce0" deposit_data_root: "0xd1a0715f2f749515ed034ed6a16583a2ba0276f53db1a55aa6cc9b3d795e99b5" eth1_data: deposit_root: "0x8d2051b62cacffd2a701ca5212d26832f0f4e0dec045d5c9a996fc1f3e3d4afa" deposit_count: "203" block_hash: "0xd4833843972af8732196ca814e0ea093f8113431a00b6173b899a1907f449971" block_height: 204 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" - "0xd74dd49dc28c9adbab7fb5dd05c11f09a6c2ef7289e6d45b56462a2dc7879a0e" - "0xd1a0715f2f749515ed034ed6a16583a2ba0276f53db1a55aa6cc9b3d795e99b5" deposit_root: "0x8d2051b62cacffd2a701ca5212d26832f0f4e0dec045d5c9a996fc1f3e3d4afa" deposit_count: 203 execution_block_hash: "0xd4833843972af8732196ca814e0ea093f8113431a00b6173b899a1907f449971" execution_block_height: 204 - deposit_data: pubkey: "0x89737986b89c213367ab0fb9a4eb998d9b0b713143cc8b0f209c9355607daa4f6e6c925dac3026890e291a9480463395" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2a249d89d206c1e335bffc3838497ab0a8162bb827aff7ced1f08b819ac0e13583a6857eeb5c6eeeead7510062febaf0e142ab4c56a00802bea141e09e8708e750e3049cdbe91bb1448ffa1d2ec4f2c09a1626a774ceb0d0cbfe2e3a3c86207" deposit_data_root: "0x75b338b16d27eb10fbd28510660fe5816d30c5b2770abf69bf55aba29378746c" eth1_data: deposit_root: "0x1a2c95f781f6e6bc105146aa1405aa3a157e835e3159aae5e06a90fdb5e2c3e5" deposit_count: "204" block_hash: "0xadeb61523c297ae6488924eeb397706fbd36b90460ba258d39eddcc162bd32b9" block_height: 205 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" - "0x81af419186b40e88c6b75d4a7e50d2eb478b523a890245e90a5a8666c14d8920" deposit_root: "0x1a2c95f781f6e6bc105146aa1405aa3a157e835e3159aae5e06a90fdb5e2c3e5" deposit_count: 204 execution_block_hash: "0xadeb61523c297ae6488924eeb397706fbd36b90460ba258d39eddcc162bd32b9" execution_block_height: 205 - deposit_data: pubkey: "0xacd8a33698c0b95294943f0642c8b8919bdfbf1e92c61f26107f0f9ad989497742b58363e3d885e4d41a3bcfcc9c073c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x88acce1b8ddba924e58450a9bbb256fc8cde985dcf0c13fad60a248adc6bcbefd26846db5bb49401baef27fd3599074e09a7b18cc4c7b509585febf85dc56d346462b209359ec2cb16d2684a23d744ef4fa0c24e25078408b73f31aaec0256a7" deposit_data_root: "0x96fc4bac61a6cd54baa17b7434ff2d25eb1d0e3442a602af6d484cb1db9cc6e4" eth1_data: deposit_root: "0xd50f56058861337da0c947bcdb625f96a40d3ca4621c58b07eaf8f311aef09db" deposit_count: "205" block_hash: "0xcc2b772737ecdf295382ee2a1ee8894aa42f33bea847e41e308728a0f31ed472" block_height: 206 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" - "0x81af419186b40e88c6b75d4a7e50d2eb478b523a890245e90a5a8666c14d8920" - "0x96fc4bac61a6cd54baa17b7434ff2d25eb1d0e3442a602af6d484cb1db9cc6e4" deposit_root: "0xd50f56058861337da0c947bcdb625f96a40d3ca4621c58b07eaf8f311aef09db" deposit_count: 205 execution_block_hash: "0xcc2b772737ecdf295382ee2a1ee8894aa42f33bea847e41e308728a0f31ed472" execution_block_height: 206 - deposit_data: pubkey: "0x964e84e1272dcea0fd79d698c1db18e847a5abe1406ef7988e61f39e3f1ef46371be5c25b6c2bf7e53788730f702b735" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x80f6d4e14705862b42e0ba0ab0a063488d8c2a68a61294029529e0eeccf938a0521d81a06147fc84ed867d1ac90b61b613446206fb88cabb7d1dba91eb9808e0dcc82e474e57be768868aa76e2be21dc777ce6ae0c083fa2ddc5abea3325bed0" deposit_data_root: "0xb0cb5384d711a5179c1c0fae14f4b843321abdce75b4203796e838cb6bd8f9ef" eth1_data: deposit_root: "0x750757bba12b4098e68006661bb2504a51ecd34f699881f9ed0191f0ff10f694" deposit_count: "206" block_hash: "0xc030e84c7c82778ecb278a7970d6f0d1b453a126fc97b57b964aff30e0f4d0c3" block_height: 207 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" - "0x81af419186b40e88c6b75d4a7e50d2eb478b523a890245e90a5a8666c14d8920" - "0x177af982879e5f9786c25fcc42e0a20e48e09419dda7d03e71c6fe190adaeb5e" deposit_root: "0x750757bba12b4098e68006661bb2504a51ecd34f699881f9ed0191f0ff10f694" deposit_count: 206 execution_block_hash: "0xc030e84c7c82778ecb278a7970d6f0d1b453a126fc97b57b964aff30e0f4d0c3" execution_block_height: 207 - deposit_data: pubkey: "0xb406b1521362c206669d15b4e5448aae2f1854c707592abc612973b4726d47edf3bcd9ecea1a4b6cffc6a9f7b039921f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8122c635f73ce71fa05d9680c5c48c39085864af2e811c324c233c73fd12aec80390bb306a6103bfdada9a2679874261462273f765cc1c5ebce0dff42cd9e80ff21fed9fb53e755602db2646742013a4e6ea25470da6fc11a3ad90b06651f43" deposit_data_root: "0xf74d5d7d3af4a3bf5f6695b1f34ab4d5336c9ef290b8a1794f44db60a1d85b7f" eth1_data: deposit_root: "0xe39b947702ff8af4cc4e50acaa3fc0d9ab834dd60237e134122f4a5b3690644d" deposit_count: "207" block_hash: "0xc3dbea25648a192a58491607281a486afb876647edf3523a4ae7cbebbe7067e2" block_height: 208 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x1edb1ff214185dbce83d685ff59906b779b360f07616112aa60e2d2dc8508c51" - "0x81af419186b40e88c6b75d4a7e50d2eb478b523a890245e90a5a8666c14d8920" - "0x177af982879e5f9786c25fcc42e0a20e48e09419dda7d03e71c6fe190adaeb5e" - "0xf74d5d7d3af4a3bf5f6695b1f34ab4d5336c9ef290b8a1794f44db60a1d85b7f" deposit_root: "0xe39b947702ff8af4cc4e50acaa3fc0d9ab834dd60237e134122f4a5b3690644d" deposit_count: 207 execution_block_hash: "0xc3dbea25648a192a58491607281a486afb876647edf3523a4ae7cbebbe7067e2" execution_block_height: 208 - deposit_data: pubkey: "0x8ca1bfff2cea25ae77249cb18146a39b9630be5947b65d15044a5e5816b6d29dac9da83504083bb8e87dbe97dfb6451f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb83a7cf087d9dc1d5d587b103b84f2dbbfaa07d9385861937d2733eacb7c1e291336214aa6eea4b38377fb2a2a7de2170edf187e150125be3d3f8dee35f71b86be7bf4e8b390bfec55f15330dba9eefa1003fa9cc5122fa5c97d8d699f2e0a2b" deposit_data_root: "0xa0a33dd10f90a1ae86de6926edb1c128943a276b0532426521d187c1d5d363c6" eth1_data: deposit_root: "0xd2fe6e21e57ccfe1ededd19b56161b95e46022936207835b5563617107574558" deposit_count: "208" block_hash: "0x04a5433ddf3ad6d7dc52c745d96e863204f6f5add434e7d3a34cef73dd92e34e" block_height: 209 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" deposit_root: "0xd2fe6e21e57ccfe1ededd19b56161b95e46022936207835b5563617107574558" deposit_count: 208 execution_block_hash: "0x04a5433ddf3ad6d7dc52c745d96e863204f6f5add434e7d3a34cef73dd92e34e" execution_block_height: 209 - deposit_data: pubkey: "0x8c2e07abba50e0e1c624bae0dfff418f8f00502e377840f72e067cd33917a209c525fea7dcc7c44f0195a3b9a5dabbb5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b9f750ad5ca21b49bee7a975da855675f22904ed9bfc52d8a9491e6d96e8ba58fd67270d3084e91e3cc7ee7321d683d10864550590818c393d4c2a0003926e2e5a73164336c216babe5a0fef22ed447aa51c67cd4704762da4302e1f7d3b49b" deposit_data_root: "0xbdab20d7935a00c76b38e589b2073a6304eeed96e201423a7e420619edbbe893" eth1_data: deposit_root: "0x99fb82c1633a127efca032676fae7239a258b230c9323ec75644c7e659cbb231" deposit_count: "209" block_hash: "0x4d98b647dfe4547b79591778779136b4586160a163f5af4162fff546817ce4c4" block_height: 210 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0xbdab20d7935a00c76b38e589b2073a6304eeed96e201423a7e420619edbbe893" deposit_root: "0x99fb82c1633a127efca032676fae7239a258b230c9323ec75644c7e659cbb231" deposit_count: 209 execution_block_hash: "0x4d98b647dfe4547b79591778779136b4586160a163f5af4162fff546817ce4c4" execution_block_height: 210 - deposit_data: pubkey: "0xa4c11513391dd190b1ac0cf8a1c2c1b9c39d925b38aecb950d357283beee49ab97b1d7dfb34396bcaf1c25658fdf7713" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb82675644e2826c0d7f77f6e4579d2ba98d37330591e05c3e87c5de32a8c97ff1fa48902289ec52d990fb81d2172a5590c569bdc5da0f0f7b9e7e07d86433f54197a37457ad65cec11b8028e88c8e175e45530910925fa6720be77a7b5323d8f" deposit_data_root: "0x49b40e35773ce653a0d51a6a45e20d9490df06160eb3059830a1f7ac9fb7393a" eth1_data: deposit_root: "0x10530b32816c9a5d1213ecba4ea82e0746d706721bd5dd14441b32050a6c33e4" deposit_count: "210" block_hash: "0xf35c48ec777e6646c99c7e1a873e949bf426354e55c2f115fe9670914e249af4" block_height: 211 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0xa94a6052c766a8599b6c20b938f754be5554f1b7a7ce0c8d337160a8b5c5fa68" deposit_root: "0x10530b32816c9a5d1213ecba4ea82e0746d706721bd5dd14441b32050a6c33e4" deposit_count: 210 execution_block_hash: "0xf35c48ec777e6646c99c7e1a873e949bf426354e55c2f115fe9670914e249af4" execution_block_height: 211 - deposit_data: pubkey: "0x92afb506a8345b325a4fc1cf1135455eac709fe1c623bd8f0972cd9e51a763cc1e80bab1f7e01976d1c4f13af3c57caa" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xabd9696dd03623a4c7ee8eaba9dd7d40a3e2658d14c46ad3ba0e07fb6a8003788a6b22cde39b54b38e41549d4b278b270d4423ae1cf28228b92d29763200a97e454f66a2eb84e4596fa5b1776d288639c6ba9e2b8f07c6695e25d6369f59d9f6" deposit_data_root: "0xeb7df9a089860361315c6c55ed2695cad55caa92a751329b1c7f07e2c8055ccf" eth1_data: deposit_root: "0x30c2e1bb452f52ccf55edb7abc1ec4774dc3058e166ac655d79640f1226a7943" deposit_count: "211" block_hash: "0x7fa99b674a69b2752edf65932a26abdb23109fd68632de579ee075271fb91e80" block_height: 212 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0xa94a6052c766a8599b6c20b938f754be5554f1b7a7ce0c8d337160a8b5c5fa68" - "0xeb7df9a089860361315c6c55ed2695cad55caa92a751329b1c7f07e2c8055ccf" deposit_root: "0x30c2e1bb452f52ccf55edb7abc1ec4774dc3058e166ac655d79640f1226a7943" deposit_count: 211 execution_block_hash: "0x7fa99b674a69b2752edf65932a26abdb23109fd68632de579ee075271fb91e80" execution_block_height: 212 - deposit_data: pubkey: "0x978b5194d96515146754465533db2d854e58371f26e78fe0eebc5c5b65917a3611947cab3bf7fc645e3cb870e4826019" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa7a1cbd47302acfa136a0114abe23123670fa4ad08e76fa4bc86007e6d941c71ce51dd92cbf1bf0d8836b4ae49b762a609559b7e798e3652a1eda20d89ace8606fff2ca5b1fe83c7783bed9267a18cc29e119c361329c574cc64fd8d209221d7" deposit_data_root: "0x4715ee6c9d226f8fa5da1140ef6cd9f7f2f67a417c24498377025d176df07ddb" eth1_data: deposit_root: "0x64f8471778ca893643db2d0be9bf4ba437611a0bc61cdcef451da8250e30baca" deposit_count: "212" block_hash: "0x0176fbf110c6da3ef4495909cdc1928eb1d9c77a7f41444b89c73dfaab805caf" block_height: 213 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x80be627c56fc721728d409e5f72984eb86cf51276c72be17a7def353b43a0c36" deposit_root: "0x64f8471778ca893643db2d0be9bf4ba437611a0bc61cdcef451da8250e30baca" deposit_count: 212 execution_block_hash: "0x0176fbf110c6da3ef4495909cdc1928eb1d9c77a7f41444b89c73dfaab805caf" execution_block_height: 213 - deposit_data: pubkey: "0xa3f841f04d3410b06a4b4eb31b3fd92eadcf486af60986723d34ef7b8a9908541ab6e7e0ecf421f593f86afdf8cbe894" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa810363310e7254b59997009c7b4739bf34856e5b16b7bbcebc61c23efdf727e36d9be21eaf4cffd2eaf4563d9fe6b060eb81f52882047c188136b132f34cdd5d9b67b04acdce7684aa16e9e378de9162c5886bb48cfa76435655b099d5190a7" deposit_data_root: "0x8a2db165a79f35c68b6f84336b364a56a68eb231908eec22d8b32dd85fcc731e" eth1_data: deposit_root: "0xee9bc848d593ff36992ed82fa51763caa78d4e5efd3a1fc7ae9f0fa7e19a8e94" deposit_count: "213" block_hash: "0x51c836750936babe4616f3402135e0ab0dd470e1151c44879a4d7662b9b08be3" block_height: 214 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x80be627c56fc721728d409e5f72984eb86cf51276c72be17a7def353b43a0c36" - "0x8a2db165a79f35c68b6f84336b364a56a68eb231908eec22d8b32dd85fcc731e" deposit_root: "0xee9bc848d593ff36992ed82fa51763caa78d4e5efd3a1fc7ae9f0fa7e19a8e94" deposit_count: 213 execution_block_hash: "0x51c836750936babe4616f3402135e0ab0dd470e1151c44879a4d7662b9b08be3" execution_block_height: 214 - deposit_data: pubkey: "0x81fba887a59873ac21711818cc8a63b2d4be1a69627f8c70586a56328a96aff64b880f1a07c125eda24784dfea0bacd4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x93595db7bb94204b0825b54a3feaa6fbbbd2b7b2500eff772129f5d1633e5d3aabf48d138d91a11f3432fa45d49a7a2708ff91c8e53bffd0da37f03b03aebe01626d67ae5388a38325056e0ee9419f511520511fc772a51f4d512df91d562f24" deposit_data_root: "0x25cead55a29f7e5da33987cb5519bfbca4e10d14b747ec5d0e0a5d20f92a59cb" eth1_data: deposit_root: "0x0a6f0bafcc040a1296ff468e4ee75a20d5d26cc395113fefb164f4367ba017e5" deposit_count: "214" block_hash: "0x16b04fa33d14e124eb5a40a6af1b01daf48c86937982ae4d208f63bfbc4c7d7a" block_height: 215 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x80be627c56fc721728d409e5f72984eb86cf51276c72be17a7def353b43a0c36" - "0x3785e11a23b4330f60f96e5dad69c55dab1a4c26c521e1c02f31f53639928bb7" deposit_root: "0x0a6f0bafcc040a1296ff468e4ee75a20d5d26cc395113fefb164f4367ba017e5" deposit_count: 214 execution_block_hash: "0x16b04fa33d14e124eb5a40a6af1b01daf48c86937982ae4d208f63bfbc4c7d7a" execution_block_height: 215 - deposit_data: pubkey: "0xa9da8f5d1d62844df8f6fae763aa653127d6eaad1b4d8ba0b3b3417e9c486be3cc879ebad7fb182dcb364d3a292ab07f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8748cde6cce3b3b7ad6b0a606e3bbefcfd26794817699117b7ba4993df77ebb656954eab6d0563447620584f04d08fd7106462757153f4ee774ebfc316c9a79836dc02beae801f29c1da0933928a8fe0f326a01538e3e32a6f10f728edb34eac" deposit_data_root: "0x884ed496077a53a281f0d0b56028a6d3947753cee6ab57d9bbb71cd9bee577db" eth1_data: deposit_root: "0xdd69faeaad85b4e2093afd6b377c9bc01987a0ae95ce1ca8f7dcc05407cdf147" deposit_count: "215" block_hash: "0x7b4865729e81f44da4be1ba22a9dcc7e422c9532974f5a9062ec67ac9bd62cb8" block_height: 216 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x80be627c56fc721728d409e5f72984eb86cf51276c72be17a7def353b43a0c36" - "0x3785e11a23b4330f60f96e5dad69c55dab1a4c26c521e1c02f31f53639928bb7" - "0x884ed496077a53a281f0d0b56028a6d3947753cee6ab57d9bbb71cd9bee577db" deposit_root: "0xdd69faeaad85b4e2093afd6b377c9bc01987a0ae95ce1ca8f7dcc05407cdf147" deposit_count: 215 execution_block_hash: "0x7b4865729e81f44da4be1ba22a9dcc7e422c9532974f5a9062ec67ac9bd62cb8" execution_block_height: 216 - deposit_data: pubkey: "0xadeb5ccef7679c5d26e97ac5d2c8222058bf8b7c5eaebd31db3f3ecbb8d00987e2b921711dc6953eff6852601c57b198" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb6b988317f7e9f48abbe85d6719ab37ed5abc8e98d31a4a37120767a70b9e1cf4a5e3b391b9941a201cc7a1f004fa97a0a1e3c8767e0fdac133d9292a8eb6da59e5ab28473bf87d0ea514ac69c60f1b56f9d31aea615fa48ac7feb17e1ebb4b4" deposit_data_root: "0x8699f7dfd9049a9383abc845a33cbce20d6bccd88b08cfb4166e298ead4e2dd9" eth1_data: deposit_root: "0x5bd775b2a763bac39331c22c5a1fb189221e22f7be74fb91dc7de0eeb7fcbfb6" deposit_count: "216" block_hash: "0x3660dc622cb11cd94846055fbeb73df41c3a088242dd96c2e5159de3f1cadc48" block_height: 217 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" deposit_root: "0x5bd775b2a763bac39331c22c5a1fb189221e22f7be74fb91dc7de0eeb7fcbfb6" deposit_count: 216 execution_block_hash: "0x3660dc622cb11cd94846055fbeb73df41c3a088242dd96c2e5159de3f1cadc48" execution_block_height: 217 - deposit_data: pubkey: "0xa4e2f5a419590f3d30cbcf9cac0b4a89b636458dd6d38aa763694d4edd787056536089077d8e71cc4b182f8e87dc7916" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa4c51bc0d55bfc64de2f5123bb685777f33784bd632b61e65166ca8eb8084d8effe9e93e4a7359b88f4d03644fba521028e45f33996189e216637655ac2de55dcb0266289b81cd8b4e83c9e2bf0b7bd53d95942f66c7ee9d85776c8ff7af6ce" deposit_data_root: "0x1c3dd97d82fd3cc85dfedad67f70b39cd7bc2df5d376eee91cdb3137e1f420da" eth1_data: deposit_root: "0xebbdfeb489d87fc3cd7e79ae85adbb1ca2237cc64b6e4d37a6de996f32f6ea3e" deposit_count: "217" block_hash: "0x861a80af90e9a9b72718b0f49dac71c9c100cf0d00ecd0816b52278ce534e106" block_height: 218 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" - "0x1c3dd97d82fd3cc85dfedad67f70b39cd7bc2df5d376eee91cdb3137e1f420da" deposit_root: "0xebbdfeb489d87fc3cd7e79ae85adbb1ca2237cc64b6e4d37a6de996f32f6ea3e" deposit_count: 217 execution_block_hash: "0x861a80af90e9a9b72718b0f49dac71c9c100cf0d00ecd0816b52278ce534e106" execution_block_height: 218 - deposit_data: pubkey: "0xa365251e868fae8780f009c14c7ddc349389230b75c79e11628b798dad880d9704a10f3358bea40f4136fe37fdec13ca" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8ec3bda16c205360636e42958f2076ed5e245cb48f3ea395d7680c689f62eb2bce4839b78129884aac0dab5345706f560310654681b3542f364b7aa4e426109ec7a772070be08997e80a890e2c1e8a4606f50cddc1fa8298ccb038719561bcc6" deposit_data_root: "0xbc2cf0159a36545c3dee043c7c612029a41ba7e4ac055d4c63ec9eb5b6564738" eth1_data: deposit_root: "0x7bc4420c8f3a21b553c643f7f33d830cfc6a658e9c5e53c24828403d3f487b82" deposit_count: "218" block_hash: "0x1fbb6ad18010df3607676411ede951c80c862b09db67219380cccdeed7d01422" block_height: 219 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" - "0x555908f2ac7299a40b5bb9269ac6d4ea86a65af7b648d63181f59cfa8314d17a" deposit_root: "0x7bc4420c8f3a21b553c643f7f33d830cfc6a658e9c5e53c24828403d3f487b82" deposit_count: 218 execution_block_hash: "0x1fbb6ad18010df3607676411ede951c80c862b09db67219380cccdeed7d01422" execution_block_height: 219 - deposit_data: pubkey: "0x91ad339cd616316e79470c8695cd83b3811eb762f292c9a67c802b84e8e074ef5d208704dc1d5fb4a8343e0e44b25807" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x85d02a1704c8fcdcce59ac1ec6868f282d66839ea77e3673cabcbc178b8cefa93b4dec28167f38a83dacfed4b543f1260375c743bd25e015d8450ae0503594afd8eb394411dbd377f67b16436b6fafe1133e5012c474158aaf2881c040f27716" deposit_data_root: "0x0407440d40aec95c78548e7f9cfe22144f11166bd468e553a150733962098bd2" eth1_data: deposit_root: "0xadfa2dc986c1769723c3007c92843f9fba2a30d162548bfd2c5073a0520ef59b" deposit_count: "219" block_hash: "0x274170cd5f2790ae9938185e411eeb46d258cc7a1d13a3db5be028cc55a832ee" block_height: 220 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" - "0x555908f2ac7299a40b5bb9269ac6d4ea86a65af7b648d63181f59cfa8314d17a" - "0x0407440d40aec95c78548e7f9cfe22144f11166bd468e553a150733962098bd2" deposit_root: "0xadfa2dc986c1769723c3007c92843f9fba2a30d162548bfd2c5073a0520ef59b" deposit_count: 219 execution_block_hash: "0x274170cd5f2790ae9938185e411eeb46d258cc7a1d13a3db5be028cc55a832ee" execution_block_height: 220 - deposit_data: pubkey: "0xa2d7d0d6f85894bda115022811b35ed5689143187a911fee5bcd0d6b1c78f4db3542223f496024fb2279b8ee76b5ea79" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa3d3e4034783206e696e6ed0fe1bb3d85b3ff78892422daf8f73b60c3526e862463c0ebec3f57fee778adadac8c4e096016430f0e39659ce5cb4ff72e377ef585b0e5fc06502fe030cc19c6ea3b63c475c4f151c698758f3ab55c6a757ca004d" deposit_data_root: "0x4ff35fdd7abcb307af9cd011f196a1dcc2383905c9f5267ccd8e12729932ded0" eth1_data: deposit_root: "0x6c54753ac7f623632b80b673c081a8aaef63506b1e4125e3d37557e191c911dc" deposit_count: "220" block_hash: "0x75b5f98560bcca1d3ef1f0ec2409dbe6ade0e7c167446aeaaa2834c4edbda673" block_height: 221 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" - "0x4615edc70a037bfbbe30e36784fc579c02930a553305855c6201fa479683dbd9" deposit_root: "0x6c54753ac7f623632b80b673c081a8aaef63506b1e4125e3d37557e191c911dc" deposit_count: 220 execution_block_hash: "0x75b5f98560bcca1d3ef1f0ec2409dbe6ade0e7c167446aeaaa2834c4edbda673" execution_block_height: 221 - deposit_data: pubkey: "0x80029a26a45145f67892bfb25783d04f700e8917afc2b406695d4443fc3a45ab9c2c0572c357a33a9ed3877ebc479822" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb7f1069867daaee8b61e9e4494feb875e7192624aa37058b3862f796ef13e72df222abc75b902324af95af6baa62b5c40fbb70f59aeadcd4eb4a22a2591aeb150e9b04fbce014b4bebff2af4a7f38aa17ceb65c01cfb2aaab6f290703d12f878" deposit_data_root: "0x8d9db83da28ca8c0edf22485af80afc1f19b144a3b44797cff3f9b11fc580f0f" eth1_data: deposit_root: "0x994cebba4398a53a0b2acfe1754f7e26ad34f11cbdaa520bf72099e5ba45cfcb" deposit_count: "221" block_hash: "0x9f3818b078a804575ae9a09ac84ef7268274b564cb832e78662d8febb4b9e81b" block_height: 222 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" - "0x4615edc70a037bfbbe30e36784fc579c02930a553305855c6201fa479683dbd9" - "0x8d9db83da28ca8c0edf22485af80afc1f19b144a3b44797cff3f9b11fc580f0f" deposit_root: "0x994cebba4398a53a0b2acfe1754f7e26ad34f11cbdaa520bf72099e5ba45cfcb" deposit_count: 221 execution_block_hash: "0x9f3818b078a804575ae9a09ac84ef7268274b564cb832e78662d8febb4b9e81b" execution_block_height: 222 - deposit_data: pubkey: "0xb6c8c112c7802a29579e14b228ae6a33fd7f0a3d33d06708b0f07cf7ec18f48e5ed7d5c47e7942c2aea2d1f4dd95557b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x82d56bd4b5cf49b4aa037a0fac68e16f6285b7e2156e52267b15a0f424c60f6df11456d6ee28dd6e48782c52fdae8690062b82574903fe2f1a0b6a502f9667957022fb4685f9d77576cb580148448f1a8d223e2d3809c55d52314b33033053e7" deposit_data_root: "0x9c5e003d673975a5d0dd59c797238f6699c03098dafaf05c841725e13f2211e7" eth1_data: deposit_root: "0x3190b4adb59dba145f8bbcc6e138e92173e69a57b657bd09822f0dc4699bbd6d" deposit_count: "222" block_hash: "0xd35aa31fa61ada5bdfafd207b08316b9cf404bbbbb655756be1654367a556dea" block_height: 223 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" - "0x4615edc70a037bfbbe30e36784fc579c02930a553305855c6201fa479683dbd9" - "0x9d39bef25d1cb967f1c2afc70f08d3b10fa353154698513f0516f4a2326ef1c2" deposit_root: "0x3190b4adb59dba145f8bbcc6e138e92173e69a57b657bd09822f0dc4699bbd6d" deposit_count: 222 execution_block_hash: "0xd35aa31fa61ada5bdfafd207b08316b9cf404bbbbb655756be1654367a556dea" execution_block_height: 223 - deposit_data: pubkey: "0xad4beca6ee84273739c03792e0a2096337c92fb096f7a902e0b09b8bf38d3f67c27a00b05d3ca69a0c9a43b491e8af4b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83afd2f9eee050a9e4f27651dca18b4ac1a4a48523aaa8d41fd7c87b26e288a07e4ff33ffd243fc053204b10a9abe3cc02b014ab31cdea51e94094d670dc9f6c830dc0c04f078cfcd74cb3cafa0bad02d99433d67a2377b53908062267573dc5" deposit_data_root: "0xa2c62c2afa8009d90ee3f7ded14aee4bf2d35ecea17026a011447c433f42986c" eth1_data: deposit_root: "0x21511637fa74488b88e6b0831a941619772a0679c69c43f0c7a91ec5ecda1b6b" deposit_count: "223" block_hash: "0x4320d44ec19761231557697186b0c02d807a9980a0a55c0af4b308bf9276fb65" block_height: 224 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0xdc8256156a85778064cc0f46fab037bebc4ea0f98abe602270d370a7938cc711" - "0x500bcd7598a4378a5c0ab9ae9ed217c3ca4c47ae0e0d34b7f5d9c987780cc413" - "0x4615edc70a037bfbbe30e36784fc579c02930a553305855c6201fa479683dbd9" - "0x9d39bef25d1cb967f1c2afc70f08d3b10fa353154698513f0516f4a2326ef1c2" - "0xa2c62c2afa8009d90ee3f7ded14aee4bf2d35ecea17026a011447c433f42986c" deposit_root: "0x21511637fa74488b88e6b0831a941619772a0679c69c43f0c7a91ec5ecda1b6b" deposit_count: 223 execution_block_hash: "0x4320d44ec19761231557697186b0c02d807a9980a0a55c0af4b308bf9276fb65" execution_block_height: 224 - deposit_data: pubkey: "0xa9ec8e4f705f27e6991a43ce006155825776666664d03be89929c4e5c9a01c7b759c1751e16b7a5d12084c419e97878d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa7b8b994844e1f99366d6b36e6802dc9e9c9e93898bbe2856b17b47f3ee086dead8413745f983d2d02aacbc58c623faf096201428d8cb54a5632334e9e486279e1c055fbb7b993827ee6823dbd633b3f5adc742133f2835470e2c047410d0218" deposit_data_root: "0x757bda9525f7bf25b15158d2eb44382b9271d489703752c15c79f2022e8bf9c0" eth1_data: deposit_root: "0x7abe7feec57fc014c31f919a1706868a569b15e5721201500f8a502f2c38ca73" deposit_count: "224" block_hash: "0x2e1d1bd56695914502d3d69e874b7969503fd2bddd90402671ae2e58210e30e4" block_height: 225 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" deposit_root: "0x7abe7feec57fc014c31f919a1706868a569b15e5721201500f8a502f2c38ca73" deposit_count: 224 execution_block_hash: "0x2e1d1bd56695914502d3d69e874b7969503fd2bddd90402671ae2e58210e30e4" execution_block_height: 225 - deposit_data: pubkey: "0x801a35e02410c44a3d81b564980738fc5a1d4d15b887c9477c8835c9038233fceddfac4c572226599b25fe3faefa85b1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xafcafcad14dcb0b9aa9cbd21fefdee102e9da1439d676e7721edd62641b218dcb43264f361e56e2aecaffc31865c0f9304c7ebe5ce98f2c8dc230029bc681d9282b80ee0a4b1f18e8bdbcb80e6963608bc9d02182afed40ae381347577395f9c" deposit_data_root: "0xb0c1df18776f2378e753ae8937bce428eeed11559e3e00da552ad63fcebdefca" eth1_data: deposit_root: "0x3f5c02cdafa88b492e4e0e4a424dbe520959a048044e2c214460d9aea2fb203a" deposit_count: "225" block_hash: "0xb382a1b5dbb7b22d33c0000937f48cc9d2a1902576c2f789b2e13eeac8e295d0" block_height: 226 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xb0c1df18776f2378e753ae8937bce428eeed11559e3e00da552ad63fcebdefca" deposit_root: "0x3f5c02cdafa88b492e4e0e4a424dbe520959a048044e2c214460d9aea2fb203a" deposit_count: 225 execution_block_hash: "0xb382a1b5dbb7b22d33c0000937f48cc9d2a1902576c2f789b2e13eeac8e295d0" execution_block_height: 226 - deposit_data: pubkey: "0xa38b922e79533b5fbec5f710ad90837cfce8073c982c57597027e5b6facaabc1edac06c7014fb1bcf8e11aaca4049dbb" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x813753be7c3419e592c33627668db7e74bae071c775b069194853355f9b91755d7dcc77672ebc011f313c8e3dafecc900f63260e6247d7a1b3c08ff3a6f1c9ff5b805b073049d1d197867d66cf9d356a3f6200041b4722d72564aeb29a0d4a7a" deposit_data_root: "0xb7c0ab5e3995215280d9af900c21a86dbb5d2cf9ff454f7a762b699358e9558c" eth1_data: deposit_root: "0x3e59ddbdc9744648e98694f1fb660d80bed43d554cee48dd274b482847d8c1c7" deposit_count: "226" block_hash: "0x6a3c9dafcc60d22e4747369ddd595545dacdf29926f2d3d6d4344ccb76fd8760" block_height: 227 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcb67f19e86fe3c871884bd661d1a82b3780ca2e36b225490607b2a6eaf66a552" deposit_root: "0x3e59ddbdc9744648e98694f1fb660d80bed43d554cee48dd274b482847d8c1c7" deposit_count: 226 execution_block_hash: "0x6a3c9dafcc60d22e4747369ddd595545dacdf29926f2d3d6d4344ccb76fd8760" execution_block_height: 227 - deposit_data: pubkey: "0xaf4cb80f788305b5c22f5a16bd3f5d2f2f50a403e4171b78e267a4e2d15b14beb04735b9ec206751a8163dae9ef3e96f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x828d01fe50f60180f2639e9337a79c130615172a25692bb29c0e21b7a6644c63820b38840fd2dce4c425faa1c8ae96bc19d7761cf0db0493413ab186acb3fe78dae6c3db6d815d91f817645646d54ea03738db3b2ca686344bbbfadd06299c45" deposit_data_root: "0xd8a2270f803bc660d2ae17e446ea8a47d59fbac4662232c48d7093b28bf4446a" eth1_data: deposit_root: "0xb1d7530096f2c5173ff8c3568bdc8dc0eccff29e5697ee803b488a9b1c89c451" deposit_count: "227" block_hash: "0x1c539da3e3764a8e1dd17e19451b72437daeb6f8fe45e592e8d96a7970efad4b" block_height: 228 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcb67f19e86fe3c871884bd661d1a82b3780ca2e36b225490607b2a6eaf66a552" - "0xd8a2270f803bc660d2ae17e446ea8a47d59fbac4662232c48d7093b28bf4446a" deposit_root: "0xb1d7530096f2c5173ff8c3568bdc8dc0eccff29e5697ee803b488a9b1c89c451" deposit_count: 227 execution_block_hash: "0x1c539da3e3764a8e1dd17e19451b72437daeb6f8fe45e592e8d96a7970efad4b" execution_block_height: 228 - deposit_data: pubkey: "0x8e0d2214a6f4364590a4acbe3db7b3757b6f2f1eee526babc383e68fee4a7c9735a672f83aff5e9384d66b2fe264c9b1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb07f7ee9cae121e1482ad8cf0855b4ea785bf039f3c09032e417f9b6418b83ad4c7e68f9b68ae015953f5519fd47c8a604d61acf88b0a10c6bb0061f99320be1ea016e3e07e5d6078574ff97d5e9fc315f5156cc6d4f79c541cec94cd5872dc5" deposit_data_root: "0x6bef5bde9f19342720ad3e132be8e8b9f7bf1508882bfe3f8ab56e1d11faf7db" eth1_data: deposit_root: "0xdce8bfad47155a9784cd497dcbc4dc3e96f262261246701c7792d45689a4e44b" deposit_count: "228" block_hash: "0x80caca4755897203f034dc16b609c1c2f4564cddad11ba383e79803dfc8b00e0" block_height: 229 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x5fb54637467f4b1e7fef955014bb48a73937a490562092a7bd1b99dac451fde4" deposit_root: "0xdce8bfad47155a9784cd497dcbc4dc3e96f262261246701c7792d45689a4e44b" deposit_count: 228 execution_block_hash: "0x80caca4755897203f034dc16b609c1c2f4564cddad11ba383e79803dfc8b00e0" execution_block_height: 229 - deposit_data: pubkey: "0xb110c3a2e0100ca6338d66f81c4fa6eb5cdf0aaaf839ea8e0a67645d958fba5f13bba8b66f7f9d069d571f25cdb8e47f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb8381b33e5ebec8010aec019e024668752bcebaa27b7ec938fe9e2a27d13f56c0e14c7fe115583ef230b5d0fb2d9a59c19f681fbc38f34b2aa9f63a58763f9804a01098031e66e2f7399482719c1729d07c25b852ca442dc620a69054de8e739" deposit_data_root: "0xbde6b47792e6754679c58260381c259bbd16097042b3d1c24404f6618b902e52" eth1_data: deposit_root: "0x9be8f309e2977f393617ff08549158f8185a24bf719001070d47e4fc19ab8806" deposit_count: "229" block_hash: "0xd9dda4f35c9c3edc515d03b9513be176d9420527d9ca62f2d7f484560d68985a" block_height: 230 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x5fb54637467f4b1e7fef955014bb48a73937a490562092a7bd1b99dac451fde4" - "0xbde6b47792e6754679c58260381c259bbd16097042b3d1c24404f6618b902e52" deposit_root: "0x9be8f309e2977f393617ff08549158f8185a24bf719001070d47e4fc19ab8806" deposit_count: 229 execution_block_hash: "0xd9dda4f35c9c3edc515d03b9513be176d9420527d9ca62f2d7f484560d68985a" execution_block_height: 230 - deposit_data: pubkey: "0x879db2b2da4652de6f12a5a9e5f8665daaffa2e4c25fc8609af45b428dd2a35244b66ac2a910dd76c0961e56c660cf59" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa14756fbc7bfaa2c851472eddf1c887d18c23fcbb3d2594e9dc085ed3236ffcd19529ea1905a48a9c666a61c8571958a17bd95397ba545381da98689290fc8e359aaa24397ed33279e739e23ce2eb0f6de4b8c3e5ce1f4d15ed433429300f380" deposit_data_root: "0xefc249e2faad07106c09333b4cbb73a021b753a9e13c8eb611b495829b22d501" eth1_data: deposit_root: "0x71fc589ae852643220368a3ded27a2aced2490b2405e2c7746a1ded7037cf662" deposit_count: "230" block_hash: "0x58025631a377c39ec1ff81899fc7574e3e918af2fe5b6cbd52afc269b69f27b4" block_height: 231 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x5fb54637467f4b1e7fef955014bb48a73937a490562092a7bd1b99dac451fde4" - "0x00515eda2b4aff0be9224f7d22352562c340830ab164489eee65b44431d623b1" deposit_root: "0x71fc589ae852643220368a3ded27a2aced2490b2405e2c7746a1ded7037cf662" deposit_count: 230 execution_block_hash: "0x58025631a377c39ec1ff81899fc7574e3e918af2fe5b6cbd52afc269b69f27b4" execution_block_height: 231 - deposit_data: pubkey: "0xa4cc78a560437549a4924c1d355e81a3467aaf9d7e7e1b4c7df6b39528345bb950c51c5316abe27f8618e5c7ca7dc5b7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xae747862da82759f24af4f9103c1ed3f87f235a89fa77853050c607e11a10f4bff05de215e6c6aaaf5b9d6b539451d1003c8531ba3bd379edb89a0ee7b5219f011336fd8232d40a10238559263bcfe81da3f31fd29397f8e0b9cff013b9da2ba" deposit_data_root: "0x9e5b59deb9c620e5218e2064db2836bff8fd7cadcee035ee762f8db7c574cae5" eth1_data: deposit_root: "0x30d14127c55bfb5dbcd6adc091e29a155cea9657dcc190ce17d57875fb723556" deposit_count: "231" block_hash: "0x6b95be192a6c1967572f0e532c52335f7c273cdbe805373da35ab2ee78f7ddef" block_height: 232 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x5fb54637467f4b1e7fef955014bb48a73937a490562092a7bd1b99dac451fde4" - "0x00515eda2b4aff0be9224f7d22352562c340830ab164489eee65b44431d623b1" - "0x9e5b59deb9c620e5218e2064db2836bff8fd7cadcee035ee762f8db7c574cae5" deposit_root: "0x30d14127c55bfb5dbcd6adc091e29a155cea9657dcc190ce17d57875fb723556" deposit_count: 231 execution_block_hash: "0x6b95be192a6c1967572f0e532c52335f7c273cdbe805373da35ab2ee78f7ddef" execution_block_height: 232 - deposit_data: pubkey: "0xb0959a30fabda6f21ccfff1b9a4854fbd869e767b253c2f9bc08c4cbbaa3c24f37a7124dd8e67e2b0bdf4b052c2c9873" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb64885eaff19de38042492a996f157cca5fcf0194227e2d06b6aac66c8dd851806072acc35516a314384b5a11acedc2709ff085e2a236ee9b1a7c2247d229fb709c012daf6d0b3a8e1cfcaffd6f7d205d8feb2464cfa4d2c99c2b225d7b179cc" deposit_data_root: "0x7f90ce698e743d4711e8b9b3f6ab4461dc9f08f24f98e9a89319c3b0a526f37f" eth1_data: deposit_root: "0x53f5b42be17a65b15e69dedbb6555c8c16807de1e45febdf338ad2cca4172620" deposit_count: "232" block_hash: "0x7de5afd9e8b8fee40adb38fb6fae15c8bd6270fa7c2985eeab19ba6cba7f8084" block_height: 233 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" deposit_root: "0x53f5b42be17a65b15e69dedbb6555c8c16807de1e45febdf338ad2cca4172620" deposit_count: 232 execution_block_hash: "0x7de5afd9e8b8fee40adb38fb6fae15c8bd6270fa7c2985eeab19ba6cba7f8084" execution_block_height: 233 - deposit_data: pubkey: "0xa050c5180ee6cd9daef723caa6367112bc4b06636c3da59c3377e5e7b536942417a29cd5d1dad73011db4492032caff6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9208506ad4ad676f471b05fb33ab7d87b7b1fb7d4a8ef630c87407a568150aa88df852bde74fa50dbcaf3b9f81211c4c1759eed3952f470772d2dbe2c57ed35886530659cf3838ac540d9be98309549ff7121eb959d9f6deed0c25a63fb2a944" deposit_data_root: "0xba747d4e778466e602ce18816cff1e7c36f7a8c16531a624a3920df6d7650441" eth1_data: deposit_root: "0x29f2b6c06fc3cfa95c9960525011a1ec1ea97bcb65ece736ac0714e6699a308e" deposit_count: "233" block_hash: "0x046a47e1afbda13b44861a64c6013262ce2d2bbd3afc4c0e72f55a049acc2acc" block_height: 234 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" - "0xba747d4e778466e602ce18816cff1e7c36f7a8c16531a624a3920df6d7650441" deposit_root: "0x29f2b6c06fc3cfa95c9960525011a1ec1ea97bcb65ece736ac0714e6699a308e" deposit_count: 233 execution_block_hash: "0x046a47e1afbda13b44861a64c6013262ce2d2bbd3afc4c0e72f55a049acc2acc" execution_block_height: 234 - deposit_data: pubkey: "0x96dddc7430e5f035c0c4d005ef950eea0b3cb8188fa1db85b947bfa69745d4cc0f8ca522b3880823154796fcfedd970b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x88df1ad86744a29bc86506d348e9e3f1f762a1a266ddb6a655a34cc45ea7897cb5467d267022e8e8c9f280ca2aecec081652fc8ac2a3de171c6e240687fe0564bbb5671e46ee029cb3ae63b900838793b89913966a4823499fcc2be104c8b177" deposit_data_root: "0x40f5c80a61e389915cd4d3e5f80ab4db55c85a2f4b2e57bf758f445538dcd272" eth1_data: deposit_root: "0xbfa95468dce6817d6393887438d0a90146367ced8533a2667f78b841e6c4a9d8" deposit_count: "234" block_hash: "0x28781e828d46a57b76c052c4b3ef44160cac67098a057a94faebc2f4e3540d74" block_height: 235 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" - "0xaba4968db31e01e16a317caeaa2d3bc79f6efbe46926a9f8bf6576931d120e34" deposit_root: "0xbfa95468dce6817d6393887438d0a90146367ced8533a2667f78b841e6c4a9d8" deposit_count: 234 execution_block_hash: "0x28781e828d46a57b76c052c4b3ef44160cac67098a057a94faebc2f4e3540d74" execution_block_height: 235 - deposit_data: pubkey: "0xb1eef7970c10f8bb2a2d70f566657cc0209b198011ee3a4aaec9e7ddaf571fecc03db1042997b1554286e52ea95cce27" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa6274df964c6175a7c789c2244c212bebda8c658fc21f3cc9cc2aaa81294785c9f3985bdf9203709b4bf4b945d25e60e02cc06cc6d9a5a1b88785ab48488d820458986e9561c4e45ec3f5627573fb7e499ca98c5b9461448a1e8c78f77dbe104" deposit_data_root: "0x3f6f7e82534853f2c9d372660aa30baf5c68749d16f7e01a4a208b2bb735d102" eth1_data: deposit_root: "0x000d046fe7ebb4a367257dd30536ddce1ba46896bf412d3b4315ff19c62a17cf" deposit_count: "235" block_hash: "0xde2f782bde063ebce8d17a6ffb690e59eef61c57854fae148a85d05a1d062c45" block_height: 236 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" - "0xaba4968db31e01e16a317caeaa2d3bc79f6efbe46926a9f8bf6576931d120e34" - "0x3f6f7e82534853f2c9d372660aa30baf5c68749d16f7e01a4a208b2bb735d102" deposit_root: "0x000d046fe7ebb4a367257dd30536ddce1ba46896bf412d3b4315ff19c62a17cf" deposit_count: 235 execution_block_hash: "0xde2f782bde063ebce8d17a6ffb690e59eef61c57854fae148a85d05a1d062c45" execution_block_height: 236 - deposit_data: pubkey: "0x85f65540cda46d23cf0ef948b5793b46a81771b4621ffb4b98c6dfa222208ffe3215bfdd436eed5ab124969704752e18" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x82b2f53b7b688fe92b7f3c0f991e2a8877c7da12806e596d2a36fe3d444a5e7fb2ab90b3989d2e0e7e3bd1af6086cc1a05281be5c581ac36e4a888f10460e6b1a5dc9f1de72580932df9a88fab6d0aa1646fd580dc54118bb08670569df173b0" deposit_data_root: "0x14f05f69965b40e8362e9ccedea325ba0686bbe2777dcfa7db391cf2176e9dd7" eth1_data: deposit_root: "0xfc113b844286b5723c0470bacc323281edcb6c74aa79e716649bce8785ac4bbc" deposit_count: "236" block_hash: "0xad091a6f9838ac87857dc11a206927e15fe263591c391d3aee5ddf3ab5cd19f0" block_height: 237 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" - "0x0f7262bce5861c90229709693935a8f977f19c7ea94b4e8bd1f12985baecf8bf" deposit_root: "0xfc113b844286b5723c0470bacc323281edcb6c74aa79e716649bce8785ac4bbc" deposit_count: 236 execution_block_hash: "0xad091a6f9838ac87857dc11a206927e15fe263591c391d3aee5ddf3ab5cd19f0" execution_block_height: 237 - deposit_data: pubkey: "0x8d016fd1936593cb41b3e94c01ae213a770cfcc1e94e06bf90dd77dfb8721090cd17255aeb4b4da53bc2a70257d2bc5c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xac1c8006b0200c3dd436b477bb2b280bb786f28790bf5da9fe4011ac3fadd996d6409642ec024fd238e46c1f3aa84a4716752ece5f09fe5f595a257c2eaa516375f9911255f91e938cf27ba02ee75abb5dcd22d2f25659d1212dc0bf5dc4b9d4" deposit_data_root: "0x9cfa02a46e3cc3e3f5aad20774b3f64b1cb9808321b3604b55b87e0868c9bb95" eth1_data: deposit_root: "0xa18458316c22446c517019010eb193e2277fde1eb5aad56e1e42df9c231b2e31" deposit_count: "237" block_hash: "0x691970c03abbade8133576a1253209024f4bc0139674b807e6204bc3e23793a2" block_height: 238 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" - "0x0f7262bce5861c90229709693935a8f977f19c7ea94b4e8bd1f12985baecf8bf" - "0x9cfa02a46e3cc3e3f5aad20774b3f64b1cb9808321b3604b55b87e0868c9bb95" deposit_root: "0xa18458316c22446c517019010eb193e2277fde1eb5aad56e1e42df9c231b2e31" deposit_count: 237 execution_block_hash: "0x691970c03abbade8133576a1253209024f4bc0139674b807e6204bc3e23793a2" execution_block_height: 238 - deposit_data: pubkey: "0x953e4c8ef12a42ae5376ba23e06cfabf11c5e3fa773a98b487723225f1a2df60be50a54a7d5621bd85be25ddeb73af38" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x933a3fe4013d7669896335b2c866b160b31b1032bf990ffc350d94c747effc2c2e29f189f875246ef57dc6a0bbd143a200c2c48be3182476725fa3844a52f2a069ee18900e1c2b039d11bdfecb4ac068e3a1dd5c73b3d69db0f1b51b240c4f9e" deposit_data_root: "0xcd3264430f4abf9cd490f8f5712b274a53c4a32c3333624f39ec75bae8fabe98" eth1_data: deposit_root: "0x9e37fd0fc2fd4db56f06797479f91b79ddead19653a7aa07c766429cea8bf45d" deposit_count: "238" block_hash: "0x866e5ee2515e964c4254798b6ad79900f96759665c738b22e7ece20d6e286b50" block_height: 239 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" - "0x0f7262bce5861c90229709693935a8f977f19c7ea94b4e8bd1f12985baecf8bf" - "0x9cf3b21fcd49adade498b802a1debdb7d2beec431c1aa4372eef06deec2bc955" deposit_root: "0x9e37fd0fc2fd4db56f06797479f91b79ddead19653a7aa07c766429cea8bf45d" deposit_count: 238 execution_block_hash: "0x866e5ee2515e964c4254798b6ad79900f96759665c738b22e7ece20d6e286b50" execution_block_height: 239 - deposit_data: pubkey: "0x90b3bf8ea91bae7c8d0e33974c65e1ce677328030cf63111d9ee5cbf6d300c72fc033c3c70d6afc21858fb9d2964875a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8462a3226ea043966c38f560258a0628da44dd4ca7daeaf82bbc64b77c21a5a34f2ded52a1ff0c012b6538e8e49d7801045b3705d346fcef4d6cbfdd694f784b4a557ebf6354c0e64554a31ccd8bb0be35c6aabbd8f0be2f02face2853211013" deposit_data_root: "0xaeb3b2cc80454c6e05ea47a0511b3a569f488624dca56695d4f984414a0ab986" eth1_data: deposit_root: "0x3148e7f341bb5610dcaf8209f84e28569aa86f787a4992e1c530fa35ec25851b" deposit_count: "239" block_hash: "0x1eadc81c31cc7f4b5c446bd88dcba2fa748773b9c6f847b1f81b254a9db5cd29" block_height: 240 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0xcfbab008757754f57710fd99c573283e4cbb498498c07b5f6d1a5c1102ee3bd5" - "0x0f7262bce5861c90229709693935a8f977f19c7ea94b4e8bd1f12985baecf8bf" - "0x9cf3b21fcd49adade498b802a1debdb7d2beec431c1aa4372eef06deec2bc955" - "0xaeb3b2cc80454c6e05ea47a0511b3a569f488624dca56695d4f984414a0ab986" deposit_root: "0x3148e7f341bb5610dcaf8209f84e28569aa86f787a4992e1c530fa35ec25851b" deposit_count: 239 execution_block_hash: "0x1eadc81c31cc7f4b5c446bd88dcba2fa748773b9c6f847b1f81b254a9db5cd29" execution_block_height: 240 - deposit_data: pubkey: "0x9412476b39b4c36ba977e5aa1bda710a773b48c95a6486d0201a978eaf58c51bce7c8b37e34f3bd61322c2f7caf53bc5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8c5224f300841a22377468fa8aa7a8c5d1ddb596c6ec85c7139724cf83c6b0707ec61f9a02a1aa185e553c260835f860f599d2c4afb79bd5506e8f077dee4cedaee36cd6ecf67dc5183110b1d00cdcc6b2fc98a61d41acaf5c207330bb535d6" deposit_data_root: "0x65bd202a5b6f083b0e57a1d1a1d99e2cd60a71071788a0ebf89723cf1f98430c" eth1_data: deposit_root: "0x8e9055eb4be6187b776047300d22266af54af5aa362e78bfe60b8815d30d06a3" deposit_count: "240" block_hash: "0x6f0584cc8761c8739652bd61a2e7c6f89e6a3e0c748b8555f6c900d566081bad" block_height: 241 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" deposit_root: "0x8e9055eb4be6187b776047300d22266af54af5aa362e78bfe60b8815d30d06a3" deposit_count: 240 execution_block_hash: "0x6f0584cc8761c8739652bd61a2e7c6f89e6a3e0c748b8555f6c900d566081bad" execution_block_height: 241 - deposit_data: pubkey: "0x8202a977e0d543f09f5f4b010fe308031db9c022058591b4ecc22205853f96fab8a906e31659cec3f20c23deced33fb0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x819cac5109e38a3e23be784a0803836ae5892a7ebf529d5b69ec3483f0765955d21453a7c8c9dbd48a67c6f6137484c9125a886a9562a70333f4a4643c2cf0a74899bd1b6f50501b25b73919a81b3a590e432af6d9d1649c484fd58d38a80446" deposit_data_root: "0x3c87bafbdd6e4bd6fd9c9b911859197b0d4e77215d1f0b4a76cb53dfd9a0bee3" eth1_data: deposit_root: "0xfecc08150b61a8fd00bef193f76e8b08a35b1e230a8fbe5fe8386821042dc30e" deposit_count: "241" block_hash: "0xffd46f6cca04a453afaaab6759ce73a0883c43146bd59559c0e3547b03104bee" block_height: 242 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x3c87bafbdd6e4bd6fd9c9b911859197b0d4e77215d1f0b4a76cb53dfd9a0bee3" deposit_root: "0xfecc08150b61a8fd00bef193f76e8b08a35b1e230a8fbe5fe8386821042dc30e" deposit_count: 241 execution_block_hash: "0xffd46f6cca04a453afaaab6759ce73a0883c43146bd59559c0e3547b03104bee" execution_block_height: 242 - deposit_data: pubkey: "0xa6071c891f8c353b0ed693c039c54f8ceaef1862c23904ecfbd88b3ca9180a52d7c4ce95bb9673e98ba6ac93a2d5b462" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8492293596dd1459367cc4ed401f6b3c2dab0c4c58045157a782a359483588f7fc072c8fab68311956fcecca8dca20ad0208bf6106be93330bb2c8f188924827efbf388ed1196f0a36c57751ba9241f9e888287f28c08f6f466f14ae39b7a471" deposit_data_root: "0xfaf043c9b1a28720d15e0878bf714c21ff2f25732db766df36c30f2294edc890" eth1_data: deposit_root: "0x25d55cb11a780617ff862a96f6a5d28b03553d6ad721b3fd9b2a969516092366" deposit_count: "242" block_hash: "0xdc1ba0aeca3dc68376239c9dc4291a18b77e5a6e073c2ce216f78cf916b1bfc7" block_height: 243 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x6ca839b6db690b690cfcecf7cc14423bb1fd7b32d682e21d2e2ac03494a37935" deposit_root: "0x25d55cb11a780617ff862a96f6a5d28b03553d6ad721b3fd9b2a969516092366" deposit_count: 242 execution_block_hash: "0xdc1ba0aeca3dc68376239c9dc4291a18b77e5a6e073c2ce216f78cf916b1bfc7" execution_block_height: 243 - deposit_data: pubkey: "0xb722d39c1d7d9c5ec39961f903efbf7bfd5faa1a3af41749874b52d9a6ecf554b022beebfd42b5d4bc00ecdc726a1c69" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8cd8f6b02f810e9b408185e8d25e0739f91a10d1091f0af98641b558598e8cb0f447f07dcaa702c40ffd3fd50e2fcb1e13fd81b3e6b5541d2c73facd4b1ee023578075d09356b8428e94cf257ebc725b94c13cf383ca033adb26f458477806f9" deposit_data_root: "0x084781b3e9bd75b87361a1f8441b80da9923d7c8668720ad8e5755482ef29649" eth1_data: deposit_root: "0x5e30bf9c714431e60981eb475a64bf5f497cb20bee164b4c2c77fcf330d5cf1f" deposit_count: "243" block_hash: "0x650a223ced62d289d54524b7d13cf38a72a713b7d76a950da2127bb06567174f" block_height: 244 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x6ca839b6db690b690cfcecf7cc14423bb1fd7b32d682e21d2e2ac03494a37935" - "0x084781b3e9bd75b87361a1f8441b80da9923d7c8668720ad8e5755482ef29649" deposit_root: "0x5e30bf9c714431e60981eb475a64bf5f497cb20bee164b4c2c77fcf330d5cf1f" deposit_count: 243 execution_block_hash: "0x650a223ced62d289d54524b7d13cf38a72a713b7d76a950da2127bb06567174f" execution_block_height: 244 - deposit_data: pubkey: "0x98bed18337602301002525627e99e62911e6bc491e2c2bbfa2eef2f4bcf173eb60e493b74e95c3b5256555f20535694e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa30352b10445dccc53569ef6a776814dd6bd35bca75d4960a97108c2ef05e896fc1218863e091e349eafa964df4252cc04aad236601220b9a047fdd8b61cc370514e05c427f83215b19beef3672008bf441e58bc9e848f68617e580d8a3851c3" deposit_data_root: "0x714f0a4796ecb56128e81e1fd76733314b4f8d9876254793390161eed47581ad" eth1_data: deposit_root: "0x58b247bf9a29620b5b3c182f0a579da72ad4126fe2ba57300f6fd58f32aba0e2" deposit_count: "244" block_hash: "0x84da630cce06cc7ab9def7b0e4ccb64c267d8d2be50f211f991cf5e4e4ce6e5f" block_height: 245 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0xa46deb2a2056ceaf788d88266b62aab355e7755244c7ea45646a731284b588b7" deposit_root: "0x58b247bf9a29620b5b3c182f0a579da72ad4126fe2ba57300f6fd58f32aba0e2" deposit_count: 244 execution_block_hash: "0x84da630cce06cc7ab9def7b0e4ccb64c267d8d2be50f211f991cf5e4e4ce6e5f" execution_block_height: 245 - deposit_data: pubkey: "0xb499f66668919d5f1d82e55171c5961e78aaa70e0fab3a2ccf14aa402379ac66e05d542060e550d8a1d03796ce703a3c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb52925ffbd2205903de239cc9abdfba52c6940f45cfc9f8c0d6998c074022c32fefd229d464724fb372a157a0c74bc87015c05f9b331b96b9354a9060a31cb1a92ceab4e91a689e5aa4156c8dbec1785a319cd74d370a3bf86aa56a431033d66" deposit_data_root: "0xdab69f68d68d19729a7255e07d59760c7b6ba098132c4d5d5a1c87af8e5ec222" eth1_data: deposit_root: "0xf1bd510bc2186b7e3cf6246ba45b1a8be2ec957093caa0f825d8d2ee898b11f7" deposit_count: "245" block_hash: "0x958e63436b683ab4d02c33db4495fcd0dfd5a72b445e3274b9efc508d4d797c7" block_height: 246 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0xa46deb2a2056ceaf788d88266b62aab355e7755244c7ea45646a731284b588b7" - "0xdab69f68d68d19729a7255e07d59760c7b6ba098132c4d5d5a1c87af8e5ec222" deposit_root: "0xf1bd510bc2186b7e3cf6246ba45b1a8be2ec957093caa0f825d8d2ee898b11f7" deposit_count: 245 execution_block_hash: "0x958e63436b683ab4d02c33db4495fcd0dfd5a72b445e3274b9efc508d4d797c7" execution_block_height: 246 - deposit_data: pubkey: "0x92c237d7fb491bcf70aa4e50e71b305bcf71bf5a438b0e08f03fc4f74d5c3c9b8c823049e314d15f8266179b1a90841d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa2bb7c6a1ee2ec8368539cccfb5b2a8588e5e479fda223410cd15341dd5c865dd22695a2a0ef27757b2545adf353df0e0b51f9c9c12b19a7fd0e22cacc81c28a0fad805cd19feb808be5ca4867eabee207e2f38e089b6097f66809b04cd41797" deposit_data_root: "0x1cc0cbc5cf5550036124427fca2b43440d4c574e10da612c1b6c583a6febe147" eth1_data: deposit_root: "0x4ba339c19953b83d57a0600cc2a325b4ab96d46eecbd4b6b483d42b6c3035122" deposit_count: "246" block_hash: "0x4194ca1e0c55ccaa492a55535bebacaa185efcc8ab9f5fb8ea60ffd90461d3c2" block_height: 247 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0xa46deb2a2056ceaf788d88266b62aab355e7755244c7ea45646a731284b588b7" - "0xfe1c7788bf7f661ff91503ec1352ef2ba4d8ad3653fe69110da96218c90b32ab" deposit_root: "0x4ba339c19953b83d57a0600cc2a325b4ab96d46eecbd4b6b483d42b6c3035122" deposit_count: 246 execution_block_hash: "0x4194ca1e0c55ccaa492a55535bebacaa185efcc8ab9f5fb8ea60ffd90461d3c2" execution_block_height: 247 - deposit_data: pubkey: "0xa1f2eb8596281b7e85285bcee8a4156140e069c6f50c02a0dd3b0f40ed62b8e15e7b9c40f6755496e13a94d91faaa194" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa3b72e3ec51a30a080e36fb0ad1c350a6f4df753de841d2626581c2f3573b3ceab177708cfe9a64d3c6d243a26df1e6700b014c3f09636bd0911addd3db4be6b8893568c0e1e92b88badec7a7c86e0c0921cb07ad48e3c7f6c27a6c6cb1ea8af" deposit_data_root: "0x571c10a7c40e7c4a5f15db4ff249f1e1b90fc1ed392d6dc2c359de9c887950f9" eth1_data: deposit_root: "0xc8f68085a6d6b9ea9ab9389235e301c66d605c6a1648e659e512d10a340f6dad" deposit_count: "247" block_hash: "0x86ca50c675d6f26df298aec00b900a9693d04a765494714b8a2c6da02d310338" block_height: 248 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0xa46deb2a2056ceaf788d88266b62aab355e7755244c7ea45646a731284b588b7" - "0xfe1c7788bf7f661ff91503ec1352ef2ba4d8ad3653fe69110da96218c90b32ab" - "0x571c10a7c40e7c4a5f15db4ff249f1e1b90fc1ed392d6dc2c359de9c887950f9" deposit_root: "0xc8f68085a6d6b9ea9ab9389235e301c66d605c6a1648e659e512d10a340f6dad" deposit_count: 247 execution_block_hash: "0x86ca50c675d6f26df298aec00b900a9693d04a765494714b8a2c6da02d310338" execution_block_height: 248 - deposit_data: pubkey: "0x8f4d945fafc936414122945190a1983192259705205fa3e92b72443a93183eb140ad527d4b1449507a18cd64764c89b8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89f9fb93f365aa814e9939d47d12e479a941b124428a3ea45ff751b336fbfc4e918be34e1f8e1006f011a1182f3fa4530ffd887727627586a9d090ba05c5f035a69fe7da7f3747d9018eff61f281ebcef266db93e508b22273173d7e59337234" deposit_data_root: "0xd752ab6ab4c095111b65b97cef47817f4ce89cf1025672ca33053c1c5cc8e856" eth1_data: deposit_root: "0x9888c051a7c8320f413b98a66f0f4d86d2161c649550a898f3a05d547072e2ef" deposit_count: "248" block_hash: "0xab019baaf509e52a456129c7b9628360234c5c99d73059d5f3a6f1c320affeec" block_height: 249 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" deposit_root: "0x9888c051a7c8320f413b98a66f0f4d86d2161c649550a898f3a05d547072e2ef" deposit_count: 248 execution_block_hash: "0xab019baaf509e52a456129c7b9628360234c5c99d73059d5f3a6f1c320affeec" execution_block_height: 249 - deposit_data: pubkey: "0x98a8e7af1994e3d8f383dc4ee6d32a01077694ec93ecfd7ffbc5cd9448938a6c6d35cbbbe8e01a49fa4782f389757b06" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96b654ae3c1bbef1c62c4dbb5ff4a174dd66d699660b3fddb0393dc3f8b675611a8f7c92c9d64a55c70c59c81ec61d9c0630b6609ee9185b075931251f5bfc63be9b5741cd1bff31d08bf63232ea95a3652ddf2012932c617741afb9417c1797" deposit_data_root: "0x1b3ff046f35984553c7bc5e78b4ef9633fbd4955e81438f836224ad1a35537fd" eth1_data: deposit_root: "0xa1477aaa9d366844c18a57e9c0f5281dbc35d8a27c7178e36a78943f2af1f4ce" deposit_count: "249" block_hash: "0xefe08745ea4a98e988389f4896dec09001efcd92fde1b157958b2a7b5bea1e1f" block_height: 250 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" - "0x1b3ff046f35984553c7bc5e78b4ef9633fbd4955e81438f836224ad1a35537fd" deposit_root: "0xa1477aaa9d366844c18a57e9c0f5281dbc35d8a27c7178e36a78943f2af1f4ce" deposit_count: 249 execution_block_hash: "0xefe08745ea4a98e988389f4896dec09001efcd92fde1b157958b2a7b5bea1e1f" execution_block_height: 250 - deposit_data: pubkey: "0xa7c051843950c482ea373ca3aa30e523911ccfe061c681b16fb8a35ec6e4ff0ada5a25fb2ae70433b18913652cc3c181" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x98eebdf73162c70581f7325614bb7110c6cba9351ca1dd4e275557a9cf71ac8fcd64071791780806cee2e37c18f98e2313e8adfec420bfbf20b35a79cfad2eddcd664a557b3b566437f567f1a5a03deeb48b0c0ce31ba57531f594ca8317fe2f" deposit_data_root: "0x357d15b4cce193ddfc397cdd46ab0a749f8a579ab81cd19f1100e041b1147c57" eth1_data: deposit_root: "0x11c2be42ec7670fab1675225953d5079ce0571d96393b911904526f6be98cf25" deposit_count: "250" block_hash: "0x65b114ab411f03138a6610b8edf979ba983e536afb438e62fb80ffffbc3cf124" block_height: 251 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" - "0xcf504f082f480bc2de32cc4c299b0fd96b1ed6919af3b090f0a9f3f3ecc10430" deposit_root: "0x11c2be42ec7670fab1675225953d5079ce0571d96393b911904526f6be98cf25" deposit_count: 250 execution_block_hash: "0x65b114ab411f03138a6610b8edf979ba983e536afb438e62fb80ffffbc3cf124" execution_block_height: 251 - deposit_data: pubkey: "0x8f14a40f502a87214891c922345fc2abc6795c28d72f9deb7ebffd7b805888222f7b1d479db1142ed013902987394cad" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x85f4239f73421ff5d28f31481729632e20bf4ed4b3ea0a91961dec198922dc1be61be0623b85365dd6db9cec094dad9217683da190c4be92b5d1bb00491314472e3a412f13d651c4c98f054219e621538c9465cd42fd2851950e0ac9a42e62b0" deposit_data_root: "0x5be2cc49961bb2f24b8e89e5e9bacc33efb9cb9f9a455e1bb91fff7bc5b6656a" eth1_data: deposit_root: "0x0df7d0d38d74a5cb89be95258e7c60ce0b9200342553536b064f33ea923255df" deposit_count: "251" block_hash: "0xb243d9ace275e844a2335d262010f8b3cf19d045bc930d89bb6e6ec738865cb6" block_height: 252 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" - "0xcf504f082f480bc2de32cc4c299b0fd96b1ed6919af3b090f0a9f3f3ecc10430" - "0x5be2cc49961bb2f24b8e89e5e9bacc33efb9cb9f9a455e1bb91fff7bc5b6656a" deposit_root: "0x0df7d0d38d74a5cb89be95258e7c60ce0b9200342553536b064f33ea923255df" deposit_count: 251 execution_block_hash: "0xb243d9ace275e844a2335d262010f8b3cf19d045bc930d89bb6e6ec738865cb6" execution_block_height: 252 - deposit_data: pubkey: "0x8e486d8c9ca07b6c4dc1181161ab52508b70980e9af31c97286b55be3df3701d73891bf0aecc6eb7d2e028572bb5c25a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa87d84736b8a674718e17bcabfd512e8a6ccb52eaf11776e2aaec8cb0d9bf91fa59b46b3c21a0023443a9911ba1f6e9f192e18b88ea8cc96362a537f98bac4de9883e4a8b46ce99f8c5407b4fa748a9bd6c438ea076b8eff66a34c43243f1030" deposit_data_root: "0x94423ecf41a112308585b194e910a68273a90cb12434e82d0cd936a3b92309c9" eth1_data: deposit_root: "0xabdddf0fbff2f71cace266b85d33a05b0621daae752c693fe9027725d863a1b8" deposit_count: "252" block_hash: "0x8c746ea8ee851c0ce8552221531374c1a73ca48d07c2da85ad95328836cde732" block_height: 253 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" - "0x5ba7e2c0ce36932281840d77f2cff6b2fc9b10b24953346e039e8d0576ba01d8" deposit_root: "0xabdddf0fbff2f71cace266b85d33a05b0621daae752c693fe9027725d863a1b8" deposit_count: 252 execution_block_hash: "0x8c746ea8ee851c0ce8552221531374c1a73ca48d07c2da85ad95328836cde732" execution_block_height: 253 - deposit_data: pubkey: "0x91402ee72dd351a735017f11da3176ae5fce3e92369972d0eee22a45d1cc2badd77f627c4a0a9d9c480d65464442599d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa1eb19f9f0c9fe4962b82a001fe8c99c3ecf7b2133202c655275af9ba4581d7715abafb9d9835340a14c52ee7a1a449c0ba1d35ad7bb6ab37fe54d05c644a577c5b86ef3e036c46c0c4ccb3829205e0b4c717d2392abf2ac92e770747643c26a" deposit_data_root: "0x00c52950b4b8050d147aeca91703761b297e5d91ab496ac1161f1fef79f7528e" eth1_data: deposit_root: "0x39b19f70b06e4cdaa2c3e1c87ef0b8039022ac99b00d68deca929ae4f7ba95f6" deposit_count: "253" block_hash: "0xc0d6735edb092ab85379457c91496c754307a70cab6e50494f858ee371eb649b" block_height: 254 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" - "0x5ba7e2c0ce36932281840d77f2cff6b2fc9b10b24953346e039e8d0576ba01d8" - "0x00c52950b4b8050d147aeca91703761b297e5d91ab496ac1161f1fef79f7528e" deposit_root: "0x39b19f70b06e4cdaa2c3e1c87ef0b8039022ac99b00d68deca929ae4f7ba95f6" deposit_count: 253 execution_block_hash: "0xc0d6735edb092ab85379457c91496c754307a70cab6e50494f858ee371eb649b" execution_block_height: 254 - deposit_data: pubkey: "0xaa5b90007d36de7c57235756d39aac060ee48e8a910f0a0c815e71414a0d53e7b0659242079253fdeb32ad18ab90beb9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x85e04b0dd29327c3b6509673add484f5236e2fc68e0d3411f7ac5070b5d171b8800cf366a8cc632d9e9b9ea49bad527f0105dc4600d55dff610464d15d70c1103218824db85b2c13a898279e777f843cb3c32afea2ab7dd46494c942fc857da2" deposit_data_root: "0xeec4762f004c245237202597a1172ba2594a24318eab15dc61519909d761035d" eth1_data: deposit_root: "0xcb2db903b62421b1add0e3747dff29b0eaa2046f7e8aea0c22777804c1931533" deposit_count: "254" block_hash: "0xb3df67d8050a51998dde8c9c9a2ebb92c608018a2c32b1bb4835769bc7303160" block_height: 255 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" - "0x5ba7e2c0ce36932281840d77f2cff6b2fc9b10b24953346e039e8d0576ba01d8" - "0xc9bd7dd686e17ced16ded792dbb1565f93d9d01b2e551b237d8674891756d761" deposit_root: "0xcb2db903b62421b1add0e3747dff29b0eaa2046f7e8aea0c22777804c1931533" deposit_count: 254 execution_block_hash: "0xb3df67d8050a51998dde8c9c9a2ebb92c608018a2c32b1bb4835769bc7303160" execution_block_height: 255 - deposit_data: pubkey: "0x851faec0a50c3df9918d1ab44fe7f63f8105d671d8fb83f3a59d291e6d4dc86cf47a6e9402973bfbd7db535b3dc4350b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xabf53104df47484b8c876216dec49ae4c6805c0c7c866fb3794f0699db316ef4e60ed588cd3a2865217db953a640fa61118325f454eb4d2768f2372bc8325b5a979a722faee2bd818d9bf944c89abbefc3328441ecdcbcab2a9f0830bad57a3b" deposit_data_root: "0x3fe14e2e6126bae3261e24ff9119ea5b74664a19426da0d091193ae3bb736dd5" eth1_data: deposit_root: "0xad9929ce3da3cccb228d8f69211d8493147a6df93daed02e410bcbdecbeaca60" deposit_count: "255" block_hash: "0xff6935719c772b51352c991341ff30606fee102d3dfd07859a2930212e75800e" block_height: 256 snapshot: finalized: - "0x5424209b0511223b880af7362d8fe72bc0f268f4aa37dbcced5b872a30a1265e" - "0xbbe623353e1418ef9492c6e1ca72e9a73bc4d28b00d17bae94476c70ae774043" - "0x8b839672af192e30144c2c46a2d14842b4620d58405e9094689262016f3b1ff7" - "0x15e5ab79d2e91316abac7981530e445f4c70332f1628d1883a21d17a699c1b4e" - "0x151d5a637c3241cca69bf3658d39f77db74646866a4dc1a1d762fbe89eb8f459" - "0x5ba7e2c0ce36932281840d77f2cff6b2fc9b10b24953346e039e8d0576ba01d8" - "0xc9bd7dd686e17ced16ded792dbb1565f93d9d01b2e551b237d8674891756d761" - "0x3fe14e2e6126bae3261e24ff9119ea5b74664a19426da0d091193ae3bb736dd5" deposit_root: "0xad9929ce3da3cccb228d8f69211d8493147a6df93daed02e410bcbdecbeaca60" deposit_count: 255 execution_block_hash: "0xff6935719c772b51352c991341ff30606fee102d3dfd07859a2930212e75800e" execution_block_height: 256 - deposit_data: pubkey: "0x933dc2f8d407d4f85a1d54953ac47a89c19808eca0d38b0ec85b376ce17c3ef1edebb518a4dce8e976155cb6561a849f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9694a8b0268e018870eb146f9d2a4dda7b9c341b4c82a73d950101d534f167fc0c8d902f37f9589c056108b1b6a3d41a0d815100b4db1232c4393e5f7bdbb23925aa043d68f95ba7b4edd2d4e58465ec63aadc831f99eb06278e067fc68325c5" deposit_data_root: "0xb71c9023acf8ceebefff85ec63ced2d0a535e3af465941895e0679b0fc692f0a" eth1_data: deposit_root: "0xd49c9ff7d98a8d5cdab9ddf57c558dc9d203d282d7ec7faa5c7d11aae81b790f" deposit_count: "256" block_hash: "0x1fe7203f9539f6116aabb762433e3ec9692de44bdb1342b1b1653afc271b04b5" block_height: 257 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" deposit_root: "0xd49c9ff7d98a8d5cdab9ddf57c558dc9d203d282d7ec7faa5c7d11aae81b790f" deposit_count: 256 execution_block_hash: "0x1fe7203f9539f6116aabb762433e3ec9692de44bdb1342b1b1653afc271b04b5" execution_block_height: 257 - deposit_data: pubkey: "0x8f7069f51912347df8b721903bd9340ff49e9d436239ea0f4f176e360c4a91aede7657037ae00dcb08a9d7abe9b48d5a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x833313916a5da51c5ba85ecb314c687384faf62db7872fd000ca32a0ee7f4778bb2e5f7a5f4139aac884a7f4a0a1c40808a766bd7acb02c5ee4d6ead05a622b6d20a818649ed08c41afe600e1710f1b5532aee603618c828ee50cc62dc51f964" deposit_data_root: "0xb7292e597a4316db41b1ee81280941feb78554bd77861d9b4e4ee85ceb83f536" eth1_data: deposit_root: "0xd254aeef26718bb674401e75886471ce4a088120fab90318c6e55d063aa04a3c" deposit_count: "257" block_hash: "0x1df4e3eafb6484a050b5168586d648e4191d90ecdf846800fd0b41ddde11edbc" block_height: 258 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xb7292e597a4316db41b1ee81280941feb78554bd77861d9b4e4ee85ceb83f536" deposit_root: "0xd254aeef26718bb674401e75886471ce4a088120fab90318c6e55d063aa04a3c" deposit_count: 257 execution_block_hash: "0x1df4e3eafb6484a050b5168586d648e4191d90ecdf846800fd0b41ddde11edbc" execution_block_height: 258 - deposit_data: pubkey: "0xb876db47bf1d1868b3a39cdba4171adde47eae91b3631dcb5c59d28cb100ecda604a446ffcb000448c462d72526ebdf1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb7302e880887ee702f55cc3fbfa2a8ec3b422317eda123538723588e7119d6111d80457a3805912bd4f07f16cb71c32c09a2bf0ade7ca11fa2303136bcd493c8b8a7c7fff3b94be38684b019cb515d4759574323015b9d53d0c92ce374a5311d" deposit_data_root: "0x40f31b70761cdda3e491f945fcfada69d0d985503e705ff9e0db0fde1d58c7fc" eth1_data: deposit_root: "0xd5c029480bf22b310991b6964481ff2e3e156e9d9a39556026ef809cf282d77c" deposit_count: "258" block_hash: "0xbc87b56c9955290b90555dfdfcfe36d95abf388b957b8b004ab7aa8682a48c26" block_height: 259 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x33caef79ba14b442d517fa8bc4c617b1a5c595ab103f2baff90a65a7f03c8564" deposit_root: "0xd5c029480bf22b310991b6964481ff2e3e156e9d9a39556026ef809cf282d77c" deposit_count: 258 execution_block_hash: "0xbc87b56c9955290b90555dfdfcfe36d95abf388b957b8b004ab7aa8682a48c26" execution_block_height: 259 - deposit_data: pubkey: "0x9666598b3eaade229b7b255866d279009ac0b42dc55cbec207f3842d51501e2fcd318ce7d2fc40a766382703c8a0ef00" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x960b98ed5f4aec48beaf813e61048411a345de0d5b99593d5017f7a18651567b7d3038e4665fd186c868a4b4b8da865f175ef0158fba21bdf10c0890cd1fa32dc3105da9f295925b96d090516bace0c6e9a168206a21a11b30f8fefce22fbb5d" deposit_data_root: "0xc0a4d26a15ce052fbb2873df1b178b41192e4cdeb45895acf94f55d5d58636c9" eth1_data: deposit_root: "0xda795c832687a92b18a304a4a68190b021082edac866a12e283b6cc4c3eee27e" deposit_count: "259" block_hash: "0x2ec63ba8ef1e86b8428bb223e6aaed2e3193f59a65de1ddaaeb3cbd96653530d" block_height: 260 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x33caef79ba14b442d517fa8bc4c617b1a5c595ab103f2baff90a65a7f03c8564" - "0xc0a4d26a15ce052fbb2873df1b178b41192e4cdeb45895acf94f55d5d58636c9" deposit_root: "0xda795c832687a92b18a304a4a68190b021082edac866a12e283b6cc4c3eee27e" deposit_count: 259 execution_block_hash: "0x2ec63ba8ef1e86b8428bb223e6aaed2e3193f59a65de1ddaaeb3cbd96653530d" execution_block_height: 260 - deposit_data: pubkey: "0xb2b4c1b1777970826b6683ceed5b72da7bec1f6f7cdfae6a599ae0d0d6d912098678327ee31fe383fc2b95bfed48bfce" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa0495982b6c281a33c67883658f6c32a94268ede93853331bae3e492f71ac4514f05b0e89ffddb1e1a8dff4b83dc807219c69ac11d5a2515c845023c566dca7dbcde3ca08855dae961242680efe3f84de27fd04ee3d8c580bacd625ce1618f7a" deposit_data_root: "0x6944628944cbac12207257df3a7d14936c9bc8f267eec1e24d18543b00b9c413" eth1_data: deposit_root: "0x7db45a47b3b9ef4cf211c695fe5682e6e79078b72f4b758d7db497ef4f3c7abd" deposit_count: "260" block_hash: "0x2d162a08fa97029565b3f57c18af38429a5a4a3f7deefde7b843f481fb7fd0a5" block_height: 261 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xe4b758cad7a082639814a7aae047e94921d416986d98b6dfcbc234966bc973ef" deposit_root: "0x7db45a47b3b9ef4cf211c695fe5682e6e79078b72f4b758d7db497ef4f3c7abd" deposit_count: 260 execution_block_hash: "0x2d162a08fa97029565b3f57c18af38429a5a4a3f7deefde7b843f481fb7fd0a5" execution_block_height: 261 - deposit_data: pubkey: "0x91cecc34498496a68dc7630a6184b1cd7b977772a94d7d704c64284cdc14aa3f4d7c6eadb3bf62eda1a43f2f8d547a2d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa2e8b32322fbe08e071a3100c7f55efa12fedb60e61d10adf35599ad6dff551e7cb22f16882c76e5a5fc03cfbb7cac2916770030f9049ab5075e8371745bfeb58d944bb0cfd9ec44e29e57ab441f96fad3b71a42ed1a3f7a8f13107a5e09ca8f" deposit_data_root: "0x709db664502b7eb538adc5890972def651e1e2c0f4fed2b14b473022f3676bf5" eth1_data: deposit_root: "0x36baa65b71d95dada8a8da1cb67eb6656fa616b6645db7870b07060afdfcbdb4" deposit_count: "261" block_hash: "0x771faf677259330b1949d0d57781f6ae7745117adb1f2c748b42ba20ec3c599d" block_height: 262 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xe4b758cad7a082639814a7aae047e94921d416986d98b6dfcbc234966bc973ef" - "0x709db664502b7eb538adc5890972def651e1e2c0f4fed2b14b473022f3676bf5" deposit_root: "0x36baa65b71d95dada8a8da1cb67eb6656fa616b6645db7870b07060afdfcbdb4" deposit_count: 261 execution_block_hash: "0x771faf677259330b1949d0d57781f6ae7745117adb1f2c748b42ba20ec3c599d" execution_block_height: 262 - deposit_data: pubkey: "0x89dc8480e9d48c7e5a39c3ced17e65170f56f86a96e4bb131e88c3d6eda3daa65265df5445e0ce52090cf34d7fd1116e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x945d9ac700cadcbad052484acb2eb9702915bbcfa44222866ece07891edd00d8ce873f17704412e338f39893af82ce54115bd1e184b11cdfa51937164a1d3576f359c14a903ef669a016cc5398e9e5c6af03730ea0534a737f8457c237141f36" deposit_data_root: "0x70c4d026dc4ce6566e02ddb3085517df6d5c742910fe7a36500d76e7badf82b3" eth1_data: deposit_root: "0x05fb7d7e57be47dd87666d6198c4e197ae9fd0922fb4100535592ac7e0900bab" deposit_count: "262" block_hash: "0x132a1b9db503b80713fc5a34717cd51069fa6f145340ffee8c0b283c8c2e0606" block_height: 263 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xe4b758cad7a082639814a7aae047e94921d416986d98b6dfcbc234966bc973ef" - "0x6cf83a85c4c666e9efb82ff97d8cf8fd2d6f4442b0c6c7e029dcf8ae80c981df" deposit_root: "0x05fb7d7e57be47dd87666d6198c4e197ae9fd0922fb4100535592ac7e0900bab" deposit_count: 262 execution_block_hash: "0x132a1b9db503b80713fc5a34717cd51069fa6f145340ffee8c0b283c8c2e0606" execution_block_height: 263 - deposit_data: pubkey: "0x8219db7b86441850836ae4e27a030e8378e594e5f1d7ee08dac7bc054653d178e6949476887c83a20a213b2bf39e16f7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c53a5ea1061f892c20cf93c1b97c42250908b3e299700090713f36a45421c619b06570d18e2b96168e71dcaafb820bd17331ed302480153fb48a685d679c829ea12e7c93ee5999aa0812ba19da8b8c60899b980401fb17312ae9db58046ae20" deposit_data_root: "0x819ccfe405e7220a1d9c053a8676a88332980aef5215f5076f1a3f5033235532" eth1_data: deposit_root: "0xcca4cb084ab65bb8629ae4dcc8b2fcbe56db2cae8859e206c4da24a4014d139a" deposit_count: "263" block_hash: "0x27aa5166ec5f9d13e6be7009abc9114701756eb96a5a9110ca40a3e593b0fc27" block_height: 264 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xe4b758cad7a082639814a7aae047e94921d416986d98b6dfcbc234966bc973ef" - "0x6cf83a85c4c666e9efb82ff97d8cf8fd2d6f4442b0c6c7e029dcf8ae80c981df" - "0x819ccfe405e7220a1d9c053a8676a88332980aef5215f5076f1a3f5033235532" deposit_root: "0xcca4cb084ab65bb8629ae4dcc8b2fcbe56db2cae8859e206c4da24a4014d139a" deposit_count: 263 execution_block_hash: "0x27aa5166ec5f9d13e6be7009abc9114701756eb96a5a9110ca40a3e593b0fc27" execution_block_height: 264 - deposit_data: pubkey: "0xb9ea48794c02725e69d9f6435382b31b3e975de5ead999a09e13746e0ae5a63115af3a3043cd71ebc94c9b051b5b595e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8964f0aaa92e1cd2a2e0df07b02766725afe98d100e863fa5364feaaec05c4159eb6efd5d9409d47ab037a5fdc41ba5300ddd8f1626f81b384a6a3793a70a5bcc8c4361c19540bf923cf6f2f5058832f8c188fbff56be3141d24fb9abd829561" deposit_data_root: "0xca07d9e3d7bab36f22f9362f73c6302b8c8fc9c41ee856fb2c0fde28702d6672" eth1_data: deposit_root: "0xf051452baf67b48585468b8af81fea65efe163d4752bc57fe502dedaebc9595a" deposit_count: "264" block_hash: "0x7c9c165d2d0ad76293cb31edc3195d7de80f5cff9d5ba5bbd9bf0f384dff028e" block_height: 265 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" deposit_root: "0xf051452baf67b48585468b8af81fea65efe163d4752bc57fe502dedaebc9595a" deposit_count: 264 execution_block_hash: "0x7c9c165d2d0ad76293cb31edc3195d7de80f5cff9d5ba5bbd9bf0f384dff028e" execution_block_height: 265 - deposit_data: pubkey: "0xadae379b50e15e5f80810abfc544eb28e26301438cfaf8a8a5569f9bfd76c4e653d0da710bb5d34687d47669f6999257" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa56c12741c2b28f868708a31c9cde178d724fc2da24acc2538f54068937fb2d7e76cd4bef53818af4ab71908f3feeb0d17527506fed49643fab936ee040061ec66bd43ae9dc1e414d9ff03f7392a9d26daadcc789117c2e66596c2235fd98f8b" deposit_data_root: "0x6449a8db47ed59b97b28d2cdc174f12232041fc3231f388d48cc5ed141ccd2a7" eth1_data: deposit_root: "0xe077d704ae5725c0d46ff39053c1ae7e15b456333bf520cefdef620ac331c134" deposit_count: "265" block_hash: "0xeb71722b0fe110a64ecccdb9ecba95d7fb7b7c832086cd5bc67e25196be9232f" block_height: 266 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" - "0x6449a8db47ed59b97b28d2cdc174f12232041fc3231f388d48cc5ed141ccd2a7" deposit_root: "0xe077d704ae5725c0d46ff39053c1ae7e15b456333bf520cefdef620ac331c134" deposit_count: 265 execution_block_hash: "0xeb71722b0fe110a64ecccdb9ecba95d7fb7b7c832086cd5bc67e25196be9232f" execution_block_height: 266 - deposit_data: pubkey: "0xb451fc2c4236ca2393853980019f5da0e5f7d93df90bab1ae34ddb583d0ce3cdece25f23bc1736e065a1f2af1ee2bd34" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x93bcb192ee34cf2cb34310583c6ed82b12baa1388f5e85d3e74ef7c9dff413f69f00eff132a686eb786f33bd918fc8870ee0337447202ff82024b20ac35bcd931c34869d33f9e594da910891722146b65e3858be3f6142d1ddafcff50f159b95" deposit_data_root: "0xf6e781e7f4285fb05464464c41580de16dcd370ae346a5462bb5791d38808f89" eth1_data: deposit_root: "0x91a3cef7fd152d3aab06e1f156a428c7f3b19697a7bf32bcbf076c37b4379230" deposit_count: "266" block_hash: "0xb87c760b0c73bb51052f5a77555e27d38ec417e21af5851664153cc71ea1b7f2" block_height: 267 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" - "0x48170ce125065a69a3020c11a7f1aa34ecfaf772a3a13be6737bcba5157f2553" deposit_root: "0x91a3cef7fd152d3aab06e1f156a428c7f3b19697a7bf32bcbf076c37b4379230" deposit_count: 266 execution_block_hash: "0xb87c760b0c73bb51052f5a77555e27d38ec417e21af5851664153cc71ea1b7f2" execution_block_height: 267 - deposit_data: pubkey: "0xb8c6b853d7f3766c881f4eb0c9986b800188b9f9ab40a492d49e64e8c1e98cefc27ecfe225ff9d5781c0193bca2f77e3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xab4f31e234441c6eb8fc1f41628ff056226de0b0b3016bb48e2d02eb41ae39f7774bf6c6bf7f8e5088504d962e2045fb0acae329fb2e80eea51f332b76cb2f1d08339b6c230c6ca47b4837f5ebed0c087b51c0c29154e5c4e0b587a0a304cb03" deposit_data_root: "0x1e826f811c943eec59894f7b90ff11deefdcc1449ee3dd9186a01e14e07f6c15" eth1_data: deposit_root: "0x480831312704cf1ebb18ce99d3d5d14aee83c31dee4a7768dc84b8f44a8f815e" deposit_count: "267" block_hash: "0xf65f73d8ffe1df07acfa02b5297f43c4652c159a3cfcdd3bb9f3f1bac7d7ce98" block_height: 268 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" - "0x48170ce125065a69a3020c11a7f1aa34ecfaf772a3a13be6737bcba5157f2553" - "0x1e826f811c943eec59894f7b90ff11deefdcc1449ee3dd9186a01e14e07f6c15" deposit_root: "0x480831312704cf1ebb18ce99d3d5d14aee83c31dee4a7768dc84b8f44a8f815e" deposit_count: 267 execution_block_hash: "0xf65f73d8ffe1df07acfa02b5297f43c4652c159a3cfcdd3bb9f3f1bac7d7ce98" execution_block_height: 268 - deposit_data: pubkey: "0x923b10adafbd70ac83cfde90a85bd38e5e919348285b311e020721bc96adc9e9b7e45f8052d1b3ef97301947cbc6d3e9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb8dbe590fe70f90ffcb0e4d7156fb9a763e0a5812a18fb900eb224dbfc1006ea53fe2995beeb8c68de87186093102daa072044fa2c7599d0ddff864035c094435b4bd4159157b8c5c2bb68b713313c33daed3f059742bf74bf9ee140996a8030" deposit_data_root: "0xb230a394c34aa022260b632113aac600d6adda8c634e99c4a0ca133d01ae895c" eth1_data: deposit_root: "0xa94dd2d608ad39920b3d4d36983bcf3fcbf847bfba0fd6efb0f9392538d9508b" deposit_count: "268" block_hash: "0xf02da506c532e1e1fd10587045c93575c15526820e5ceacab2119c401979948d" block_height: 269 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" - "0xe199368557ff186641e9a7d5cb05acac6d482b97df62a1011f0b9fd5c03f5734" deposit_root: "0xa94dd2d608ad39920b3d4d36983bcf3fcbf847bfba0fd6efb0f9392538d9508b" deposit_count: 268 execution_block_hash: "0xf02da506c532e1e1fd10587045c93575c15526820e5ceacab2119c401979948d" execution_block_height: 269 - deposit_data: pubkey: "0x8860a33d75543d49ad04bdcffdfdf7fcef7228076d4e8150d80c3cda14651963544a683355e256166d995dd3f6b4ad35" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x986c60f5e748e02284435fdd37c2a72a5247e0784ebc99677490e9095f2665b1685a16d7dd48261c922897faa2273fc6030db1b871f208a56e20602b337ef10921b8a3164b128fbfef2566fc0db86c27f392eaddf4745aba700d9a69af3d0ad7" deposit_data_root: "0x1c37b6d2caaa5c7bb785e5cf0f444edc230bf9836cf1c8a27f1a0c5665c50c37" eth1_data: deposit_root: "0xd021c86513c1fd866c766cdedb99464a5c9a2abcb4f6a5563ccd8178cc778b0d" deposit_count: "269" block_hash: "0x27cdcf3f09175210019c23eac0ac9309bfd56a6654eb9523900ae387500fd99e" block_height: 270 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" - "0xe199368557ff186641e9a7d5cb05acac6d482b97df62a1011f0b9fd5c03f5734" - "0x1c37b6d2caaa5c7bb785e5cf0f444edc230bf9836cf1c8a27f1a0c5665c50c37" deposit_root: "0xd021c86513c1fd866c766cdedb99464a5c9a2abcb4f6a5563ccd8178cc778b0d" deposit_count: 269 execution_block_hash: "0x27cdcf3f09175210019c23eac0ac9309bfd56a6654eb9523900ae387500fd99e" execution_block_height: 270 - deposit_data: pubkey: "0x805de41e2e03f52993f465c0cba3886c40488c0ebe7fbbbe65f016e5e6ff971efe2968e09b0d62263cde4c70f6cf8540" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x830ed2435dc71a80676f51b674be560ecd4d7f0b7d2328ccfee8bc207f4480fac75aa62926c2665a00cfdf2a9b5f18cf00313aa3eab4cb83f3224417cbe42a1591ba0260afb464481391930abfb206db57230757da96e033d25ad57ca15cefb3" deposit_data_root: "0xd00dd9ec8defab31ac1699c60512ddb92c0b66fdb722eeb8f889ce3f9a36e198" eth1_data: deposit_root: "0xf20d2b6626fa9a2412b80217d55810beaa23b9d42c0a386624fc99f04622d1d6" deposit_count: "270" block_hash: "0x0f3d50198252da6bcdd9fa7a62accd5b21e2c3236ed4434a6e30ecfa9a31c349" block_height: 271 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" - "0xe199368557ff186641e9a7d5cb05acac6d482b97df62a1011f0b9fd5c03f5734" - "0xc68746b2b174136c95a60d0312e6eb45b1d289447eeec15e7126fcdf8a85da9e" deposit_root: "0xf20d2b6626fa9a2412b80217d55810beaa23b9d42c0a386624fc99f04622d1d6" deposit_count: 270 execution_block_hash: "0x0f3d50198252da6bcdd9fa7a62accd5b21e2c3236ed4434a6e30ecfa9a31c349" execution_block_height: 271 - deposit_data: pubkey: "0xa367b7c50ce66726561d5f4190607e9c1d3feab41f624b9ecfadb6f52e1b300ef98e8913e8fffb2b65cdbb889ff5fb6b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x918fe57e516de9e415db3fd4f1a78843da0f6f76b71ab4ec9d8f91bea748fcab31a90e25b22d69e98cf83f43502cf4ac08a0cec4a3e7aa21d5b876b9728b079c0640becf699ff07b023431d6f872561c7e35f86e15d3abe0c9b2bbdc452fdad0" deposit_data_root: "0xa29deb39e17dec8af0ce7d25156ecabd1ebae33d3076a29b4ea8d8b127335672" eth1_data: deposit_root: "0xe92c7ae8c37c06c234eed3d64804cec30984b01ae852511077750a8e5ce8e9e2" deposit_count: "271" block_hash: "0x4a4ae702e70fa102e90e05e95bc8163f7cee4224b9a8ade2c97c4ad04d2f104c" block_height: 272 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xa175806ecd8f45f5b8a87219a9c345e9e612bcdfc850bf0b51c2b6a60813d7e3" - "0xe199368557ff186641e9a7d5cb05acac6d482b97df62a1011f0b9fd5c03f5734" - "0xc68746b2b174136c95a60d0312e6eb45b1d289447eeec15e7126fcdf8a85da9e" - "0xa29deb39e17dec8af0ce7d25156ecabd1ebae33d3076a29b4ea8d8b127335672" deposit_root: "0xe92c7ae8c37c06c234eed3d64804cec30984b01ae852511077750a8e5ce8e9e2" deposit_count: 271 execution_block_hash: "0x4a4ae702e70fa102e90e05e95bc8163f7cee4224b9a8ade2c97c4ad04d2f104c" execution_block_height: 272 - deposit_data: pubkey: "0xaf379c89e4f4bec6b942c9e2d8fa6ccd2ec13cf421d80c987af53d5217c932483c4ed17cd1a9c9d7174e2546ab16ebb4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa49410f5cc90cc268e78c2afa27c8cf129f4da16397953dc383e3eafb1e797faa9bb0e9649502829df2c2cf2b7cd715d0d8be34d1e8cc2706933290ce42bdd8bc1a1bcbab9defcdbb0e85309ca92a7c7c0df00b1ba01dd13e74834ff17788d0b" deposit_data_root: "0x677f04382b7df90d9e30533f0fea1e1193e6a71e0f3d2fc6621957b406a2d39e" eth1_data: deposit_root: "0x734e5eceb4244b23ed80e4a9d91f6830c403c9e37a27c8501368ddc1b9bc1b25" deposit_count: "272" block_hash: "0x615eaf0c08bbd375884ea9de1f7261253ab51971c2b1d8407fa63982d4d6feae" block_height: 273 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" deposit_root: "0x734e5eceb4244b23ed80e4a9d91f6830c403c9e37a27c8501368ddc1b9bc1b25" deposit_count: 272 execution_block_hash: "0x615eaf0c08bbd375884ea9de1f7261253ab51971c2b1d8407fa63982d4d6feae" execution_block_height: 273 - deposit_data: pubkey: "0xb6c5b136625178a485ee2eba1ddadc84b55e42c0e5a7ebfc8e5e2db651baf3c0a7cff6fb8e94dfccb1ca0a0d48b7496f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8dba1b2ce9ddb0488fbd27b8f0e760844e5242b4a70d188a0fe5e7602161ca591f09b3ddeae404795f02df26930d00e80ef42e30d4d09fd5632c9dde165519725ff4442dc3eb9d86056a5afbe401a5568674ee6f7dbc7f1ef9d5e7e8ec6d4a74" deposit_data_root: "0x984f88c7b8523c5a9c9268002fa51558131645074051f28869233e59bba2bb64" eth1_data: deposit_root: "0x0b1169b7908d522037d597df82f0e4821a3f141ae329527275e975e1f06b44f3" deposit_count: "273" block_hash: "0x9a12613dd49a16c089530e40aa1c8f06f77c852479a90a28387d068d5884ba45" block_height: 274 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0x984f88c7b8523c5a9c9268002fa51558131645074051f28869233e59bba2bb64" deposit_root: "0x0b1169b7908d522037d597df82f0e4821a3f141ae329527275e975e1f06b44f3" deposit_count: 273 execution_block_hash: "0x9a12613dd49a16c089530e40aa1c8f06f77c852479a90a28387d068d5884ba45" execution_block_height: 274 - deposit_data: pubkey: "0xac210cfd8d8d9547120ba0a786a93318beb172471e9711b764db71376898bc28037160396e32be311a1823e585e8f524" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9917a489a4d766025fe21104187d687a191ab135e68f44282e597ab9bee1197d4cd037d59051d36197be3854c2429964138486367635adc03360ac053251a06df519237d2fa0b72b8540feeb5bb5e6180f137bbbcdc250aa191a62fb9294f33e" deposit_data_root: "0x6d90c6f3641efb6dce19f2efb93fc24439111dbbcc6cdcdf60a2f4c0019af2dd" eth1_data: deposit_root: "0x9604fd80f34acd50e4b641e866a440bfd4697939c358ac3bc91bf25352a8057a" deposit_count: "274" block_hash: "0x439db7c4143f986853029b0ce493c55804bf4a38e08c9f2bbc19ff22b1a185e5" block_height: 275 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xafc140dc42b75f6f96d56352af93e6d41d56ab68fe4b90981a6ef2aca4a11b4f" deposit_root: "0x9604fd80f34acd50e4b641e866a440bfd4697939c358ac3bc91bf25352a8057a" deposit_count: 274 execution_block_hash: "0x439db7c4143f986853029b0ce493c55804bf4a38e08c9f2bbc19ff22b1a185e5" execution_block_height: 275 - deposit_data: pubkey: "0x8771e8df435244648533c638f725d292deaa9ef3e098ccce30255f860156f9101aea2ab56199d5a8cd2042af7ea57e33" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x813560e954b791856c97ff6bf3bc645f75d58e88a405d804957362b901ff360f625839be68c9c612da31cac55f41b7d009dd46e7847de8ff5c78594ac44dc2a5c91ff1330e1f44e3c8398e44a0021e5508afc438bc3f2d88fc9fee40b6171386" deposit_data_root: "0x6cab9ec916767574e8a430f9d5eba9d27c0a90902ca458bb94ce0f50c6d6ebf0" eth1_data: deposit_root: "0xd55236a200b36a4aa5e760c3135bd62b4ac05255ee43580b5d5bf16322ac92b2" deposit_count: "275" block_hash: "0xd095a783f5860659c4fbd8e22b2bbb739d9fe8b974da64831e52c4839bc2f8b8" block_height: 276 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xafc140dc42b75f6f96d56352af93e6d41d56ab68fe4b90981a6ef2aca4a11b4f" - "0x6cab9ec916767574e8a430f9d5eba9d27c0a90902ca458bb94ce0f50c6d6ebf0" deposit_root: "0xd55236a200b36a4aa5e760c3135bd62b4ac05255ee43580b5d5bf16322ac92b2" deposit_count: 275 execution_block_hash: "0xd095a783f5860659c4fbd8e22b2bbb739d9fe8b974da64831e52c4839bc2f8b8" execution_block_height: 276 - deposit_data: pubkey: "0xa3c94a3ec9d463a4929513b426cc91887c7e09fd038314ada8e5e7a8ce204a7a20247319f91c0746de0e241550aef4bb" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x99b1d155a15927ce6ca47e70b7ded4d286509f134e2c58a85595e7bedf9eb7d27408cf7638df5cc64969ee5a502644d20486af547bf3518937fe1253259f9d0bb2e509b1c6b1b0f8510950345522a82927de2d8191aab3bb4bb0ec1cb94a03f9" deposit_data_root: "0xe237d745c0911cc07e84746c0e519b09b08b97b06b530a9ddc4e887d53bf8b81" eth1_data: deposit_root: "0x5df671c2350221cbf76630d9cf5d5ba52a568e846e24a45f2631a577507011c1" deposit_count: "276" block_hash: "0xa5113dab93745a4a0e8e65ef5f666109d653178cc86cf033bbdedffe8de244a0" block_height: 277 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xd2f50982286bcc1b17c7402df3f3c8e5ccb7ac8516cae8783aa22d003b1838ce" deposit_root: "0x5df671c2350221cbf76630d9cf5d5ba52a568e846e24a45f2631a577507011c1" deposit_count: 276 execution_block_hash: "0xa5113dab93745a4a0e8e65ef5f666109d653178cc86cf033bbdedffe8de244a0" execution_block_height: 277 - deposit_data: pubkey: "0xa647de716dfe7d82e529344bf832f2ac603d7067a515ebb7148fe69cc4330c1c12d3caaf16d6df3a3483574d49a296dd" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x93620e7602b38582df7080d48213f86a395186fe16197167e99e8c555d0a7a2f8b818bf2cc884608059212ae1090fc21135cdd2285e1a96271dc200bae45d68bc30a6053a68c5387557827685bdc3717b1754a22473b9193b2ed08fe12936e4b" deposit_data_root: "0x454bf4695084db5d52745a0c0fcf55d46b16d40fd982c40df3e64ca30abf2eff" eth1_data: deposit_root: "0x2cb46c5f7addaa0c11d5f2a617f116ee53714804de67624d12aaed20ee03e07d" deposit_count: "277" block_hash: "0xc16cb9437067b34e14b0db82231c2466967cf85459de2d923b92fc39afedbcb0" block_height: 278 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xd2f50982286bcc1b17c7402df3f3c8e5ccb7ac8516cae8783aa22d003b1838ce" - "0x454bf4695084db5d52745a0c0fcf55d46b16d40fd982c40df3e64ca30abf2eff" deposit_root: "0x2cb46c5f7addaa0c11d5f2a617f116ee53714804de67624d12aaed20ee03e07d" deposit_count: 277 execution_block_hash: "0xc16cb9437067b34e14b0db82231c2466967cf85459de2d923b92fc39afedbcb0" execution_block_height: 278 - deposit_data: pubkey: "0x97dae6c47e2b695734163c4e12ff709e7d63879fda8192ca26a35501dce45fd8748b5ed04519e829d61e5e7a3e379dfd" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8419026bb209d08a2db619c23985a483e4a42af20e10715893985ee289a000c990c4f33693780a3640ded33dd21fd2200781677f590164d65528a4f1c047443e619930b7a3ab3be00e7a6c0df70fa505da34862fb9a539a531c237792dc0ab79" deposit_data_root: "0xdd6f4ed981c18b7b2e7bb2f4e0688708fd069d405b0b087315ff02eefe2984c5" eth1_data: deposit_root: "0x3ecdd5c5beb8def23312392aae577b8950c66c902af8bf99de73b96656be003b" deposit_count: "278" block_hash: "0x8bd6fb2e4d0410f8eae7eedcffbc2f9ae0e0a31b9dc9d6de94b0bf7668691eb1" block_height: 279 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xd2f50982286bcc1b17c7402df3f3c8e5ccb7ac8516cae8783aa22d003b1838ce" - "0xd795029ab5b69d8e37a9ff4be1b60af4cf9805d75bb3e2b61fa05fb9decb98d4" deposit_root: "0x3ecdd5c5beb8def23312392aae577b8950c66c902af8bf99de73b96656be003b" deposit_count: 278 execution_block_hash: "0x8bd6fb2e4d0410f8eae7eedcffbc2f9ae0e0a31b9dc9d6de94b0bf7668691eb1" execution_block_height: 279 - deposit_data: pubkey: "0x897c752e1ed45c3ab22146fe595fd08175a828c69e1e3243e6e1e644792b0bc979924123c0cca7dea405b074e214880e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xafd9fdd20324edeeb6283b1a45e7178f6419260b0581cd71ea46b392d6ddb5ee3b7dcef33bf889f401e6b78c5d3766370f25200d87ace14ebc81992a6c0c7552bced661cf33b1ec285d89ebe94c7159e0f0d78543e1d1362789e54729bce5834" deposit_data_root: "0xbefaf00ec4412758aba9bbd73a7a8f4c56dec0523ca462ae5dc6c1f553100248" eth1_data: deposit_root: "0xa3e6322b128ba1eb9cab42f9e9de032e5ef934e3395e3c070c2e3877a9262640" deposit_count: "279" block_hash: "0x00ed7d8bb7cdd6256ac0d7f1ad7b9e34302d9e119e9db4078fbb19b8d3541685" block_height: 280 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xd2f50982286bcc1b17c7402df3f3c8e5ccb7ac8516cae8783aa22d003b1838ce" - "0xd795029ab5b69d8e37a9ff4be1b60af4cf9805d75bb3e2b61fa05fb9decb98d4" - "0xbefaf00ec4412758aba9bbd73a7a8f4c56dec0523ca462ae5dc6c1f553100248" deposit_root: "0xa3e6322b128ba1eb9cab42f9e9de032e5ef934e3395e3c070c2e3877a9262640" deposit_count: 279 execution_block_hash: "0x00ed7d8bb7cdd6256ac0d7f1ad7b9e34302d9e119e9db4078fbb19b8d3541685" execution_block_height: 280 - deposit_data: pubkey: "0x90e6673aa3258396ea9b5e5d4c53b076fc93d4f408008343e44f5d4e49e408942c764d454b435be080ed8e4328ddcf1f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xad7a438ba41385b1078bae963e814a92e922a83efebe6aca14ce1a0a1754ec7d882211ef71ef55bcaa4d87e75b20f9b611837e28ab711d1874863a151a5ebfee310b649ce58aeee5fe7809dbf813a0d1e5786cbcf9286fbb6d649939c781339c" deposit_data_root: "0xdc9c1d97e917f6e25ae888d726fca078b28921a5bb9f1ea669ba53b18caaa5c0" eth1_data: deposit_root: "0x7b3c923bef540d0db79619c5bfb8a2abf74f57c23a1cfd4dec6410feacb6b943" deposit_count: "280" block_hash: "0x0067d9ff3bd86de63d54114d41770e5b0cb7c8c5120b19530eab3d3bdfe79836" block_height: 281 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" deposit_root: "0x7b3c923bef540d0db79619c5bfb8a2abf74f57c23a1cfd4dec6410feacb6b943" deposit_count: 280 execution_block_hash: "0x0067d9ff3bd86de63d54114d41770e5b0cb7c8c5120b19530eab3d3bdfe79836" execution_block_height: 281 - deposit_data: pubkey: "0xa7f7669994d4503c6390a44e7b64103861f78d60283580e19d0898948ed55a0b16b6c8fcd86e14341fd9a5974e4eda5d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x837a5a91adc8bd9b06a5b116769ad796b673f5230741af2e8ce61d59c7f3eb80b1a896f36af0f7b1d72c612cdf51eec7154395d1cebf833e0329d4ebc118a0708b2d2429d13324157ee8056eba25c5e0ff6a3b4212c19e437666151de56a0e46" deposit_data_root: "0xc760b2ad57feef344b258de4d1ecb020fc392a45187f5aab606d97a308a63ebd" eth1_data: deposit_root: "0xa06cf7368dcd4b336a8769c80e7ade8ef0d8900f5abe104cececdef2a22f73dc" deposit_count: "281" block_hash: "0xd67c87e9d0958db9609fdb7e4a3246578abbbc9e36517a6c224196c1d726207d" block_height: 282 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" - "0xc760b2ad57feef344b258de4d1ecb020fc392a45187f5aab606d97a308a63ebd" deposit_root: "0xa06cf7368dcd4b336a8769c80e7ade8ef0d8900f5abe104cececdef2a22f73dc" deposit_count: 281 execution_block_hash: "0xd67c87e9d0958db9609fdb7e4a3246578abbbc9e36517a6c224196c1d726207d" execution_block_height: 282 - deposit_data: pubkey: "0xb8ad8a758c02b9a1769a5f883a41eee5a516165cd2ae19749d60ff634f1175940ea569244830265b2f59b2aeaa434478" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb55d9ffeab85b135b7e21166db97d4defbea12b1beebc795a694062cfcdc5de3db44e1810539c8b22bbc2a930b4cc0fe102a8b233c45b958a7db52b28bcbe9192e191b967ba76f9fce60d4bd30ebfcf0c156b298ed99cbf1df359da8f9b089c7" deposit_data_root: "0xd224e7399aef34aebab912dd931e8029d849a75e46d52d3e7af7ef795089aba5" eth1_data: deposit_root: "0x41e107ab1e7255ca23c4f66b6afaa812e789a822664683cf158c481a32a62e10" deposit_count: "282" block_hash: "0x8e6819b492671a514f3da060880e5379b0b42de61df7089d479d883c2f25e4a6" block_height: 283 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" - "0x5f703e4b8197692608370e14e3f2f2ae87e4817939d05d095009486de7ebe0ed" deposit_root: "0x41e107ab1e7255ca23c4f66b6afaa812e789a822664683cf158c481a32a62e10" deposit_count: 282 execution_block_hash: "0x8e6819b492671a514f3da060880e5379b0b42de61df7089d479d883c2f25e4a6" execution_block_height: 283 - deposit_data: pubkey: "0x95037a05a0a6a90acadb5cc2156117378faa1c1eb79cacf3b91835e268d7855960e638dc34bbc192cc6b8ca6b942be04" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96ffe4fec99f4e61dfeddeb4e0ce1db5d3f2ec1c7b5608a27dbea3a684705aadd979a4c48ed703904b1afdab4ec410e717a8d892b8c881d95fc0cea3df434f4a2a736b75e12cbfa65354d1452f1c1494679b0c2f82e0278bac0e727cca54ae5f" deposit_data_root: "0xa84635d4c80545e945a05b992bf4e018466bf90ce77efbc6c4afcd86e7c40480" eth1_data: deposit_root: "0xf45ea7c111196d94551e75f4827dc54da7b27159b61f0157001cc501e449ab11" deposit_count: "283" block_hash: "0x208b9d89c955086f385701344c89f0f7f36d8a12f8126654ff46fffac19738cb" block_height: 284 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" - "0x5f703e4b8197692608370e14e3f2f2ae87e4817939d05d095009486de7ebe0ed" - "0xa84635d4c80545e945a05b992bf4e018466bf90ce77efbc6c4afcd86e7c40480" deposit_root: "0xf45ea7c111196d94551e75f4827dc54da7b27159b61f0157001cc501e449ab11" deposit_count: 283 execution_block_hash: "0x208b9d89c955086f385701344c89f0f7f36d8a12f8126654ff46fffac19738cb" execution_block_height: 284 - deposit_data: pubkey: "0xab152bc78eada258d68785ad491422f64ffece7e462ac59ba92ca919f6e2ecb3c3707b34d6159a967b4dd7590c4321e0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa62cef8f23182080da9f5566785c5f614bb68b7ed2480551ff248ba0ff398af1125437bb1703598a3726757e6aa242f30c73e7f1833a07e3944fa370bb35a17bca08a6a65988a8cca0cc544489bebc4f7089ac288694483aa3f0d14913d11bde" deposit_data_root: "0x7a9db3084c5390172ef580652bd82ec524081fa698d216f8680acddf3598b5a9" eth1_data: deposit_root: "0xb14450ae34030b8e3b7357bcd9b403267d507c15e5006ee4df1d5fa5dcf8dafc" deposit_count: "284" block_hash: "0x705a548444db8857275b1e4daff4e049715ba5c3cd31e9c9ea40d7aa767f76cb" block_height: 285 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" - "0xd2b6e86410a770e340ffb7de6ee5cf863a85940c79573f83f25f86aea119f640" deposit_root: "0xb14450ae34030b8e3b7357bcd9b403267d507c15e5006ee4df1d5fa5dcf8dafc" deposit_count: 284 execution_block_hash: "0x705a548444db8857275b1e4daff4e049715ba5c3cd31e9c9ea40d7aa767f76cb" execution_block_height: 285 - deposit_data: pubkey: "0x847230d7b775a10cb13cbe8b80b7d2e5e613043af2913729fde2404485cb4dcff11fbb08487c860125c9d4828686818e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa97dcbec769d32f79ab1ffb179002460cf80afd587cd7f19c6f8761af07a8819cd82a64d82917e208dede5fdda3392e008516c97578f0fa1f56201f010b00e3a7dcde2d8ce22cd02d24663540889087ba0f7011af978035591f41a26b00d4455" deposit_data_root: "0x71aa303f97c1545130a878320efceac5ac755201d7435beb0a6a5bbbd9f76432" eth1_data: deposit_root: "0x89e2e3db69c005b9af9f2f52537e98e4d99b15078574bfbb0542230f161d7bf4" deposit_count: "285" block_hash: "0x70ce0316c6eb65c0b81f178a0f234dd62a88b9f1f751b77974158bc26cd78152" block_height: 286 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" - "0xd2b6e86410a770e340ffb7de6ee5cf863a85940c79573f83f25f86aea119f640" - "0x71aa303f97c1545130a878320efceac5ac755201d7435beb0a6a5bbbd9f76432" deposit_root: "0x89e2e3db69c005b9af9f2f52537e98e4d99b15078574bfbb0542230f161d7bf4" deposit_count: 285 execution_block_hash: "0x70ce0316c6eb65c0b81f178a0f234dd62a88b9f1f751b77974158bc26cd78152" execution_block_height: 286 - deposit_data: pubkey: "0x811f122742c9f58ceff4b9b75ef59d8a8b5553313c027e18a21f417206d72b66d225c30d9f9f5dbb648d68e537a95cd8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8d64c45dec8fd9624e5a673b4be330985f42fb04e32ddcb14f8463e92c8534e8c9dc7ce6dd324d9e46d08535d67024bd0f3d2eb8afe1c571969f7054eee365376b6ef65dd2d79aeaf4b9e065fab99a08f54f7aa4eaa608f542be51155c97c943" deposit_data_root: "0x8c2d9422f7f6da9f58a22bf2958c28614b38612f6599a09dbbfb3b6b05a2c9de" eth1_data: deposit_root: "0x39ed089d07634871eab8445a2e27720f969a75194f7e739b28632596d51afd4c" deposit_count: "286" block_hash: "0x0ad81ac5b5624db6ae564e1e55a039c9ff07abbfad8541f36b1499a38e34ff01" block_height: 287 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" - "0xd2b6e86410a770e340ffb7de6ee5cf863a85940c79573f83f25f86aea119f640" - "0xd8e36fc1ec59065a6d776496630ecf9de9417b10f4fba2873ba760bf445dfe59" deposit_root: "0x39ed089d07634871eab8445a2e27720f969a75194f7e739b28632596d51afd4c" deposit_count: 286 execution_block_hash: "0x0ad81ac5b5624db6ae564e1e55a039c9ff07abbfad8541f36b1499a38e34ff01" execution_block_height: 287 - deposit_data: pubkey: "0x875b740b7de5cd6db43823c3dabb3e0652b132a2b0c7593383420f31c452c3e772885f083932eee347c94ff2411367fe" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x870a4c9e1e8bad7573ca85cf96c85fcee530e3918c0fd5231945d44b93668b09dfe394fee7df5f34641f9a2100d7f8c100758148ba94822633c24ce5c8abfa4922f9dc83ec659a471cb791d2c8f50bb63879125bb240da3f3ddf073034022974" deposit_data_root: "0x95dae1cb1d3ceb2b954761d7e3994dfcf890f0af2d932c8ae16a0305f4172e7c" eth1_data: deposit_root: "0x091a9d9c1cb63e60b98a645f4b92cb819e69c9d72a1a22bbf4ce0aab06fd8f4e" deposit_count: "287" block_hash: "0x0a2ee6676a0013c27224c31e35877a9f41c87bfcd451d50a496f62094cdddf59" block_height: 288 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x004f564bddfe12ca7aeb4708f48538e1d5fe4b3ad2c8b08be819236aa2c67ec2" - "0xb96037b213deff69adf6fc2ef3ff23ef01b2a19f085f6cdc4395ef55d13f1eb3" - "0xd2b6e86410a770e340ffb7de6ee5cf863a85940c79573f83f25f86aea119f640" - "0xd8e36fc1ec59065a6d776496630ecf9de9417b10f4fba2873ba760bf445dfe59" - "0x95dae1cb1d3ceb2b954761d7e3994dfcf890f0af2d932c8ae16a0305f4172e7c" deposit_root: "0x091a9d9c1cb63e60b98a645f4b92cb819e69c9d72a1a22bbf4ce0aab06fd8f4e" deposit_count: 287 execution_block_hash: "0x0a2ee6676a0013c27224c31e35877a9f41c87bfcd451d50a496f62094cdddf59" execution_block_height: 288 - deposit_data: pubkey: "0xacbfea617a3cbc5df59da38133fee49b25a4a27aee878184acbd8cad6c72a2ffd5cf31812e4ded11d7a73c6c7a9a7cb8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb261f12cd1af634ddd037f62c1930120938421469681c3e4ad8abed21ba550a1b60d91fec994000e28bd880da3de709c0af2408c80150b438cf318791dc169983785152bed21b01117f698ee6853bf23948501289e4ccd63d7d87b70d82484a2" deposit_data_root: "0xc5c4f40555719fb6d08ab90de29f01a80adde2ede7f5a2338ec0ae24980480a6" eth1_data: deposit_root: "0x313a8e2fec006ca89b4e20c0945b2f7ba336aed9695b4b03bc06608712cde390" deposit_count: "288" block_hash: "0x7895648d903ca4cfc86649eb22f8d1c758141f8d3aa89f938f2f25016481435e" block_height: 289 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" deposit_root: "0x313a8e2fec006ca89b4e20c0945b2f7ba336aed9695b4b03bc06608712cde390" deposit_count: 288 execution_block_hash: "0x7895648d903ca4cfc86649eb22f8d1c758141f8d3aa89f938f2f25016481435e" execution_block_height: 289 - deposit_data: pubkey: "0xaae696196c2730c93099a70860ca5efa86f84e5841e05aaeab2619a772f23eec46d4c72a31b0e458c85409b511b498a3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa99138f2331c3cf13064847011cece90e314742f897c5a629912cf2339ae8e2ee5375bd3a2bd33e164a03b3adde0d40f0243c57233e12f7d5f61328bb6f4e2516bbc784dd6fcd3ca814cb8658499516267b4b1aed34eee7dfcc1b9920efcbe4c" deposit_data_root: "0x844286999134010ba50c2a62fbe3af61cb39b66dcb6c74fbd58a9aad32331c73" eth1_data: deposit_root: "0x1aaf2dc02a54384847050da49a834ff3a3474b4419885b2e37092c885c2a5764" deposit_count: "289" block_hash: "0x74d07cd3aacb5ed6004cc7a76696a60a64fd2f8a1367d1070b3e9e70316cbc58" block_height: 290 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x844286999134010ba50c2a62fbe3af61cb39b66dcb6c74fbd58a9aad32331c73" deposit_root: "0x1aaf2dc02a54384847050da49a834ff3a3474b4419885b2e37092c885c2a5764" deposit_count: 289 execution_block_hash: "0x74d07cd3aacb5ed6004cc7a76696a60a64fd2f8a1367d1070b3e9e70316cbc58" execution_block_height: 290 - deposit_data: pubkey: "0xae0825786e4f5ada18f212b067a394b52e60b37c98bb22ccdf0416d27b33029678de976370eea92c384ae44bca79386c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb27632627c427944c2fc88f3cf387c3ae3b01bcbdd66fca2e0342c8d99608e86943a7f85783609c2f52bca77c4c703561734b382e423db9b639655ad298c1278d906259b9d73d8a050e78ce06433a6ad5c0e18f22edfdd6e59f8bcc4eff47262" deposit_data_root: "0xd4fb8486399925af6ee9cb0675686bf197754b6115bb082560b529ee4b0bc6af" eth1_data: deposit_root: "0x799fbeae76281fc3802633b4e9cf0e96fccd7cdfeef10763f38d71a9362264f1" deposit_count: "290" block_hash: "0x7394bcdc109326766ef4bbbc9a79a2e3a0ec7ca68af666caee2628105e29da04" block_height: 291 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x7705b49fc5157cced1429cc52e57d903c5bef2f85f33041d5cfb966557058b7c" deposit_root: "0x799fbeae76281fc3802633b4e9cf0e96fccd7cdfeef10763f38d71a9362264f1" deposit_count: 290 execution_block_hash: "0x7394bcdc109326766ef4bbbc9a79a2e3a0ec7ca68af666caee2628105e29da04" execution_block_height: 291 - deposit_data: pubkey: "0x95ef906a741f50b59bf8fb77c134abc0534fbe7d0c432832d2d1c0ff9bd20090b424df54ffadebb9cc43e5f3812a7968" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x86e9c1163ad77136831a5a21680ae3b20e22ea656c108e3db81c698526b2a0f453df4b18c563a6491b4b627f8885e79611a4d5b71a2c2dc72812fd0219314c4ff2cd561cb8acb01fb6b03dc4052b7bcd5231053cbcb28d47da3e6bb3442b5018" deposit_data_root: "0x6edb20c206b0c315233ef2716988f6043c49f1a557b934ca778841f252256d33" eth1_data: deposit_root: "0x87c3659d83ea26cbde44dcc3b5b4c4afab70c1c3c1345cd11514aa7a325b66f0" deposit_count: "291" block_hash: "0xcf1ebd89ed9130987c74ec2d4af8d83006364bf28784baaadd4c169ecc03ac75" block_height: 292 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x7705b49fc5157cced1429cc52e57d903c5bef2f85f33041d5cfb966557058b7c" - "0x6edb20c206b0c315233ef2716988f6043c49f1a557b934ca778841f252256d33" deposit_root: "0x87c3659d83ea26cbde44dcc3b5b4c4afab70c1c3c1345cd11514aa7a325b66f0" deposit_count: 291 execution_block_hash: "0xcf1ebd89ed9130987c74ec2d4af8d83006364bf28784baaadd4c169ecc03ac75" execution_block_height: 292 - deposit_data: pubkey: "0xac3a33ffd0eb0ecdb7baf1a5a4d8fdbd7c2e7558aa073269d2f9b7e9e5c7a1402c30efdb34fd7d268ec5f64db92a76c3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xad36e7b3da78886b41f5e61ad0bec7a5a7f68fb9b6d5bfd0ba5b75c59dfc6ada6b33da3729215c23122d812abc4e8eda06f88f7e414e79224eefcb4bae2f798512cab1cb96f5f1c1ed5e8b81c97967098a3a38b96a1bb2e19bbc819de9342342" deposit_data_root: "0x7e435b81ff4fcb487b26cff3b131c5453c05d167c6617c8865879b51bf8fb04c" eth1_data: deposit_root: "0x53252143b0ff828eec2c69855e5ca87dd5153f5df8a7a24603031e62fc7a2980" deposit_count: "292" block_hash: "0x1dec0f6cbd0fdfaeb411d008ff1b21c4cab80e38ddab4385464828921e8903d7" block_height: 293 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x0730794fdc9fa73177b77e150edf2e164ec8d1917f76a71e085eefdaf0bd3835" deposit_root: "0x53252143b0ff828eec2c69855e5ca87dd5153f5df8a7a24603031e62fc7a2980" deposit_count: 292 execution_block_hash: "0x1dec0f6cbd0fdfaeb411d008ff1b21c4cab80e38ddab4385464828921e8903d7" execution_block_height: 293 - deposit_data: pubkey: "0x8b1d9ba63bdc005529f0f6e2f442e6649adcec11e0db1d643b3d3e09307cc8c5b3fb84049941b8692f10799011c246c9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb331295d92ea1dde46a7149810b7348a1cfc004b760326a35e61c95afde55c3e1c9798b3e94d8dc8b8a4101746600b470d2b693074eec42f90347e22ddb6dcf539de7b4c9d0bc2ad6d21e59d81228831df635658789f3d1dacea605ddc391719" deposit_data_root: "0xaa148346b9b8d2c5c24672977c58e8c35edacef56bfd81028f3fecba2b2442c5" eth1_data: deposit_root: "0x34e1e67726ccca66adad1c4d54baba739c7c52955a01b7cba29c3d8f2317f5e2" deposit_count: "293" block_hash: "0x5808234c115cc61500e2a564049a17037ee5108aec392d429f03f58ba8d16443" block_height: 294 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x0730794fdc9fa73177b77e150edf2e164ec8d1917f76a71e085eefdaf0bd3835" - "0xaa148346b9b8d2c5c24672977c58e8c35edacef56bfd81028f3fecba2b2442c5" deposit_root: "0x34e1e67726ccca66adad1c4d54baba739c7c52955a01b7cba29c3d8f2317f5e2" deposit_count: 293 execution_block_hash: "0x5808234c115cc61500e2a564049a17037ee5108aec392d429f03f58ba8d16443" execution_block_height: 294 - deposit_data: pubkey: "0x8f9ec3c7b0f5793f3056fee53b16af2874bef12a90bd0ecf6282d55ce6ba70a07071df4e3861ad99da8753677a2a74a3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa81d1bd6fb813b55c286bae7e79f9ad080e65865bc0c34f8309876e22f1db6e06b87abf4b0fbda1ade851d0914f8c4270d2abb19efd831a116a040180a9eae89daa1ef6a69748984c1b8029d33ed4e278d26226833a0d05762f94c389b758b83" deposit_data_root: "0xea2af2f7a4f8409ff112a26b16f36e6192581fd5c633f90b165668999c1f9e1e" eth1_data: deposit_root: "0x21ec4811b4490a5d9c97b40830607f18ed6decc77cafc3328b487ea076ec4520" deposit_count: "294" block_hash: "0xf86216620bf16f8591322c0b32fe4c594de559b382aae1c535be72771d8dba24" block_height: 295 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x0730794fdc9fa73177b77e150edf2e164ec8d1917f76a71e085eefdaf0bd3835" - "0x7bad1e86995476e6d8c7a8a05d659145ff02c84f1b0eac70e5964c395c14f8e3" deposit_root: "0x21ec4811b4490a5d9c97b40830607f18ed6decc77cafc3328b487ea076ec4520" deposit_count: 294 execution_block_hash: "0xf86216620bf16f8591322c0b32fe4c594de559b382aae1c535be72771d8dba24" execution_block_height: 295 - deposit_data: pubkey: "0xb083923ec58581ce049677eb0df25ff6ea0e29938881a9e03ecedf4c7482ccd25dbd2f8a15d6bbdf8eca74a74f444e40" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa7ed5863f832a1b984ce9993b33cdded121815178c70538b0926a3f17452142ba546cb751861f739c4303940664348f908ab344bee4e62aacdf26d25ba25cb32b1269f3fd2defd2b740788f2000021c07f0ac20ed927745641f3ea74464ff433" deposit_data_root: "0x450d67be526c8cc2dc5b23a24ffbd79a03dc5b4e9685285e381e598bb478b958" eth1_data: deposit_root: "0x331ae72b1a07010b6967e88090dcf730d1c721b54900e636c7bcf23a4b511e7b" deposit_count: "295" block_hash: "0x5e382493002589f3487d5ef95d6933de04c0b65a592691966854d900eaf32f74" block_height: 296 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x0730794fdc9fa73177b77e150edf2e164ec8d1917f76a71e085eefdaf0bd3835" - "0x7bad1e86995476e6d8c7a8a05d659145ff02c84f1b0eac70e5964c395c14f8e3" - "0x450d67be526c8cc2dc5b23a24ffbd79a03dc5b4e9685285e381e598bb478b958" deposit_root: "0x331ae72b1a07010b6967e88090dcf730d1c721b54900e636c7bcf23a4b511e7b" deposit_count: 295 execution_block_hash: "0x5e382493002589f3487d5ef95d6933de04c0b65a592691966854d900eaf32f74" execution_block_height: 296 - deposit_data: pubkey: "0xa41e4e990ba7effeb504f4f0c27924c90c76ec433f2cc59d65619ce9796b80db1b2a6c3fdcd3a3b5ae798c65433ff911" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa3eb87a76711659f7821c30c915d68c8853d948e1ca08da89c5f20b390f1c65feea7374c2040b3bbf9c6496af37afbaf09ef6a060d5370a06318053d845a4aaf99e82852a8ccb4dfab2ee3980f8cfda07b08dfdca5c15ce73a67fcd4d5979ca7" deposit_data_root: "0x056b0a462a8e8ab1f9cd2d1a3428e3a102de98b075968c605d95bb65dd516095" eth1_data: deposit_root: "0xc16e10784846d8fdd7bb158f065db835af24031e348baeae33ae24ede22ec3e1" deposit_count: "296" block_hash: "0x8ffaa2662024d089a5006527ba28bb380b041cc2e81e2421d4deaededb9d3d61" block_height: 297 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" deposit_root: "0xc16e10784846d8fdd7bb158f065db835af24031e348baeae33ae24ede22ec3e1" deposit_count: 296 execution_block_hash: "0x8ffaa2662024d089a5006527ba28bb380b041cc2e81e2421d4deaededb9d3d61" execution_block_height: 297 - deposit_data: pubkey: "0x8fb481a72fde68d6b21d0f679bcf64c9986e88acd27874cdfb4d2ae7a84e7dac89ca6afd072bdc503b15342ddc899b94" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83f4b1f8e47b6c688f1068e9ecfe223b53090656d44396b24f7192e6fd7cdfd66f96760b8fca2b01c57e0c01c323952008d6e33dbb0fbee95c36dda724fbecfb07dd99ce251bce32d22e2ce36bc45b9e59ffec6ac9aa2e67a94953ea1deab2c4" deposit_data_root: "0x8bc82d0cf82a2499dd2b717cfde2c3e68bfc128763e250a4fb50e3f0122accf8" eth1_data: deposit_root: "0x1add0cbc74e152fa595c6dc87e2d5df9699025429dc658682c635977d03fcd6a" deposit_count: "297" block_hash: "0xf305397aeec554ea12622d5b37c601710070c0f4856e2b0170856c55f80e07a9" block_height: 298 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" - "0x8bc82d0cf82a2499dd2b717cfde2c3e68bfc128763e250a4fb50e3f0122accf8" deposit_root: "0x1add0cbc74e152fa595c6dc87e2d5df9699025429dc658682c635977d03fcd6a" deposit_count: 297 execution_block_hash: "0xf305397aeec554ea12622d5b37c601710070c0f4856e2b0170856c55f80e07a9" execution_block_height: 298 - deposit_data: pubkey: "0x9792ac6f48e8f90fdabf06dd862bfa48612c72685f259f7f69ce201889daf43e220bbe3795554d1973b497360b81311d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83ed426c80869348bf799aece915aa4c3ecd715df0d83c443758db8d74be8dfec2707bb8cd41a65117b7f484998f59d715cca0f03903248374af59f3013d9a0ea7ec0dff855c632ad47c695186736c62ad52d3c0131f5227bd8d2a977e4b574f" deposit_data_root: "0x377acb0a185e15e235bb479f2c7a6eadcdebbe04e96282510656c1c8643c8f08" eth1_data: deposit_root: "0x90beacf75d211ca5fa19ea7a78d25c2e9a72a9b59652192d5b37368a66d7f71a" deposit_count: "298" block_hash: "0x141e6a356ffe9bce0d90886c27b5460df7ad03c69635cf28c3a3ffa99dd524b7" block_height: 299 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" - "0xc60a40ade74fa8bc78d964bb75dbe9e361b8468980dcf4ef30f5712a8e06f20a" deposit_root: "0x90beacf75d211ca5fa19ea7a78d25c2e9a72a9b59652192d5b37368a66d7f71a" deposit_count: 298 execution_block_hash: "0x141e6a356ffe9bce0d90886c27b5460df7ad03c69635cf28c3a3ffa99dd524b7" execution_block_height: 299 - deposit_data: pubkey: "0x8db6b709638a90a292ecc760d425bd26855a8b67e34286987f3c6aefa0811573e106f54b088b3afa8436156fb36f783e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xae4ead5a15f81287a7c7c20d4265d95345637980d27bf0d8edfdb1d7ca2099c9283916e09eae340be93f7db49d76d89b19ae467cecc02bee4d8f47a82a9609db4ed4f5c915c910babbc35d885799b6d6e5e70b9025a6e2e192f8dabe61109028" deposit_data_root: "0xddc96174c52bb3bdd22b83e73bda24cafc7203e6166d0ede60c079a367d5ac08" eth1_data: deposit_root: "0x31dae0097efd30f99ca3f1582a55545fc31326f4046ce06adce7b926155b60b6" deposit_count: "299" block_hash: "0x34c74dd45b01879ff4a0508fefbf6fc9adccc408bffa5cfe13e68655115226e0" block_height: 300 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" - "0xc60a40ade74fa8bc78d964bb75dbe9e361b8468980dcf4ef30f5712a8e06f20a" - "0xddc96174c52bb3bdd22b83e73bda24cafc7203e6166d0ede60c079a367d5ac08" deposit_root: "0x31dae0097efd30f99ca3f1582a55545fc31326f4046ce06adce7b926155b60b6" deposit_count: 299 execution_block_hash: "0x34c74dd45b01879ff4a0508fefbf6fc9adccc408bffa5cfe13e68655115226e0" execution_block_height: 300 - deposit_data: pubkey: "0x93ad251e308b778815f925a6de6b11bb7f3d4d8d710cafd66cab8be0b91ef0ada350c2ca2d8f5fbc3ff4f002445680f9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa3cf73c28799277452db8bb4e7c5944f029c8228321a655325aac140baf67884f24dd459356818857341088afda6828b06149d514d5b2ff3caf8993ed07129b111798a35a9dc28f526752e6002cee205127893ceea458afb5da8698d0eb4902b" deposit_data_root: "0xa01227f9122459ac47d9a6b110e72f74ea18ae68b62ca95a0b76bb4166269eda" eth1_data: deposit_root: "0x8c2f6e57502350b5d9f26e44419267b541ad91471cab8d5db5ff4184f5bb33a0" deposit_count: "300" block_hash: "0x193c858804c50b4119d959c31820b38c2beb2bc36f0e0595213c4030cac59626" block_height: 301 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" - "0xb8f534205d4b218cd717bddf06a06cae872d995a165506cff2e8c12af6a71afa" deposit_root: "0x8c2f6e57502350b5d9f26e44419267b541ad91471cab8d5db5ff4184f5bb33a0" deposit_count: 300 execution_block_hash: "0x193c858804c50b4119d959c31820b38c2beb2bc36f0e0595213c4030cac59626" execution_block_height: 301 - deposit_data: pubkey: "0xa31e15bea68f0f555e2eb0552f74bb78a755ee77e242799cfeb8a380507d994cf24f46fd86568f46c4ecc7ddcf359ba6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb3e700ee6b7fcd21fe53dee2c22d4da8ca914be0adebfd496396edff50068679a17410d9afbcfffd5f6b0add9d2523e90cdf840ba008e4d58ebe9ebea0115305155c5d3f7b566cbde5f7dd511fef9d543c1fab467e91bac3d4a27ac9ad87957f" deposit_data_root: "0xdcf69aa4fa002dbef4af6017e7a178c9c553c68e3f3d9352563491ab58bd82b5" eth1_data: deposit_root: "0x7615cbc219a8c6a9fb950d887fd850185534967b2a5441902215e584dd2151a5" deposit_count: "301" block_hash: "0x79363266a5cff13e09297e640ced33e737db69fdc4e8a649939e36578099a9e3" block_height: 302 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" - "0xb8f534205d4b218cd717bddf06a06cae872d995a165506cff2e8c12af6a71afa" - "0xdcf69aa4fa002dbef4af6017e7a178c9c553c68e3f3d9352563491ab58bd82b5" deposit_root: "0x7615cbc219a8c6a9fb950d887fd850185534967b2a5441902215e584dd2151a5" deposit_count: 301 execution_block_hash: "0x79363266a5cff13e09297e640ced33e737db69fdc4e8a649939e36578099a9e3" execution_block_height: 302 - deposit_data: pubkey: "0xafb329bae0ec756fd1be3ee1eac93550b77177d96558deeec2a6a131e35ccdee653189d4f5bb744f492371605c44a9bc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x81839fd0a1d6bcb75751f1c9a3d3b2a8c7812c4e2933d52c0327d69ca7fea84c9ad7c1a4475c88e46d25baeacd41e4e60c5f3ea05c16ec768e011d41c0e3b2edac0d9ae16b4b410313470283ed4086634c080bb7e676493763c459c6d246e15a" deposit_data_root: "0x3d5f8d118ae4e4fca8223b2b819c1931cd041443d278b6823c9b4aea22bd57f7" eth1_data: deposit_root: "0xa80eedd04962726c155bf13aa99c6c56457c99e3d4533ab74a4abe2e961fe9f8" deposit_count: "302" block_hash: "0x1c6191f59c7eb6f4c8cc5837ccd23de7600c2dffb62c9e1133248baf3cc4e363" block_height: 303 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" - "0xb8f534205d4b218cd717bddf06a06cae872d995a165506cff2e8c12af6a71afa" - "0xa93353e7b0d909e8d19d5d6c466cae15e8e5f2b929758e88d8c35f6ac180c0c2" deposit_root: "0xa80eedd04962726c155bf13aa99c6c56457c99e3d4533ab74a4abe2e961fe9f8" deposit_count: 302 execution_block_hash: "0x1c6191f59c7eb6f4c8cc5837ccd23de7600c2dffb62c9e1133248baf3cc4e363" execution_block_height: 303 - deposit_data: pubkey: "0xb62df9c59793d5e3a553e9f5b9da4c928105e221898f11847e7ec9a60c091a1a56e0f141d64bb5bac13d424a49798917" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x822390897c4b8d9e0f2d0868afe9cfe5efc14f7290a48717071de84200fdf96d5f4aecf2c577d003f4af4c4f59bbbfc802166746f52794eecdc656c4ec845085d053c4d021d45c639567e24825bbc60572747900e54452fb052f45895ed97e14" deposit_data_root: "0x888daeb2cf145994cbd3f25806c306082dd402d4b4420f0817c5a5a19132cb36" eth1_data: deposit_root: "0x334dbf7b9b0cd5d22f79c7dca388d3baf541e430bdd31883fd7402852febf29a" deposit_count: "303" block_hash: "0x42bc399b54a8e566243c3ba4e2e1ceeca8eea2b7cd84462b8814229d9f459796" block_height: 304 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0x5b1f9c36b45f9d1e8495781e9d8290f328e09b9ec8f382b801aa6354b25b2e27" - "0xb8f534205d4b218cd717bddf06a06cae872d995a165506cff2e8c12af6a71afa" - "0xa93353e7b0d909e8d19d5d6c466cae15e8e5f2b929758e88d8c35f6ac180c0c2" - "0x888daeb2cf145994cbd3f25806c306082dd402d4b4420f0817c5a5a19132cb36" deposit_root: "0x334dbf7b9b0cd5d22f79c7dca388d3baf541e430bdd31883fd7402852febf29a" deposit_count: 303 execution_block_hash: "0x42bc399b54a8e566243c3ba4e2e1ceeca8eea2b7cd84462b8814229d9f459796" execution_block_height: 304 - deposit_data: pubkey: "0x810ab821a4d4a0707e0f70eb7dbf78a528e2503749e462fda69969ef1aeee9ad2b8d37c77056bdb0feecdf206313d2e9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8899dcaccd1c167c69c6e4d5ab42f03f5a6e9bf1a1d664dbf07fac6de06b59e651147cf78a2924acedb33944a8d11d451189e78c32a646260d0401ebe79dda5c35d00688cc0d024a2f12248b47fe5d4a7a04fdd420aca97e85f86497998f66fc" deposit_data_root: "0x0c6eefdd540468d0e9e72aa9c1394441e05788e7f0998cf6f5157466fdde05d2" eth1_data: deposit_root: "0x3fddb8ccad286ee5c85d0e2d851ee3d45dd7b03bef1a980c60ba49166465af93" deposit_count: "304" block_hash: "0xb0338e285f4f8d5621dfb6894d21095a58cc89d5d8b0e574edf8efe7ca30ad26" block_height: 305 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" deposit_root: "0x3fddb8ccad286ee5c85d0e2d851ee3d45dd7b03bef1a980c60ba49166465af93" deposit_count: 304 execution_block_hash: "0xb0338e285f4f8d5621dfb6894d21095a58cc89d5d8b0e574edf8efe7ca30ad26" execution_block_height: 305 - deposit_data: pubkey: "0x80f23973b414503e2ba0a53f67463f332b23fe5fd5466f1a770a6d548fdf4421d9370ae890b54be1cbeacb7a9e31d166" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x85a60518498341146050685aefe04587f4f9cbb7210bee705e2018c351d358d357330ca0a81da886788228eb0a3688d202024a72a5c378ccbba3c7fc7fbfcf84d630c0a8cac56ee029b8348d83b6b73b1e7019dadd34ed0272e7e6f0ea8b36b5" deposit_data_root: "0x7562d64a4e031ff5e46a3319de670de403d8b14c256ade2aa6c3f69b2e0ae077" eth1_data: deposit_root: "0x567a327092d5109af0a5b29ad3c445d7444dd00fa1e34b678db5e04b48a54917" deposit_count: "305" block_hash: "0x30f7bf7c4b84b1e0e14234732b33fd5eaa755838404fd7a9558a0d52b29a072d" block_height: 306 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0x7562d64a4e031ff5e46a3319de670de403d8b14c256ade2aa6c3f69b2e0ae077" deposit_root: "0x567a327092d5109af0a5b29ad3c445d7444dd00fa1e34b678db5e04b48a54917" deposit_count: 305 execution_block_hash: "0x30f7bf7c4b84b1e0e14234732b33fd5eaa755838404fd7a9558a0d52b29a072d" execution_block_height: 306 - deposit_data: pubkey: "0x95ce181db92ea8695c006896d2bb9faada9e157a896cf06b5466c304ccc6b09f7b8b10044b9b0689265ee97a6388dcd7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5911e4df04e991fe79576339db9eabcdaa7a691fcf6a07e86666b81f4176fb2cf7bdcd93f7512f3d8a0bef4725c30680e6ee5439ac60e013ea0cdfc8c11c0a044f0a64c7393bd12927b9c51b45b2862311ca1169fcd83b798c1653d1131d98d" deposit_data_root: "0x88d50a861161dc2f5a2fd41cc69eca91e1e251d29224d3e813937860204f93f8" eth1_data: deposit_root: "0x3e8177de3da30a03e473faa90d01ef262563526c5a28c17d22c4bba44430eef5" deposit_count: "306" block_hash: "0x0168559f9953fd501450a3ff14cd7b48b0b75663a319abd9766d4d9fc514a2e0" block_height: 307 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0x2685dc940c27a8289d56e5cf4246afc27ad50baf0abef93caa8e379dcb39b41e" deposit_root: "0x3e8177de3da30a03e473faa90d01ef262563526c5a28c17d22c4bba44430eef5" deposit_count: 306 execution_block_hash: "0x0168559f9953fd501450a3ff14cd7b48b0b75663a319abd9766d4d9fc514a2e0" execution_block_height: 307 - deposit_data: pubkey: "0x8e322c2995e2472a7981466eb4b890d753b2016798cf640ed4b7ea7a3d53e5644361f404c5eec4baa1a55da860b7981c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaeb741e937c13a7f8dfa2b7603c902719786f247a25b0eedf6327921d09486afb8ef66c30b232d6032d4ab5475dd54f407c702a09cad1bfd675ff57f44d100a996af265c6c275c69f0593da7832a81cad4417b82fbfc6a088482b3aa1d856a4f" deposit_data_root: "0xc275ba69111f046f57da439d9b3d3e52a7124328b5909b40655e1afe75bfbbf1" eth1_data: deposit_root: "0xf228d693edc9dde11a393ab4191a7b47ad4eabe0839bba4fcdc6a63cda49f729" deposit_count: "307" block_hash: "0x6d3facdb3a92f45bf9f2d65576346739d524e703d4057c1d8474b3fe9de8667f" block_height: 308 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0x2685dc940c27a8289d56e5cf4246afc27ad50baf0abef93caa8e379dcb39b41e" - "0xc275ba69111f046f57da439d9b3d3e52a7124328b5909b40655e1afe75bfbbf1" deposit_root: "0xf228d693edc9dde11a393ab4191a7b47ad4eabe0839bba4fcdc6a63cda49f729" deposit_count: 307 execution_block_hash: "0x6d3facdb3a92f45bf9f2d65576346739d524e703d4057c1d8474b3fe9de8667f" execution_block_height: 308 - deposit_data: pubkey: "0xb6f68789c60d1348b5e24bd6b7ccc18500be7b6ef0099895547a83f63eca37ca4f26fa3517d5bc71bc4a2fb186149179" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8888f11eaefbd7bee2d93a8713415d0452b6cdf794f5095a7f4b7913556b17e969d6b1137048e2fa94af582d4fea848e185cd3df47f5071d49ec86d21389443e4771f31fc466c3bdf211cca260f677769c90d5493b6a0e8a230c455a9f6539cd" deposit_data_root: "0xc5256c0995975cc0953677c36413969b40e96b3921007fd975bdb7d5cc883d5c" eth1_data: deposit_root: "0x301dd53110abda16d11eee1d46ccbc839f8e9adc1c0f0592aa010242f123397f" deposit_count: "308" block_hash: "0x4c2a9c39824275f99a4ef57cff7778b6fb793cd493d7e96da426f9f5c50b19f0" block_height: 309 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0x428b54bb40a87f83657cfb7998905b4deaad55f2d092f13b0365b11847bd984b" deposit_root: "0x301dd53110abda16d11eee1d46ccbc839f8e9adc1c0f0592aa010242f123397f" deposit_count: 308 execution_block_hash: "0x4c2a9c39824275f99a4ef57cff7778b6fb793cd493d7e96da426f9f5c50b19f0" execution_block_height: 309 - deposit_data: pubkey: "0xb50d3fc8e36d2f2eb544c16b959b500160c2b176298e4e16ae5d928856406c86605b8ea6bd802ca1a2d1c9210d6bce61" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa88f8ea391dcba3fbbf6a4ffb58bcb8135d0001207c3656f671fab5669903a3d1fbf1150e856abd0c2d180f5518205d707692aa6a239ab2bea39338b11b0a04cb078bc61fe966feb25b905b1629067a6107bb858393339002119592d03d60395" deposit_data_root: "0x768bb277eec0d74fe504242f61cd37bd63a76417f860ea154d89bf1e9209318e" eth1_data: deposit_root: "0x03403e71434239fc6cf3c51e014029b6dce79899d189cb789ca41ec8c76870df" deposit_count: "309" block_hash: "0x142755a334e7b0f2ecd19714918edfc8fc49e591dbe27a072f98b929914795c2" block_height: 310 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0x428b54bb40a87f83657cfb7998905b4deaad55f2d092f13b0365b11847bd984b" - "0x768bb277eec0d74fe504242f61cd37bd63a76417f860ea154d89bf1e9209318e" deposit_root: "0x03403e71434239fc6cf3c51e014029b6dce79899d189cb789ca41ec8c76870df" deposit_count: 309 execution_block_hash: "0x142755a334e7b0f2ecd19714918edfc8fc49e591dbe27a072f98b929914795c2" execution_block_height: 310 - deposit_data: pubkey: "0xa72612ca8f454d74489512d0637191bcac72124f4111f7cd52de8920ee3ea804ee895201ed74527407159220ed00712b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x988ee0d14e460e614b4db31aa0edce326450745ae33898a67f59279ca125a60a420e3fef3440be1502b173cf3b6cf75f16e427739cc02e79804a5533453b752962eb695656c5f7eadb3c13588762fcc743978bd3d6ccd4feeadedbb9bf2b989d" deposit_data_root: "0x0275c66e7493040447a4a1ce248051418acdc6c62cbe2e5de0a6ab4737f1c6c7" eth1_data: deposit_root: "0x80a4bb6bffb48e9c359242c260546b21e0b52020788e5a30a6c06a4ac8728d4f" deposit_count: "310" block_hash: "0x626aa2fd2714dfff5d15b35def25420116d8ccb50a602513f9596ed98e06040b" block_height: 311 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0x428b54bb40a87f83657cfb7998905b4deaad55f2d092f13b0365b11847bd984b" - "0xeb3f38ea9f413e0b73256ebd08ed8be2b639aced165911e48656e44330d03d5a" deposit_root: "0x80a4bb6bffb48e9c359242c260546b21e0b52020788e5a30a6c06a4ac8728d4f" deposit_count: 310 execution_block_hash: "0x626aa2fd2714dfff5d15b35def25420116d8ccb50a602513f9596ed98e06040b" execution_block_height: 311 - deposit_data: pubkey: "0xabdcd975ccfab19f10d7ec535f7c0e9e269a34f5eeb653d15ee0505f383274e5a20b3b71bdba0f369e36cea0eae1f5b1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x80039f2345c88aeb006695982d70543e37c8cf5a1622b589326d215ff2687396eba8797e896c590878aff20bcdfeecdb0e4e9534df8429e3cc8c585d0a1821c9c9378d4f2335f4dacb7d59794539c7d77306da1f065a126593bfcce78465d8e9" deposit_data_root: "0x12463230892e22766c8e4be4bde2f242553e7b213843ef3cb46c4ef6612cab71" eth1_data: deposit_root: "0xa0dffba4c6f35f9ce7e1e951a12c523651b6aa4bfb17e2323cf26324cce04330" deposit_count: "311" block_hash: "0xfb60531376af074a51de3a1bbceb7df9fab77acaca749ee4f779abf774252092" block_height: 312 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0x428b54bb40a87f83657cfb7998905b4deaad55f2d092f13b0365b11847bd984b" - "0xeb3f38ea9f413e0b73256ebd08ed8be2b639aced165911e48656e44330d03d5a" - "0x12463230892e22766c8e4be4bde2f242553e7b213843ef3cb46c4ef6612cab71" deposit_root: "0xa0dffba4c6f35f9ce7e1e951a12c523651b6aa4bfb17e2323cf26324cce04330" deposit_count: 311 execution_block_hash: "0xfb60531376af074a51de3a1bbceb7df9fab77acaca749ee4f779abf774252092" execution_block_height: 312 - deposit_data: pubkey: "0x83dbae1b08eea5bf0a89eb1d0b61e9e0c4e1142610ac8d88d9f3bdef550e3264b54bd47052d481738b92ffbcf6e36f67" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xabec6694b693a184bc5720f1d0c4d8dd8630609076af52ae7fa62c04fa7df7cc3c793d1eb776199a8755e861c9bd35410c3e225f31912cd2fb21694fcf444db989aa5e4eacc3434ac4ecb894fd4f203f1514e3034e328cf5d174ee896be4e26e" deposit_data_root: "0x627fbf478b052d8b09b47b17598cb372ef316a9e2df9fee7e04639f9f23a9060" eth1_data: deposit_root: "0x5c072d54c707ccbcd880507073f57cc01b6f162aea0a100c4523deb9508f357a" deposit_count: "312" block_hash: "0x4a09a6f7522d4793a3c0f56fd21714035a19d37f18d975a218b34952df576c9b" block_height: 313 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" deposit_root: "0x5c072d54c707ccbcd880507073f57cc01b6f162aea0a100c4523deb9508f357a" deposit_count: 312 execution_block_hash: "0x4a09a6f7522d4793a3c0f56fd21714035a19d37f18d975a218b34952df576c9b" execution_block_height: 313 - deposit_data: pubkey: "0xb628c432d9d76dd6483ed50938fc4c369bd24b6e3c1a41cc4620f7b513148fb242a76c7577f8766a14770ae597c36aa4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x90be83d06747ca26fd1d38a4847a9fbb02f2433ba940b51f364ca9bacb3924a2ffbc0d6e23366eeccfafaed746e29bce12589c80fb49db1b11df5da16a75aa4605b571efd142c59c07e0607cbbf6c16d989461a515e2a44b4f3c4c561fba0505" deposit_data_root: "0x74cc9ddae3f91c1b4bd274ed0ed14c29daaba30aed1632521ef60ca123ce2d09" eth1_data: deposit_root: "0x7789482c357af66154948684754c641d23d0d2556cbe3f017a9680aabb46934e" deposit_count: "313" block_hash: "0xad05a4ad4a1dd8968ce13df5c3a6fed1f0899849372b26285fc4288bab0e2b65" block_height: 314 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" - "0x74cc9ddae3f91c1b4bd274ed0ed14c29daaba30aed1632521ef60ca123ce2d09" deposit_root: "0x7789482c357af66154948684754c641d23d0d2556cbe3f017a9680aabb46934e" deposit_count: 313 execution_block_hash: "0xad05a4ad4a1dd8968ce13df5c3a6fed1f0899849372b26285fc4288bab0e2b65" execution_block_height: 314 - deposit_data: pubkey: "0xa36425294d9fe4f803acb3ce90947ea5f20cb1c06c4899b80129d8fd7e491f0128d86f98aa987a1578ec1244ae3d5f17" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb19797920d1e40e85dafd881d1193e1b347dc252974d55d0187abfd6e0f2a195746fc24527529581c1f59f3d3bea4d2d0ef3080d515468c273d216711cb3b618d9f7f25f7da3ef789d060cb1811a747a3ec0ab93c149bb8656825451426dc668" deposit_data_root: "0x955a4d69a457b02106c01614769dfb29fe7d5c6672da037a22e16619edb5c06e" eth1_data: deposit_root: "0x627b60a6d46949a3c8dfde03b024118cf57f0b8e3590ab48c2523715e48b9011" deposit_count: "314" block_hash: "0x2ddf1d0ff89d425c64c78796ae3826cd030caa6ae70fbaa29c24a0d81abcdfb3" block_height: 315 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" - "0x69106b127afcf2e4ddba6429779d04030f20a0ae7eab086bb65958c789430cd4" deposit_root: "0x627b60a6d46949a3c8dfde03b024118cf57f0b8e3590ab48c2523715e48b9011" deposit_count: 314 execution_block_hash: "0x2ddf1d0ff89d425c64c78796ae3826cd030caa6ae70fbaa29c24a0d81abcdfb3" execution_block_height: 315 - deposit_data: pubkey: "0xac55318cef8cd8f015f2493d09be7556066e235f618971a3325368f3deba029bae60fba85171762827f1f70c6883a467" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b4f261038c4bff210d1a0925059e46cd0d830b16b6a20da2a8ac9bdde1239f15b21d20550fd5d1878977bf0e0358fec155a9cbd51112d9ecaabaa5d3a56100afe4f18a3a0ade34698d2e84e52e164fe83c4b1140ad4a6d048a09e658c57f8b0" deposit_data_root: "0x7dbeb694af44e130ec3a9390893a798e86e787ed494bacfc10a3ef49d8e85889" eth1_data: deposit_root: "0xc8cc34185cb292295e96bbb5ab092b69eacb7984aebe7f0d88ae077aa6c71e20" deposit_count: "315" block_hash: "0x48396fede67f0d87fdb841ae3f8dd588552fc1b43141ff5c2dae2f143a305a65" block_height: 316 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" - "0x69106b127afcf2e4ddba6429779d04030f20a0ae7eab086bb65958c789430cd4" - "0x7dbeb694af44e130ec3a9390893a798e86e787ed494bacfc10a3ef49d8e85889" deposit_root: "0xc8cc34185cb292295e96bbb5ab092b69eacb7984aebe7f0d88ae077aa6c71e20" deposit_count: 315 execution_block_hash: "0x48396fede67f0d87fdb841ae3f8dd588552fc1b43141ff5c2dae2f143a305a65" execution_block_height: 316 - deposit_data: pubkey: "0x9966dc1de264da86652de12f70b4d6c7271026be0b081797589ba126108809b6264e2ec18cd59e90dd2c639bcd9986c2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x97dd0583026f23df048ceccb8815d9ae93a5a61cc8ae0e57ef7bee0e0c16f146ba1e0b31c5490f61697c83dd8eabab7f025d724669389df5fcf1abc54f0d7715885d5db3c0f2dda0ecf1ec51fcbf613a9531894f9bec308782b73441a1f29ad3" deposit_data_root: "0x0f9245219098e059529bd695cb6a8409d6a7b771146e799ea918c4bc4778aaac" eth1_data: deposit_root: "0xd275e61f8ffd78a24684a3e46425d38e6dffa2babf29bbf98d3521ef0d6891e4" deposit_count: "316" block_hash: "0xb4bd7e404339b1e80030772dc8b8f1721d29b9b31516b26eb094eac84d8f36d1" block_height: 317 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" - "0x587c330aecf776f443ed580dc13abd4d0a36e4f8617e25366dce8a28e796d9e2" deposit_root: "0xd275e61f8ffd78a24684a3e46425d38e6dffa2babf29bbf98d3521ef0d6891e4" deposit_count: 316 execution_block_hash: "0xb4bd7e404339b1e80030772dc8b8f1721d29b9b31516b26eb094eac84d8f36d1" execution_block_height: 317 - deposit_data: pubkey: "0xb5a83ace1a9e683361435bb484295c11e371316800c073c8beaf1ee1900d5589966ac8266ee11b10b24f671231584302" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9029f10262639dc7a78130c1e0d924531a0939ce02c93df4171d9bda8a055dd270588fb54bc87c0a19a8ae1a3b93f02d1471907debb2c43e052a2bc6c71dc80751c96e46ecdb6e64ee5dbd86669b821e4fb7ef1a863af73a25207391e92c2f15" deposit_data_root: "0x2eea6ad287847510e3abaacdd5d8b21bf4c3cb317cee848b5150d76c7eee2326" eth1_data: deposit_root: "0xf7814cef15936b64805475bca92a6a37105312c8fdb4b6088bbf8d02aaf03a78" deposit_count: "317" block_hash: "0xb1baae047525e7438d4e06c776b9c14549a2bb0539275ce2d43a54605802105a" block_height: 318 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" - "0x587c330aecf776f443ed580dc13abd4d0a36e4f8617e25366dce8a28e796d9e2" - "0x2eea6ad287847510e3abaacdd5d8b21bf4c3cb317cee848b5150d76c7eee2326" deposit_root: "0xf7814cef15936b64805475bca92a6a37105312c8fdb4b6088bbf8d02aaf03a78" deposit_count: 317 execution_block_hash: "0xb1baae047525e7438d4e06c776b9c14549a2bb0539275ce2d43a54605802105a" execution_block_height: 318 - deposit_data: pubkey: "0x8428f1acb3bf75a11ca3ff7b9fcb2af1f0c43ae22f08d4ceb586c96f97f5d999273739d348900e2424cd375e5ef68f35" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb7a7faad5149b6e8b901414c37b01b5955033c7b7b29aab827b29cdd0a7bb32bcaebe1c67bdc1de99a972cfa52defdf518084a465c3804241e9d3915b441a8a108770f557e5b372ec2f4d7bb127b03585ce8ea85ab35506c51fbdd91ac109403" deposit_data_root: "0x37f7ed384f323053073d09ba424f7fcba44ae6b1f50464f210cf880df9ec4e8c" eth1_data: deposit_root: "0xf1b373962ed896fb473e2e0625acad818126834046cd4f36d43ef3c3fe15a589" deposit_count: "318" block_hash: "0xe756598b26a44670dfd997e1be73332113f9605d5d8d7f07ee3162f04d72ccd1" block_height: 319 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" - "0x587c330aecf776f443ed580dc13abd4d0a36e4f8617e25366dce8a28e796d9e2" - "0xfef52200f08b898e7c1909fe36e281e60093f925aa8400431e6f2fad81571ce1" deposit_root: "0xf1b373962ed896fb473e2e0625acad818126834046cd4f36d43ef3c3fe15a589" deposit_count: 318 execution_block_hash: "0xe756598b26a44670dfd997e1be73332113f9605d5d8d7f07ee3162f04d72ccd1" execution_block_height: 319 - deposit_data: pubkey: "0x8e73eafaa8fb6863473e55ef578c4764d9330996a62132a9329ab43f2a45ef2e68637cf48f674c8a0d127d9fb2738229" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x93dd39078da197a9ed00edf9ddff70017afad6b5cf9c9c3eb139bd61b362152c6d1d2bfce66fb93445eef99d2ddbbd041371aa6178eeb511229633be0e31fd692628a383b42e11a3e8a219c66bf15942c34658c1cffe86b97857145b0cf14f8d" deposit_data_root: "0xaa707e0428d7847f2f87e9dd478d34b093aa50c6bd025d7152f7fc48b5e61f5f" eth1_data: deposit_root: "0x24873485c0d733699f5309721201310f38e8e8a3fdd5c63dcab7f918a360e9a7" deposit_count: "319" block_hash: "0x703e8869ebd982b635b6f7f298cddff7ee58d5f8d9518c80c0d5aa0cd5bea3df" block_height: 320 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0x22c8f83b80ba6d15c5d143935e2decb02783c33299c81a81495369e44fd7f121" - "0xd332180e48743692efc13e599dedfd063f73963ababcf12ee1dbcddab376bcd5" - "0xb1125c174cf98e6ea57e02bfb8108d15da2cc5c7f1d49167551a9bf8bc37a7df" - "0x587c330aecf776f443ed580dc13abd4d0a36e4f8617e25366dce8a28e796d9e2" - "0xfef52200f08b898e7c1909fe36e281e60093f925aa8400431e6f2fad81571ce1" - "0xaa707e0428d7847f2f87e9dd478d34b093aa50c6bd025d7152f7fc48b5e61f5f" deposit_root: "0x24873485c0d733699f5309721201310f38e8e8a3fdd5c63dcab7f918a360e9a7" deposit_count: 319 execution_block_hash: "0x703e8869ebd982b635b6f7f298cddff7ee58d5f8d9518c80c0d5aa0cd5bea3df" execution_block_height: 320 - deposit_data: pubkey: "0xae451c6d18b7a14585dc96423f078be6b46742dde9be4d52907fff934956ebb2332e82c66cc2354eeb2da821e80ab7bb" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89bb72ea77d8cf12f08050fe005f9da2e6d31b5348ec1e6e7b46e1084664c5b2f486c7c44773df37ecbdf1ab7c3f86e00fc35ebd2f4d470d929deda82847570be28c6191631235ce4901ea75920638210cdc92f2776889addfefdc77023ec196" deposit_data_root: "0x7407798bee346eb5f23e00cdc0fbf7fddfbc35a0ab4c6573296cc0d58fe5dbb3" eth1_data: deposit_root: "0x2b537afcf4a0b123429379355ab08f2ed8e1f5a15311d37e6dfdb7436d78bf87" deposit_count: "320" block_hash: "0x4e38625114a763d73cb04258b94c92eda5b6eee0507e18e9f4b562cbfb2060e6" block_height: 321 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" deposit_root: "0x2b537afcf4a0b123429379355ab08f2ed8e1f5a15311d37e6dfdb7436d78bf87" deposit_count: 320 execution_block_hash: "0x4e38625114a763d73cb04258b94c92eda5b6eee0507e18e9f4b562cbfb2060e6" execution_block_height: 321 - deposit_data: pubkey: "0x953ecb430dfe4f91510dbb8166f07a557881c19112e41a8b1b8b0aa2c3d95c061cdff951044255a3e4df6f529302beff" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x90650885698e776deaeb845e2582dc5a60770c20f08563c429ee2e6657d01e4ae4e0a6464e9669341f3b04f64846a02f05b00b950fb4c5b10363582bce2ac313ec4534758bc293b3b9eab0149217e45b761952b6a894e3f42226d9392d33219a" deposit_data_root: "0xc978fe6c6f919724950edef3008541909ddc2965bf9bdd297aa98ff6760919c9" eth1_data: deposit_root: "0x0d9593241269b53b9aab5168a1db67f2ac6afb5e1811ca34627e5f510fa47c27" deposit_count: "321" block_hash: "0x101e4774d651227e02db01e67dd883d7ecfa1762fc5773639bdec3394fec49b8" block_height: 322 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0xc978fe6c6f919724950edef3008541909ddc2965bf9bdd297aa98ff6760919c9" deposit_root: "0x0d9593241269b53b9aab5168a1db67f2ac6afb5e1811ca34627e5f510fa47c27" deposit_count: 321 execution_block_hash: "0x101e4774d651227e02db01e67dd883d7ecfa1762fc5773639bdec3394fec49b8" execution_block_height: 322 - deposit_data: pubkey: "0xae629cdd3ee2278a8993feb4e163a9127c4a09857981704fad31e3fbf2e7668136f2943987c7b5619d7e362d1bf9d9ee" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4700ecbc23a35301973959072651da1963b1ec856c7d210e4bf165d7a306c501b9e31fa34e73b4001a1ab3a9b0acdaa0c62ba65f79e3ccfeebee512fdf980dc937a1c34a59bf67f323de0753ffc974ac8047948d924cd9204827b0587fef031" deposit_data_root: "0xa35ac1d1af9eab97f2679f3dfaef4a934ab6de575cadb245a45d754ff1c696df" eth1_data: deposit_root: "0xe3ab2d88fbc1cf4b39a86b71ea1d020c2d8231c69cc6d6eb2523c08b7fba9426" deposit_count: "322" block_hash: "0xc581458176fa41f0363a1ca199b1926a761489bf6dfacfa6cecbecffac82995a" block_height: 323 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x909fdc4a762e835a5b890dc4b1c41ca41b65df75770ac25537840d618375a2b5" deposit_root: "0xe3ab2d88fbc1cf4b39a86b71ea1d020c2d8231c69cc6d6eb2523c08b7fba9426" deposit_count: 322 execution_block_hash: "0xc581458176fa41f0363a1ca199b1926a761489bf6dfacfa6cecbecffac82995a" execution_block_height: 323 - deposit_data: pubkey: "0x963564994c2f8935ab03230c47dbd3596ca372a892a616c28ed80a582b9ca4a43e6ef58cd2fb2a3f3c03ac02eb272a82" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa470adad0a49fb8d863a31f7a942901ad76014898fb519d0df83215bf4df02db3348d42ffd4dd12c8e2ac0b421994e1b00325ccecfdc0ee8319fa5c135df27fdca2295568890a024178ec4c4b60fe9354c384792f0e61c8949461c8f0f211d19" deposit_data_root: "0x2aa0578a29fb670faca20939e663b953e70177df3cc91ba85d38332b4178b9d7" eth1_data: deposit_root: "0xaedca7ce962cb7ef634eae179f6f58c38f2dc6ea6121c41cdda7ec9438a27514" deposit_count: "323" block_hash: "0xfa06fa004648cc64acc6bd93a8a309d9494409f073f19d07d8a8221fbcc49635" block_height: 324 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x909fdc4a762e835a5b890dc4b1c41ca41b65df75770ac25537840d618375a2b5" - "0x2aa0578a29fb670faca20939e663b953e70177df3cc91ba85d38332b4178b9d7" deposit_root: "0xaedca7ce962cb7ef634eae179f6f58c38f2dc6ea6121c41cdda7ec9438a27514" deposit_count: 323 execution_block_hash: "0xfa06fa004648cc64acc6bd93a8a309d9494409f073f19d07d8a8221fbcc49635" execution_block_height: 324 - deposit_data: pubkey: "0x893f6809ed7bfd91951ba78b29c2eed9e8147ed63f01749380a0b6bba9bfd3c7654f05d2aa77fb7a096b981745615055" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaffa69acb9ec862c2e6a48e490ac305a1f7b9ea17b95c5aa416bb4f8f7682abcb8fd9f1074f989f99b780eeb8ba2f03015f8901fb0b0c2c90570452da90c0ecf591a739d6bf8e6e1ec13ce9d4644a4517e44a8bc923d1688732af77cf4e3a2bd" deposit_data_root: "0x5b62379e4f53e1806f256162f584ccac600b1b11d21ea858bcd61d8cea1b168b" eth1_data: deposit_root: "0x637c3e9b84ad5037a6e90a895f20d1b5ec49a3266ee9e3b3c4c632ce3f3f012b" deposit_count: "324" block_hash: "0x104902e1b47f88b3220f39f473f2f47d0e5b8f12041e12b6f1796ddaf70b962c" block_height: 325 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x829bab24c40bf37b3bed73fa4dd76eca6f03f8cdc0d73ec6decd58c56626fdca" deposit_root: "0x637c3e9b84ad5037a6e90a895f20d1b5ec49a3266ee9e3b3c4c632ce3f3f012b" deposit_count: 324 execution_block_hash: "0x104902e1b47f88b3220f39f473f2f47d0e5b8f12041e12b6f1796ddaf70b962c" execution_block_height: 325 - deposit_data: pubkey: "0x868207372934c6e8133df3c6a1d4a993cca26a06616d8f3de0c593a4cca3005d6e1a73b41620b05a31eb44841fc20932" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8485459f5c442443a0075bce597ec6428477bc1f2634fe463397f35b39fab15fe876f1d9c22dc0a9eea20a546f92c39f175ff8402decdffda89f03d074d0c6abd9b95ead19f2b015e9cd6637c505131a38f94c0cc1f39e79152ab5fded97d295" deposit_data_root: "0xc19bad7ae315d2679d0a9a44b416955031393874ad7d4f86924ab2e7412dd86c" eth1_data: deposit_root: "0xd7162fb64e8276d1d722de19732d3d13cc63963606dd5afd722c901721b001ad" deposit_count: "325" block_hash: "0xf56c5c31b8721f20db972d51c8dc999755b33f49f051f8ecc343a6ce30ba1695" block_height: 326 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x829bab24c40bf37b3bed73fa4dd76eca6f03f8cdc0d73ec6decd58c56626fdca" - "0xc19bad7ae315d2679d0a9a44b416955031393874ad7d4f86924ab2e7412dd86c" deposit_root: "0xd7162fb64e8276d1d722de19732d3d13cc63963606dd5afd722c901721b001ad" deposit_count: 325 execution_block_hash: "0xf56c5c31b8721f20db972d51c8dc999755b33f49f051f8ecc343a6ce30ba1695" execution_block_height: 326 - deposit_data: pubkey: "0xafa8898fca81793be528c433c00c9838be077b05b7fee5c82c2ff1bea10834f3aae64e2d5b8e3cb3e4a8104127f2b99e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83536ec416710222ad12669bf77c64062b11d01bbf986d900efb37174e45673764941a630a641d4971bcc1ef031bf6110f7f65599ae492f7e2581af7fbe532aae11882007c3f89736eb7c840b21d194f2805e4016b0cb554255ca59343d741ea" deposit_data_root: "0x119dec41ef12a9e3fb28da1a750b117e63d1d0f59a65668984336eec709b8061" eth1_data: deposit_root: "0xa6f2b846a99b787bfd81acf69ffafca4811ab7c97ba50fbd2ddcf2dc508cd5b9" deposit_count: "326" block_hash: "0x5d0b737eb0d181195028dd01961a295c8e2baaf0d9aefd647bf884032089245e" block_height: 327 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x829bab24c40bf37b3bed73fa4dd76eca6f03f8cdc0d73ec6decd58c56626fdca" - "0x6352a5698a39b09b04e0d89ee74b46a579de3e4176cb60ec11c6aad278f2e0ce" deposit_root: "0xa6f2b846a99b787bfd81acf69ffafca4811ab7c97ba50fbd2ddcf2dc508cd5b9" deposit_count: 326 execution_block_hash: "0x5d0b737eb0d181195028dd01961a295c8e2baaf0d9aefd647bf884032089245e" execution_block_height: 327 - deposit_data: pubkey: "0x9685e2fb1018a705d32745ac6bd64d7bc5861679753d5f886a9439c1f8f85cc247b392035fcae82233aa39a6be24515a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8d766fcb28fe1c2c80c93cfb974f700b2b413dc9abcf0621f623fc8f7059e7d2ede209c75a426c7cbc264a08435790831645cbf7f6f977d9dde8e1382db0ca6f8d7c153e47c7f9a2bd5afc1c09b2d5a0d60b4c7357fad005c53d6e29ed369d57" deposit_data_root: "0xd469915f8ff96a6b4944ac2cfb6cfaf5086b4502819e279ddc3d079da18351a9" eth1_data: deposit_root: "0xefe013b8db2bc21b289a80f7eac2d726307ff64d7182c92d3c38f8bf5b070ed3" deposit_count: "327" block_hash: "0x7e26828262c78521add66b854b9f6202f38c1b9425f93b7bbe786da0ca6a9d41" block_height: 328 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x829bab24c40bf37b3bed73fa4dd76eca6f03f8cdc0d73ec6decd58c56626fdca" - "0x6352a5698a39b09b04e0d89ee74b46a579de3e4176cb60ec11c6aad278f2e0ce" - "0xd469915f8ff96a6b4944ac2cfb6cfaf5086b4502819e279ddc3d079da18351a9" deposit_root: "0xefe013b8db2bc21b289a80f7eac2d726307ff64d7182c92d3c38f8bf5b070ed3" deposit_count: 327 execution_block_hash: "0x7e26828262c78521add66b854b9f6202f38c1b9425f93b7bbe786da0ca6a9d41" execution_block_height: 328 - deposit_data: pubkey: "0xb41c965012fdbf74f551e0a1372202f5814cedfe541336f5954020ee2ef23043efa6baa200cbd22b34acc5462ca3e9cd" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x86db0292465a7a813f4e6da0d9dc4df20852b088a096b5b569251f544f4e98d2e3125926f1ed97fbcddc356de8461ca1173e9466d181b5f7fc63f772313bc3bb5e37b681c845b5cec8954762565b0614c0413da52147e461bda26ac718afd166" deposit_data_root: "0x2a5c7ed2c0ef2938c1edeaa39bbe965c3b7ddfbf544553892c02c2b502c19f33" eth1_data: deposit_root: "0xa7a049ceb8533aaaee37c8540f1ad14e400ce325de95ef3ff6d9a5a30277aa80" deposit_count: "328" block_hash: "0x7368b2a4ec10255ec111a7b79ef69efee937e637da93706c68907df2eb5ec722" block_height: 329 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" deposit_root: "0xa7a049ceb8533aaaee37c8540f1ad14e400ce325de95ef3ff6d9a5a30277aa80" deposit_count: 328 execution_block_hash: "0x7368b2a4ec10255ec111a7b79ef69efee937e637da93706c68907df2eb5ec722" execution_block_height: 329 - deposit_data: pubkey: "0xa8a7015ac1ac3ec6678478167302dade9eedced09f899a60decc8060f972141a88be910f959aa155cceea322f375ae72" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa3b80ecbaf373ff93624739d4fe040d037ebcf3ef906b294b3b908325547aa217b930b0663b2d9589aab52084a028b370c455a452f4ca2ac2156bc7f4283f96c1b3a770d05d9570dfd57844142aa167091359e2a2364de250d22ba06533e4736" deposit_data_root: "0x59397bf83c3fc9c58074f1e8139affd9df65b46dd060f498562079145f499f34" eth1_data: deposit_root: "0x638a7dd7929e0e9ce2efd35226d44a66c555379ddb234e778244064ed44fb3a1" deposit_count: "329" block_hash: "0x32438de8960d5072d117ed3497e8c3ae169df2c634103b6e708bc04bce0de62c" block_height: 330 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" - "0x59397bf83c3fc9c58074f1e8139affd9df65b46dd060f498562079145f499f34" deposit_root: "0x638a7dd7929e0e9ce2efd35226d44a66c555379ddb234e778244064ed44fb3a1" deposit_count: 329 execution_block_hash: "0x32438de8960d5072d117ed3497e8c3ae169df2c634103b6e708bc04bce0de62c" execution_block_height: 330 - deposit_data: pubkey: "0x83a7860b2ff27518453860637b50ed63adfbda9a2f36432e949268cdbd5a6cc10985acf9bbb57391393823d71328c85a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x973582f2e9868c13e6f8f5bf798e2111c785281e0659e1adce01524406daaa5d2da5a70c141e84da6891941b632a22af157d1239c5d8a03dbdea8157d7c3f86cd0b316ce06150e18986aca9c84740b1a389bd60234e8f95c9a3d5bcd7f4ca6b1" deposit_data_root: "0x249592161dbff13774225e1fb6d8a41c4bdc86213ff6ad2fd5bfaa0b4c9b814d" eth1_data: deposit_root: "0x2676fba7f7791a8dc588e76fda0a40390988f860b6fcf543d91bdaab3f889344" deposit_count: "330" block_hash: "0x1c1926c17a2879fb7535863b86d080bfdb32f0213e74ba6895ab8801771bb20a" block_height: 331 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" - "0x491c63b1a2fc1989cb6be00597134cd056a4ccbcc142850c5834a24da3a58686" deposit_root: "0x2676fba7f7791a8dc588e76fda0a40390988f860b6fcf543d91bdaab3f889344" deposit_count: 330 execution_block_hash: "0x1c1926c17a2879fb7535863b86d080bfdb32f0213e74ba6895ab8801771bb20a" execution_block_height: 331 - deposit_data: pubkey: "0xb7458d704a414e012c62a3d19c27da6b0ed9dc77dbc1a328e736043e156eef0af395853ba915bb246a2a4178febc7ad9" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8d51031827dc04649b8825a745eb56f32168064ec6efeadbf8e6d639b21e826ef5c61f890e816bfc66e87bbf85759d240d9c5a95d602ec1ba173fca94959c3a84b164b1d7bc6098bcdead65318f9900c79f9cda30584fd450914613cd174b425" deposit_data_root: "0x579accbbe17b59ac71d9923a7cf7b851ccfd509caeb9fccda56c538dacf1744e" eth1_data: deposit_root: "0x24d257c531f4a7c0979f1778496a0e422e76f120dd5e6f97af72ba9c19b30369" deposit_count: "331" block_hash: "0x5d1c3942268956fbe23bac62b814488414664aaeff9a047078a2790f0ccbec6d" block_height: 332 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" - "0x491c63b1a2fc1989cb6be00597134cd056a4ccbcc142850c5834a24da3a58686" - "0x579accbbe17b59ac71d9923a7cf7b851ccfd509caeb9fccda56c538dacf1744e" deposit_root: "0x24d257c531f4a7c0979f1778496a0e422e76f120dd5e6f97af72ba9c19b30369" deposit_count: 331 execution_block_hash: "0x5d1c3942268956fbe23bac62b814488414664aaeff9a047078a2790f0ccbec6d" execution_block_height: 332 - deposit_data: pubkey: "0x8a6785d9912cb5be712bf51c08da89f9a3c7942869176d1a24f114f430715064f48c35d37c1c1d1eb9b9322ecfdcedb0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa19c204bfe842f321b5eb4921bfeaaf7275ccbe56531bff038b7e534ab98b13179245d804cbfe08eaa635b1f0c9271ed09754a00cbc617ce22610a78c7a621e92be914288e5412bf2568f784273c59e3d2a529c45c72689a2817a19489fdc109" deposit_data_root: "0x3998111d43f8546fc032329d81489551501ccd9b835b0c738866336f442f675f" eth1_data: deposit_root: "0xcf48923ed77d78c9655d703dc1920f4824c269dd652f2999757e589abbad0247" deposit_count: "332" block_hash: "0xa0bbc1be8518265a9f0c090c6a3011529e0066b978151c1751962b6ee6439fe5" block_height: 333 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" - "0xfad232bae67341101a570b10f6192e9d46fd997037d7350c72506c8ff80f9c2e" deposit_root: "0xcf48923ed77d78c9655d703dc1920f4824c269dd652f2999757e589abbad0247" deposit_count: 332 execution_block_hash: "0xa0bbc1be8518265a9f0c090c6a3011529e0066b978151c1751962b6ee6439fe5" execution_block_height: 333 - deposit_data: pubkey: "0xb855cac3f2635d485914e4b25b953b066dd5942215b38677d16d3fa6aac5b7f8d0849398ef946674e88514fc83c42491" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa1a4a04d87aa7051d721623609478467070098d8ee9310292a5c98ce5c49185d2fbeb8225a964906f23b4b8d864a47dc0025a10d94953de9b4846ed342fc3e97485d278f9c286417a54eee5496b9f3c1f1e51cfd3396688931f888c241f95552" deposit_data_root: "0x6566a16b18a8c515bff85c5cfaa9d0dd7873c39afd6a50e7655d15198fc3d37f" eth1_data: deposit_root: "0x601f76fb38837cf4733da9f152e37859b1be5e1d18d341ca181b87df6b56320c" deposit_count: "333" block_hash: "0x2b03e78da06e7a66393fa47a4713ecd2f0eb79a016ad42e2e57350e9a6c1340d" block_height: 334 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" - "0xfad232bae67341101a570b10f6192e9d46fd997037d7350c72506c8ff80f9c2e" - "0x6566a16b18a8c515bff85c5cfaa9d0dd7873c39afd6a50e7655d15198fc3d37f" deposit_root: "0x601f76fb38837cf4733da9f152e37859b1be5e1d18d341ca181b87df6b56320c" deposit_count: 333 execution_block_hash: "0x2b03e78da06e7a66393fa47a4713ecd2f0eb79a016ad42e2e57350e9a6c1340d" execution_block_height: 334 - deposit_data: pubkey: "0xae8aa6029e2318a91b3b6ff77e2792905a690d7ad0ac1f97a7887ca4891642d267b7e208f6bddf407fd8c4e10caab2a5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9077969feb76785e0c70a27f1cbbe4ddf95a0d492ded0730d542b4efd8194b44761f9af983f5169a3b04894db5ec0b620f20b332626a3a41451bd2fa7699750a7422b7c3adb2886bf009cc361b35ecea393d2e6539f16af3cc29b12adc52b007" deposit_data_root: "0x212acb543447a951ec9bc344e0dd2816b7cf8292ed26e09341b39c463bf2c1d7" eth1_data: deposit_root: "0x17ad9aa2ffcb568adfee07a4ea93693926ef5e196f325c0c0b1e282433e2526e" deposit_count: "334" block_hash: "0xeac3f8860c586f736f0bfbb5132027e74d76b0060a0751e96ffee1d90eb57707" block_height: 335 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" - "0xfad232bae67341101a570b10f6192e9d46fd997037d7350c72506c8ff80f9c2e" - "0x98ad3ff4a62e454b2468ff55af20008d2d05198840dd8fa50ef9c637bf07086a" deposit_root: "0x17ad9aa2ffcb568adfee07a4ea93693926ef5e196f325c0c0b1e282433e2526e" deposit_count: 334 execution_block_hash: "0xeac3f8860c586f736f0bfbb5132027e74d76b0060a0751e96ffee1d90eb57707" execution_block_height: 335 - deposit_data: pubkey: "0x98a5e4ffd62c3b8eb39f6230d242efb74701f42380663af26fcbf106ad1b0f02339aa6d9eb5f2f073b01f2c85062d89c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa611b0ecfe36d86f891951236a218d1f9a64abd697b4e861b2c8849b6b9b1f23287dfdfa1c2c45ca6fec8dae2e1163d1022836eb27982c328955eff7643e031c407ed8629b8c39c8d30bf3b115d0629baa493ead81959b962e42c4ea44b69403" deposit_data_root: "0x4b2e8ce40e43537b4a92f303966172fa604c02f1c1747d558f561c4a9915e649" eth1_data: deposit_root: "0x6b407936ac387168556937334d1fd4d42efc8b83e2979abc7b9440264dd81e8f" deposit_count: "335" block_hash: "0x642c02da32878eeec84d0c17ff498fba2173c61acf4f268b1f4d937a8261d92e" block_height: 336 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x68037963cd0454c7fca9c176f22dd9e308d606acf005cb7b2c5c800b9d443189" - "0xfad232bae67341101a570b10f6192e9d46fd997037d7350c72506c8ff80f9c2e" - "0x98ad3ff4a62e454b2468ff55af20008d2d05198840dd8fa50ef9c637bf07086a" - "0x4b2e8ce40e43537b4a92f303966172fa604c02f1c1747d558f561c4a9915e649" deposit_root: "0x6b407936ac387168556937334d1fd4d42efc8b83e2979abc7b9440264dd81e8f" deposit_count: 335 execution_block_hash: "0x642c02da32878eeec84d0c17ff498fba2173c61acf4f268b1f4d937a8261d92e" execution_block_height: 336 - deposit_data: pubkey: "0xa7723c37795ac53e3ebc25b9dd55af10080490e872a18724b0bd3c7fecf8ab18f7d6abd1b49bc755048a3f9b1bb136ed" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x82d29cd5f8a497b898dcf8d03b7b4e43e2ab362898d80f1b8cedfce878eda388aab81dd2249c4ea11f0359ca666ecdcf12dc23fb637063a23a42f6f0140d74040faf4cedf86ffde4d4ad31a3115a652c53e3e69b8c6041341976bba45451319b" deposit_data_root: "0xaafd33e6d9e12cd2b3c9b01a65440dd47914a24fa5ec0a54f1a8fdc04d2a4cce" eth1_data: deposit_root: "0xb16b2f7f6c0d8dad74c340492d57d24b032a221ae10d86ee1525f0221fcc690f" deposit_count: "336" block_hash: "0x0671e4bb3a224e145648e03b323fc2034eae6d285f280842370bffc9b75211b8" block_height: 337 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" deposit_root: "0xb16b2f7f6c0d8dad74c340492d57d24b032a221ae10d86ee1525f0221fcc690f" deposit_count: 336 execution_block_hash: "0x0671e4bb3a224e145648e03b323fc2034eae6d285f280842370bffc9b75211b8" execution_block_height: 337 - deposit_data: pubkey: "0x865f9a725b49135bae6c011f778bb311a514a73911924e4630a5fedac29e1b4d127308ac8b0d623e7f246c668b827f35" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x98df5e77c8ea74dcc876e84a85bfb829d3f8e6349e1295daae0f7817e47d62788ef5509ef4c7cfe12ca4928c2f8708380b880cff39db85f02a3ae414529cf8ea708d745cdffaec6785a09f78e31a38b6eda8a1849c987e16a896d1fac4baa936" deposit_data_root: "0x4c1a708c3fd48341741103c34da6335e37373ce7706ce809aaac4ac88d1a8253" eth1_data: deposit_root: "0x796573ea2cfd71631491eb7a44bfd33ad6d1be1b3e446549409773724d8990ff" deposit_count: "337" block_hash: "0x76f57ebaa44d6bf4b4edd91f646b8f872bc1386822617d4e438412858e69fd19" block_height: 338 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x4c1a708c3fd48341741103c34da6335e37373ce7706ce809aaac4ac88d1a8253" deposit_root: "0x796573ea2cfd71631491eb7a44bfd33ad6d1be1b3e446549409773724d8990ff" deposit_count: 337 execution_block_hash: "0x76f57ebaa44d6bf4b4edd91f646b8f872bc1386822617d4e438412858e69fd19" execution_block_height: 338 - deposit_data: pubkey: "0xa663aaabc4aae867b7bc4feb03558f9c906be74fbd1cfa931b88191a1817c8393778ef45b5cb107cbf860e9cce540212" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b7e2a3f92460dfc0e12f13ae76c2949a08fb6407ef52ca0b5059def233c0764955401253ef03f2bed3fc6feea5a09f008969ab976cfaf7a649a930b552285f4441f0d06c0234b81ee37dbf8eac19a50c8276979ade3c7bf773249a45c477e31" deposit_data_root: "0x1500846f0a4b55b0ed41b84c3028f1df35be19bb4f82dd1a84c6b5fde4d9dc21" eth1_data: deposit_root: "0x955590f03dfa34324c77e65b555d2dab80e5d4da4594deb99c7564eed667b840" deposit_count: "338" block_hash: "0x1d34b11fbd4c5364cd26c59d0d39dab70bb4406ab876409eb98a505f474c12ab" block_height: 339 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x02937359af82fb5ab508a78d0a5455edc12d42abc01d457cb808ae23ffe4f3b9" deposit_root: "0x955590f03dfa34324c77e65b555d2dab80e5d4da4594deb99c7564eed667b840" deposit_count: 338 execution_block_hash: "0x1d34b11fbd4c5364cd26c59d0d39dab70bb4406ab876409eb98a505f474c12ab" execution_block_height: 339 - deposit_data: pubkey: "0x970d2002cd899a503a0a007d6b5cc6f8ea9fc7e7db1de06b5297daa7f365d066e69cfd179197229508bdf93161904330" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb286275d11239f69f057de9e85f5f26466f0b316dd0a904a4ea87def5aec3808f7c5379d8303666902819449fab7efab1564ee7e1fabddb6f475530fee84042b76ccff7eb8a1c4788fef17ce15aba2ecdf8aac1ba25af4f9c47bf66491dc6e4d" deposit_data_root: "0x7fd3c53f7f63b048832cf0492598920d87f4a205dbd16e53c4bb6bc9c9c9d43e" eth1_data: deposit_root: "0xf75235a060b1c539b96b12e4d23245f341777cac99f556f4d686c0cf44688538" deposit_count: "339" block_hash: "0xaedd455c7e89005ce8a0cd34b997eb55456eb21d7dfd08b0c1978717614285af" block_height: 340 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x02937359af82fb5ab508a78d0a5455edc12d42abc01d457cb808ae23ffe4f3b9" - "0x7fd3c53f7f63b048832cf0492598920d87f4a205dbd16e53c4bb6bc9c9c9d43e" deposit_root: "0xf75235a060b1c539b96b12e4d23245f341777cac99f556f4d686c0cf44688538" deposit_count: 339 execution_block_hash: "0xaedd455c7e89005ce8a0cd34b997eb55456eb21d7dfd08b0c1978717614285af" execution_block_height: 340 - deposit_data: pubkey: "0x81fc32376cd95ab4456f645030a9ccba182da956571ee1136916fe655c8bf08f05244e204bfbc87f696472b3cf3bab83" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8e625f0c45db2539e488bd2272774e46699e690e45fd6e88fa42204d9798a24aa1ea432498172c25671d65450b2ff8d008bc9d87276592803f9568cd46e4d46e1da49db778158256fdc10d8e4dede5194cc51d684887f31a4ff2725113deff26" deposit_data_root: "0x8d6754cda9a15e4c2b26cd6c030a76af60e0dec4e17a008f30164ed9ba746cff" eth1_data: deposit_root: "0xcb7ce227d926f427218766a5fca5311ec8111498381867d4fa68212857ec0e41" deposit_count: "340" block_hash: "0xdc73d2399512a4f010ac368d10034f9ec2ca191af40dc0be3c768a0c56bcf02b" block_height: 341 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x691d6c3d1788448165cd972951b94cca4485afc7571864393cb986aca78a99bb" deposit_root: "0xcb7ce227d926f427218766a5fca5311ec8111498381867d4fa68212857ec0e41" deposit_count: 340 execution_block_hash: "0xdc73d2399512a4f010ac368d10034f9ec2ca191af40dc0be3c768a0c56bcf02b" execution_block_height: 341 - deposit_data: pubkey: "0xa42f4e4ec8732b5a4fbffea9e17a6c208db024f36a899f90671b1910a1dff4b18996b517050f4aacb548640bdf8fe844" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa9bd07d645a9db4c36bf8bb92478ee618c92414a1619a04cf6d39f5ca4fe37fed016b0332d9e9ba62247180f26b001d40c7ffdd2522fa4316e5f1980b14259b279e98da54c01a65d1355d6ba3e827b36476854eef5fce97f01690bd45c9eb7bc" deposit_data_root: "0x0cb2bb82034b6d90b373320449a801ae41fdc49cb4610e8bde86a2073cf91e3b" eth1_data: deposit_root: "0xc8efa837e5b208a1252d1c5caa6e2da3377532093f952df3d8a655cf0960144c" deposit_count: "341" block_hash: "0x281cce8e3af1cba285ad4a6533cbbdd4b16f7c646351d2594c47a54d84685a01" block_height: 342 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x691d6c3d1788448165cd972951b94cca4485afc7571864393cb986aca78a99bb" - "0x0cb2bb82034b6d90b373320449a801ae41fdc49cb4610e8bde86a2073cf91e3b" deposit_root: "0xc8efa837e5b208a1252d1c5caa6e2da3377532093f952df3d8a655cf0960144c" deposit_count: 341 execution_block_hash: "0x281cce8e3af1cba285ad4a6533cbbdd4b16f7c646351d2594c47a54d84685a01" execution_block_height: 342 - deposit_data: pubkey: "0xb4368a6946801366550e764247f27c24bed3c5830a49be21ddeee79a67d71e0aff3d5cc0a9b1e18bad5c9e655ad23502" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4e0e77af815e173a20d602fbc5148918012820754d736dd34549761392b3d8a81af062830ee3d851125ae056201dbab1246b20bbe4d92a3e11f913fff280acefb6dd64508591e1ab9b02a300bad6ebb54e205c80923d892a8db4564c3945856" deposit_data_root: "0x3c15bff5b52d7d846681e0cd70606a0ee32b276c9408b42601fde515b35f196b" eth1_data: deposit_root: "0xa10f1b573d7d012d556954b1fb79a14483d8d45db59f475f2ed8bd0dd38a2f79" deposit_count: "342" block_hash: "0xfcef96a865323635b735de16d7a4e79e58e00efb50920ae9b7f55cbec4dc42c4" block_height: 343 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x691d6c3d1788448165cd972951b94cca4485afc7571864393cb986aca78a99bb" - "0xe8c655eec2a2badc6e31a521cd3847d22c7d67433e11aa8304ba846ef1b4616e" deposit_root: "0xa10f1b573d7d012d556954b1fb79a14483d8d45db59f475f2ed8bd0dd38a2f79" deposit_count: 342 execution_block_hash: "0xfcef96a865323635b735de16d7a4e79e58e00efb50920ae9b7f55cbec4dc42c4" execution_block_height: 343 - deposit_data: pubkey: "0xa4a216ff9a365d29e027a557ae3d4f52bf4fa11654c4314d65a319810fd799c8fb2d129692d7d68f6c134cde9de5d2c6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb62b67e03a9b18faa69f527953e53ca8dc3c14ff793e274314c0495118e52e01651bf43cbce50daf8c93756a43a32f6d10f697c1a37842f1def52372e984fab30010f35b5105f1079563979690d46edc71c80fa6bae135b49a2d7b0a01aad0bd" deposit_data_root: "0x0f433740b767093be9a8d4e8ee049901f378187296b76b352595542022e6bc19" eth1_data: deposit_root: "0x0cccf3ad07bb6129c55118f363f08f6a7eab37150d087d713ab9e4b93c9e3825" deposit_count: "343" block_hash: "0xfa34f90576211ca0acfb7db7cbf1529ddb54a8f319986a7c133b79e15c65f945" block_height: 344 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x691d6c3d1788448165cd972951b94cca4485afc7571864393cb986aca78a99bb" - "0xe8c655eec2a2badc6e31a521cd3847d22c7d67433e11aa8304ba846ef1b4616e" - "0x0f433740b767093be9a8d4e8ee049901f378187296b76b352595542022e6bc19" deposit_root: "0x0cccf3ad07bb6129c55118f363f08f6a7eab37150d087d713ab9e4b93c9e3825" deposit_count: 343 execution_block_hash: "0xfa34f90576211ca0acfb7db7cbf1529ddb54a8f319986a7c133b79e15c65f945" execution_block_height: 344 - deposit_data: pubkey: "0xa814035503cb1adcfdef259521573a5193dfa1e8d74e22649ad1b2b01a44fc6c2352100bc42d6c48584ff1d3a430537d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c4f917adb8706a169c9f93c6bbe2186fd84a81e86f9adaec27391a485afc8e9130f5d940129208437ac6be31ddb50b50eeefceb47751b664ff119be7aee930df8bff802a819c3e9d08e0cc453b7544bc8089b8b9f63c8dc7e2411d997aaecaa" deposit_data_root: "0xea73c129f0be1b4bb10e06fbbe409b22e94e0e4ad06411ee5ef1142fd61b3c64" eth1_data: deposit_root: "0x5a82e52a1ed416eee15a1c097092f7518b4c53a89bf44c76046cbdb4866aee0d" deposit_count: "344" block_hash: "0x625d21649e1542510b4fa7f2570067aec4ecdbaade993f1b33f7fc0448ada465" block_height: 345 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" deposit_root: "0x5a82e52a1ed416eee15a1c097092f7518b4c53a89bf44c76046cbdb4866aee0d" deposit_count: 344 execution_block_hash: "0x625d21649e1542510b4fa7f2570067aec4ecdbaade993f1b33f7fc0448ada465" execution_block_height: 345 - deposit_data: pubkey: "0xaaa334a2fb779ce6de3c557025ff9bf17243deb3f09a37f6719356b54afd9be09a7b82cd589758779544a08cfd3ed5cc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x951f84c57cf1242ce760108e8b5e6ab1b9ea7bbf8ce40198f6a10f2d55838320c9f6e0c2bed2d9eaa4aa3837a9394fcd1562efaa6daeb5b8e0b183924d9786bd2eb94b31952577611f3e1eec834e44fcfab0cacec4632aba7d1ba5a15880f339" deposit_data_root: "0xb6d2d582e7c0f6d7dab60416797b7c84771fe30cb380b25be8c6c0ca12d7c54c" eth1_data: deposit_root: "0x9c2315289da9d6fa488347b4856f84fe558e5e7e186b44256496a538a126f880" deposit_count: "345" block_hash: "0x51046db7f7057439306e943428b8271dceee739b9c2473f00c516959dbec5bfe" block_height: 346 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" - "0xb6d2d582e7c0f6d7dab60416797b7c84771fe30cb380b25be8c6c0ca12d7c54c" deposit_root: "0x9c2315289da9d6fa488347b4856f84fe558e5e7e186b44256496a538a126f880" deposit_count: 345 execution_block_hash: "0x51046db7f7057439306e943428b8271dceee739b9c2473f00c516959dbec5bfe" execution_block_height: 346 - deposit_data: pubkey: "0xaac004b4b25584ba8c906671196db57d7a4f159cfb430b1590d61d94c5c22cb694c25bb6ee850421db260d063e096145" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xac4f0ad93d329006d74a5e51870edd9038900d3e080f74ad8e3362fff86e616566dde3416b752f7b900e235bcf01f58b06862f9678a0dd11d481224afdca5ee9fdaff661e74b4cb70cefb7f691b76a822fa278008f9b611ba9cbb5a0234ccff9" deposit_data_root: "0x8b7c5eb357e9e4abb96dc68302fa6e93c3067abd623b9338a1afa7ac8e16d63b" eth1_data: deposit_root: "0x5ce81fb6b5ba660b0fd450e1c1d8ce22f1b02dbfa8d4f1df5062d70e3aeb66e4" deposit_count: "346" block_hash: "0x51050db6a05c59f2dfcdf79b39dc420a5d52ad575ce0f08b436f6ea02325d0fe" block_height: 347 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" - "0x5a89c435553780c594308fa4372c85b8ac39ab611cbdd7ada19bb99116c7cb4f" deposit_root: "0x5ce81fb6b5ba660b0fd450e1c1d8ce22f1b02dbfa8d4f1df5062d70e3aeb66e4" deposit_count: 346 execution_block_hash: "0x51050db6a05c59f2dfcdf79b39dc420a5d52ad575ce0f08b436f6ea02325d0fe" execution_block_height: 347 - deposit_data: pubkey: "0xad7b6b1ba1f7950cc8e2b5b0cb9041666361eb023b1deff783420482970cf58213497d64cfc91cf06762dd511b0aac31" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5abc0b6d2aeeb6156bd77d50cb67115abe5b519e46a9275f60d02128e2048da62556ff24746037f710a4d5cae3d924c1916f896829525603a9c8a4f7c737c7e9255344686fdb590bf8dc9a6ed3e4803727ace8ac5346cdc650aaf87444cf316" deposit_data_root: "0xcca6725f342e727e05d46aacf15407b225f054ee8edcde7c1e46554ab4d258d8" eth1_data: deposit_root: "0x46aad6ffcc251664c097e6d284162dc501d4d1625ac3585cc2bee8bee47ad946" deposit_count: "347" block_hash: "0x9660d6f0d6d69745bc825562e29c177a86f4ce447e9d90f417f66696454551b2" block_height: 348 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" - "0x5a89c435553780c594308fa4372c85b8ac39ab611cbdd7ada19bb99116c7cb4f" - "0xcca6725f342e727e05d46aacf15407b225f054ee8edcde7c1e46554ab4d258d8" deposit_root: "0x46aad6ffcc251664c097e6d284162dc501d4d1625ac3585cc2bee8bee47ad946" deposit_count: 347 execution_block_hash: "0x9660d6f0d6d69745bc825562e29c177a86f4ce447e9d90f417f66696454551b2" execution_block_height: 348 - deposit_data: pubkey: "0x846f3af6ac23b648a5ea3cdb60b2086e18e42b2837a9d689625af534792f9489a1b22cab64476533993f34149fed1a0b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xae4c2827395dc47a9303a2ec5f5337b5fadb67e813e4bdf0bee32ea1f0a0377e50f1f381313d4d8db576797ce1f1edbc1924e110278ce87761774b7fa6250f81f0563a2c757ce24b7e57143a396087a2a14dae9f06c2787cfb247e8726df18f3" deposit_data_root: "0xb6be3a5becdd7330a4e3fe5176fc77cc1cc107629421a6c373ccf5cf89d12546" eth1_data: deposit_root: "0x473a9d413c0619796c3ffa906b9ba7774339cc08d3f30d468d868ac3ea1fef6e" deposit_count: "348" block_hash: "0x25df98dc1923be776e2e9732e5e667a77f6dee8af43bc1f198dcd43025da3589" block_height: 349 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" - "0x08b50aac114125944b1e0be249589266d73343598f6094b9e13f1c04c4f895fe" deposit_root: "0x473a9d413c0619796c3ffa906b9ba7774339cc08d3f30d468d868ac3ea1fef6e" deposit_count: 348 execution_block_hash: "0x25df98dc1923be776e2e9732e5e667a77f6dee8af43bc1f198dcd43025da3589" execution_block_height: 349 - deposit_data: pubkey: "0xa8784f36c1a8c6e739b090d982480712ff04c9231190b97121c86c84a35cbd561d3372902017ea71fb99ce2a6582f362" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaff0df82cd7d8b804a9f5f62f493936e0d77be3631c1f0d9d295dac98c3d019f534774519582503694a723820031ddb8184de493e5df34c2fb875ee4a0be4c82571b6623546b666d1ce1c539175662b42dc963e6205a243d758f7e1e6c040449" deposit_data_root: "0x8920aa96089e1b189ba5b62754537f9ae53cf2e3f6d0d9c18385bc2566712a24" eth1_data: deposit_root: "0x69b38abb0d6cb1a2914ed20b9c04e2110e2374dcae202360845a9f730e2005b4" deposit_count: "349" block_hash: "0x74905823b1a94f841f1763c2b21604f9ddd31727e12a0c4405a50b70903c105d" block_height: 350 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" - "0x08b50aac114125944b1e0be249589266d73343598f6094b9e13f1c04c4f895fe" - "0x8920aa96089e1b189ba5b62754537f9ae53cf2e3f6d0d9c18385bc2566712a24" deposit_root: "0x69b38abb0d6cb1a2914ed20b9c04e2110e2374dcae202360845a9f730e2005b4" deposit_count: 349 execution_block_hash: "0x74905823b1a94f841f1763c2b21604f9ddd31727e12a0c4405a50b70903c105d" execution_block_height: 350 - deposit_data: pubkey: "0xa398c76ca4aff66b20dfea97e1bbea311a5491b6de44cbcc979bd368818eaef834f188ad6fb413c3120b1af141637cdc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb345cf97868f004b66e78cce43b072e515e647c10b7a06970bf335d4eb67d423977bcbae4ddd3479fc243117a639443a0f730fa27c9173a1fe9c1a336d99aad931e813fc84f11112453bae446b01a363f5a8962bb2fda2957f5cadd0bdbcc840" deposit_data_root: "0xe1e4024334ffdcc89d3c6bb0f633afb6b8cf63e1bf0624dd29e980035a80b1e1" eth1_data: deposit_root: "0x249ae18bac8cbeb1bfb2970234b73368a09d8a2ed6fab14c1a0608887b22c95f" deposit_count: "350" block_hash: "0xe55ef2c7c927098d257769da87f33354267c4f720bd31ee699cae6fe6c23b9ab" block_height: 351 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" - "0x08b50aac114125944b1e0be249589266d73343598f6094b9e13f1c04c4f895fe" - "0x540b74da4539ce3fc72ade01431e3b30606bc85b85cc5cba0c12c3a166746e9b" deposit_root: "0x249ae18bac8cbeb1bfb2970234b73368a09d8a2ed6fab14c1a0608887b22c95f" deposit_count: 350 execution_block_hash: "0xe55ef2c7c927098d257769da87f33354267c4f720bd31ee699cae6fe6c23b9ab" execution_block_height: 351 - deposit_data: pubkey: "0xaf54a32535604e042dc5a7e296a762f3ddc1fe00741eda9acb8f54be49a8244750d6d8f15a10d9384afbd26bccb662af" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa6286e34d6eabfd35e2e69f1541ce7574229d152a95b693b1073874d7505399babd68b1e5d373c5e3a60bb85360d43a51715914324b85b6d52ecb42f129bb1658959ee201c581e717a1ec40e281fa2ba26e2d93f1def180d2d13a58ff9b875e4" deposit_data_root: "0xb1c68778c0ec68fe070016e011f0efe683dcf0d5ccc5ce4a41506027de9409ab" eth1_data: deposit_root: "0xf653f23a48facb6c1c9b5d7df3387f77ed798e75556b335237fcfe8e40e6832b" deposit_count: "351" block_hash: "0x22fbc60289a0213fd65514e255963d148ffac49400e25fc2fec770a6abc36890" block_height: 352 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2be3d691d07573381ecaa9be38f015a03ca00046e7433389a53d83968989b137" - "0x61af53fab3c4897138fbefac5b631a96d505678a097ecfe9a2f9a7905c8d9683" - "0x08b50aac114125944b1e0be249589266d73343598f6094b9e13f1c04c4f895fe" - "0x540b74da4539ce3fc72ade01431e3b30606bc85b85cc5cba0c12c3a166746e9b" - "0xb1c68778c0ec68fe070016e011f0efe683dcf0d5ccc5ce4a41506027de9409ab" deposit_root: "0xf653f23a48facb6c1c9b5d7df3387f77ed798e75556b335237fcfe8e40e6832b" deposit_count: 351 execution_block_hash: "0x22fbc60289a0213fd65514e255963d148ffac49400e25fc2fec770a6abc36890" execution_block_height: 352 - deposit_data: pubkey: "0xaa41628c60365750c75cf91a8d4097047d61c624b01d4f298ac90a66409cada1bb99cf42a2577ba173a94745dd73d6d2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96b47d0a7ea06103c1ccf89698c71e8e05bb361aa564c6a0ddde8cb35ca0827d4c6fc03ef762f9f8919907deb4b7e2c10210757f9a0e03c7edc7e93afe48c3049841940bb352d015fcc404dd065d9aa947aba87074344fa29e126d83165f9e10" deposit_data_root: "0x5809f4140599df5900ef54b70e678188108fcb84993cdf92f63734e016683a36" eth1_data: deposit_root: "0x8fbfbcd57a3f6f5dc37eb7ec56d7e273892dc5e321c1365d220becc4ae65eda2" deposit_count: "352" block_hash: "0x5fa4ed804971ad0bc19fd3038282bb697dca9c7aaca9b413f54fb261e843352e" block_height: 353 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" deposit_root: "0x8fbfbcd57a3f6f5dc37eb7ec56d7e273892dc5e321c1365d220becc4ae65eda2" deposit_count: 352 execution_block_hash: "0x5fa4ed804971ad0bc19fd3038282bb697dca9c7aaca9b413f54fb261e843352e" execution_block_height: 353 - deposit_data: pubkey: "0xa4623cedd189249799b7c9afb49960dd86f31572a6edd594dc9d147bd11b368b66afaff6a2dcdecfa873f88991e5a8d6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa53f69cf2e224bfff70ba77e95b49525e4222ff8f3967a79bcc6244995e48501db0556fc79fba5fb32bcf1cf45c1ba8f17c0eb25eb5fbffc63344807e2627b49e03f8d8e8e9017c0a65f35702f2353eb576141fb10970655d63ac5d89a2e87b8" deposit_data_root: "0x79ac2faba3df339c9a4c1035da2b4319b9b6e007a70479b528b6eb6008281e2a" eth1_data: deposit_root: "0x3d14a58b5cbc0e3146ad1778955f955c855ae299c4dbb24494e291aac4bca411" deposit_count: "353" block_hash: "0xd45a6c4a1391e32940ab1a47bde642ebbeb12849a6909615c317474252c04075" block_height: 354 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x79ac2faba3df339c9a4c1035da2b4319b9b6e007a70479b528b6eb6008281e2a" deposit_root: "0x3d14a58b5cbc0e3146ad1778955f955c855ae299c4dbb24494e291aac4bca411" deposit_count: 353 execution_block_hash: "0xd45a6c4a1391e32940ab1a47bde642ebbeb12849a6909615c317474252c04075" execution_block_height: 354 - deposit_data: pubkey: "0xa58a5d3d29c1331b6f4f977ee08afdf95c067db26c21a591b15db682f93d223acd4e031c98434ec7be34922496ec8ec1" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b2019cbdc2fb49df3257128d61a4e0fa63f451b09a86ef0e5b3084d42a7647d076f03771c996322ce65a4ee05a9bbbc0e7a108e2b816bdb39db1ebe2cc10856864cd8dfa2a042d42fed42236d88b37ef286bff4c5e3176140f140773ccd5505" deposit_data_root: "0x4e2e9ae16bcb8f83129a723e664b4e2d1dbb436655d0c2bfcacf416ca71b3bd0" eth1_data: deposit_root: "0xfc17404478ee17d526ec0e6d7b7f392f0cd2edf08cd20ea72a6b7cafb0bc5d1b" deposit_count: "354" block_hash: "0x48e867e23f93afbce5c768c3e7b24afc6f67bbf23b03ed35f673daaa22e150cb" block_height: 355 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x0e5edf133dd9d31c962d3c832701f118549e950098920f374a8a7f4b1503424c" deposit_root: "0xfc17404478ee17d526ec0e6d7b7f392f0cd2edf08cd20ea72a6b7cafb0bc5d1b" deposit_count: 354 execution_block_hash: "0x48e867e23f93afbce5c768c3e7b24afc6f67bbf23b03ed35f673daaa22e150cb" execution_block_height: 355 - deposit_data: pubkey: "0xa31ecb88e06673a2c3ea98a969827babdd0c6a8fc9569d70c024640f31084c7fc2bc8f00eb65023a008e0b47b3d2e364" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9212c805e5710672e72e9cbf49ab23f0b8849bda05c2eb97599849b0966e814956cceff71141ee1c90a5090e7388e6ce167364b1a5a843e08ab11e42fcb452e70a9b34cde657637ba57002054819440d51b7fefc316897c2dc396e36e3052251" deposit_data_root: "0xe29cc36e9033d65ab7c3214886e01b4071597f461fba82ca0d5b6e2716a96c2e" eth1_data: deposit_root: "0xbc150ef54a71de32ae1cdc80595d7102bcfb75391a31596cd08f93ac573f82db" deposit_count: "355" block_hash: "0x91e6f47ff5874c78e63536737ed9fba1fd13418ad4adafe5d8afa6b6096d7175" block_height: 356 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x0e5edf133dd9d31c962d3c832701f118549e950098920f374a8a7f4b1503424c" - "0xe29cc36e9033d65ab7c3214886e01b4071597f461fba82ca0d5b6e2716a96c2e" deposit_root: "0xbc150ef54a71de32ae1cdc80595d7102bcfb75391a31596cd08f93ac573f82db" deposit_count: 355 execution_block_hash: "0x91e6f47ff5874c78e63536737ed9fba1fd13418ad4adafe5d8afa6b6096d7175" execution_block_height: 356 - deposit_data: pubkey: "0xae32f510734cfe1a05f1a49888185191777008667a62a3b5d71f4b249a5a0421d762c98c0dd0626e17f6326ff525e63b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb278d4156302165853f5a95e5a38a57aad92e6388d231f1616c024ece355b83f9b4ba41f1bb60fc0ae5aca0c1457b5090e84bd06d28288890b17a2244288e4421a4fc1534b190ed3e520a471701e5142eb4374f3e372f4e7b0d754e943455b54" deposit_data_root: "0xea9cace5a73c0c0a4cfc34fe161fe4a0aa802729c46451cd375a524f84032e1b" eth1_data: deposit_root: "0x4ece22540ed44b8d7e55a580ef7afcd709ada5004c4505db558a4fa0ef39e949" deposit_count: "356" block_hash: "0xf9854d07f70ef80e24c9dae43433d2a284b89ee66e5e8912a4ebb92246a268da" block_height: 357 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xec97a0de415ce5348ebe21219a3cbe17938f07344276f64ec40e1dced411c131" deposit_root: "0x4ece22540ed44b8d7e55a580ef7afcd709ada5004c4505db558a4fa0ef39e949" deposit_count: 356 execution_block_hash: "0xf9854d07f70ef80e24c9dae43433d2a284b89ee66e5e8912a4ebb92246a268da" execution_block_height: 357 - deposit_data: pubkey: "0x9407a54a336fb7632ed16da2929c6ed1e2a8a969990d15f9f322734ee60c00757dec74e4c0224e813efeb1c9be42c09e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xafd6a5b56011fdc9d506d7c468993d690e2416b8322a5117fbfaeba9e4f15a6518d1f6b4b6917f381e96e396f8a5ff0c13eb33425c2247af685cc4723322d0e1596a3e1d0013871ac6603ef6fa4c74eddf2707f60e19fbb84073113afaa9ce5a" deposit_data_root: "0xa27fecc07480ce7de9e8fdcab0a5371632f26446c6a1a7e5594cd3b05f91c879" eth1_data: deposit_root: "0xb6e2c6e1112b2143ea4480f062c4c7c648307419c43032304281f44bcfe04578" deposit_count: "357" block_hash: "0x624663feb3f1449b2b425c886c243ab42cb4bbe01a06f1d47421134df7b63475" block_height: 358 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xec97a0de415ce5348ebe21219a3cbe17938f07344276f64ec40e1dced411c131" - "0xa27fecc07480ce7de9e8fdcab0a5371632f26446c6a1a7e5594cd3b05f91c879" deposit_root: "0xb6e2c6e1112b2143ea4480f062c4c7c648307419c43032304281f44bcfe04578" deposit_count: 357 execution_block_hash: "0x624663feb3f1449b2b425c886c243ab42cb4bbe01a06f1d47421134df7b63475" execution_block_height: 358 - deposit_data: pubkey: "0x8fe3971515fb25cbe62a03e4a593dfb4cc3563bc5b7866dfe300b958a53f07fdde463fc7abfe349a2eedf38d569cd126" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8f51e38f6033d91644cd646777b584c8ee985d18951ea4f184e5f321806b111881584c65d411542e99899832620664c60c6bee1be977e63041276f81f6daaf7b1931cdd4c725faf85b5186f2001b18e4e6cfb2c562cf5360bf76f1783ad54b7b" deposit_data_root: "0x28cf518415e14159c030d4c9ce4e1737eb8dafd10f8c9f3668c1a157b5f5ec3e" eth1_data: deposit_root: "0x0b066def513f0615242e17a3fe521dcd78226abfbfa040203591f1f9587b3877" deposit_count: "358" block_hash: "0x3492958f15fa544dbe4eac07ce27c1ade01e53ce22cff0aa6e5688a50a53af73" block_height: 359 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xec97a0de415ce5348ebe21219a3cbe17938f07344276f64ec40e1dced411c131" - "0xd34bdde7bf541ae5af14a22f182fe4a5087d292e96c952ec405b9c04fd71645c" deposit_root: "0x0b066def513f0615242e17a3fe521dcd78226abfbfa040203591f1f9587b3877" deposit_count: 358 execution_block_hash: "0x3492958f15fa544dbe4eac07ce27c1ade01e53ce22cff0aa6e5688a50a53af73" execution_block_height: 359 - deposit_data: pubkey: "0xae99451101dde8ce7d7f1b784fe2a1fe0974cd3d7e8d2d3c775892cdc2dfc021eb9f7a5b60681fe7369ec88884e6299a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa9e4c4aa80a317292a1d42a7dd6d18cfb04c7087a078332b7ca9c1fdac29b8019a2f6f2cb3034362a63ac7ceed7616510b6c45212fd0ebc2b7851293c4c46d1aa3eb99b7df62891c30e83d2a1a58f5bc91ad4278655f8482dd14bb0941ab37c9" deposit_data_root: "0x69b84b7fa3b0dda0b7eaf825ac386bd2416359a1c076743901c727adfbad4022" eth1_data: deposit_root: "0x0a872a65e20b1d6eb13282886f5082a99b3ac36e5636c6b7667d6f7b454c136f" deposit_count: "359" block_hash: "0x05f878ea1b32f42d1b5eb823c090f2789b19a062bc3495d80402a3077ccab36d" block_height: 360 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xec97a0de415ce5348ebe21219a3cbe17938f07344276f64ec40e1dced411c131" - "0xd34bdde7bf541ae5af14a22f182fe4a5087d292e96c952ec405b9c04fd71645c" - "0x69b84b7fa3b0dda0b7eaf825ac386bd2416359a1c076743901c727adfbad4022" deposit_root: "0x0a872a65e20b1d6eb13282886f5082a99b3ac36e5636c6b7667d6f7b454c136f" deposit_count: 359 execution_block_hash: "0x05f878ea1b32f42d1b5eb823c090f2789b19a062bc3495d80402a3077ccab36d" execution_block_height: 360 - deposit_data: pubkey: "0xb5dd36fb996d68fb9dff117081435088b54509db6c3bdcbe58bb3711fd21b62f22f7ffef9b8ead2031c0c187717ca738" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa704de41a3d802906eaa920016df241c8e6a483b25b6a144811305341d631c9159b7453c16fc7266c005d20a362b52ea1322e545ccb84f995f863b30f5b31d0af2824cbd21cf7dfce43fb369cb77cd92dfa58ea2c515d99c4b1e82b30a4001ba" deposit_data_root: "0xe392df1901cb47c60f7a23312f4938957258d1e4552775a6c9e1716318ebc23c" eth1_data: deposit_root: "0x566ee27dc76d160c182b89a8152d85644ad00ae1a6dffa89e096d383f612e4f0" deposit_count: "360" block_hash: "0xe3a5318a234c6d5ceddb72a5dbcdd3d1424a17d8ca7b08bc7bbdd55b6aa0d9c3" block_height: 361 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" deposit_root: "0x566ee27dc76d160c182b89a8152d85644ad00ae1a6dffa89e096d383f612e4f0" deposit_count: 360 execution_block_hash: "0xe3a5318a234c6d5ceddb72a5dbcdd3d1424a17d8ca7b08bc7bbdd55b6aa0d9c3" execution_block_height: 361 - deposit_data: pubkey: "0x9376161dba759909776ec807351e1cdafbff9a9d817babba680c953344a80dcaa38378ac6a7fb3079d909f5907310336" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b38fdafe54fb8e27ad780c4fa0910777e6d0f8ece579bfbd4a0cf121eca3de1e1e19dfdf284db7516d25265f9c989210ed3894e1c6c6e3365d99e9f3357b39bcf791ea2e08c43059e2adc753ea6c96a68ca0134395f7b8cb25662d87339157b" deposit_data_root: "0xb1df04177e3328845d9af042b46eb4b7b5d4d0c8c884a28c2ad183ed23801013" eth1_data: deposit_root: "0x77959d8e2c2c5ce3fda7eb96f376f88a281224e3eaf3fe232d20d35eef2d4f2e" deposit_count: "361" block_hash: "0x42046b4ccdbc910edab7da07038bb06f7cf7a9f01da446b7896260e2fb0a797a" block_height: 362 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" - "0xb1df04177e3328845d9af042b46eb4b7b5d4d0c8c884a28c2ad183ed23801013" deposit_root: "0x77959d8e2c2c5ce3fda7eb96f376f88a281224e3eaf3fe232d20d35eef2d4f2e" deposit_count: 361 execution_block_hash: "0x42046b4ccdbc910edab7da07038bb06f7cf7a9f01da446b7896260e2fb0a797a" execution_block_height: 362 - deposit_data: pubkey: "0x8d92d91ccf259f1c3df11d2e4e92cbe047a9b278ab9ee1341835a08da4c957950a70f51d62bbefd4c6f3c01511e39796" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83b14219e42c4389f315892b1f7bf34a7d9649aa91086b2a3a5d06fa5822af504b9f46364e39a5406a33bb8feb3baa540f90dda0d091ca6cd9df322bb81e1220af8a63a3ac9f5bea4db7ea883d8e7b39df07c59f7d478c9754455e84f556d1dc" deposit_data_root: "0xb65dfed61fae9bb5cfe7b84bb94b11aed1949d8c0f2ab1bad962aa2639ee9ea5" eth1_data: deposit_root: "0x8ce66b4067fd288192b5cf456c79dbf793d86adf144f0ded5837fa2f916330dd" deposit_count: "362" block_hash: "0x30caf55961a0afa34e0ea7fe1c82badaf3bcb966c3e27b5f6d28f5dc90cdac8f" block_height: 363 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" - "0xededa6672e4f4f520b91640b5d0e396d02af2d267ed8a7f99ec6844a81bd3197" deposit_root: "0x8ce66b4067fd288192b5cf456c79dbf793d86adf144f0ded5837fa2f916330dd" deposit_count: 362 execution_block_hash: "0x30caf55961a0afa34e0ea7fe1c82badaf3bcb966c3e27b5f6d28f5dc90cdac8f" execution_block_height: 363 - deposit_data: pubkey: "0xa95aa6bfc756de15cb1a21d05b465afd5bf806faee4e662ec335d1e093299632f9498dff50c71844e28d98b0d2cb9e29" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xab509e72eb0293f13ff2cb2dea99e6289562f8315b1f70c913f1a7705b45c6398150df3cc1991edd1ef7d0c72cd0925712a04bf9161f3f7d5548ec6f0ec4c2271054fcca875d6258a204d5478a4396dafcb2d99083ef2c990111cbe6c9b62b07" deposit_data_root: "0xf0a5d8ef855f6d121a251189ad5dfe512c221f0f27e4f7225fc37e163001359c" eth1_data: deposit_root: "0x8c048d62dd48e2676a75bf37278cf8a81934a702809656d92f153568b81893a6" deposit_count: "363" block_hash: "0x7dbc675b430d7c2de00d444ad4babab187b9590770a385b9c34b97f8f9db8bf7" block_height: 364 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" - "0xededa6672e4f4f520b91640b5d0e396d02af2d267ed8a7f99ec6844a81bd3197" - "0xf0a5d8ef855f6d121a251189ad5dfe512c221f0f27e4f7225fc37e163001359c" deposit_root: "0x8c048d62dd48e2676a75bf37278cf8a81934a702809656d92f153568b81893a6" deposit_count: 363 execution_block_hash: "0x7dbc675b430d7c2de00d444ad4babab187b9590770a385b9c34b97f8f9db8bf7" execution_block_height: 364 - deposit_data: pubkey: "0x89f4dc26316e4037269b4afd3d92f7aa9d768be37dd951829657941f2220f7546071ac46a72d715a1af71689982afe61" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb7be13f710902b118aabf1b4e84f6e67bb72bb4df89a9444dffcdc9db966fd451b4f16cebfa6546a41f0b7ec4a52baa206133d4190cbcf26b266d5f0dda6231d720a0cfb21c671008b84b230f851a4e9bdb87c78f81a2c4cee31bea858596c68" deposit_data_root: "0xbbd775efe2df031eb9719e580ea4259844d508dcaeb723b6698c3896dee27771" eth1_data: deposit_root: "0xf5ed206c675198fb290d0298805bdd34ecb569f3a14bcddba8343424118d0609" deposit_count: "364" block_hash: "0x8969f759d3bd762bf45f15e4a30f4c733ac0a822a698027610cac5618cb35e91" block_height: 365 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" - "0x6ad91868ba8f36bf1cf9fc3a3226e8fa1b5b3182911ab1db6c7bfd830938d689" deposit_root: "0xf5ed206c675198fb290d0298805bdd34ecb569f3a14bcddba8343424118d0609" deposit_count: 364 execution_block_hash: "0x8969f759d3bd762bf45f15e4a30f4c733ac0a822a698027610cac5618cb35e91" execution_block_height: 365 - deposit_data: pubkey: "0x812c4ef835a77db7ead5b86773755711051cbc34cfdc4be7eb41a99ce5094f7d12412a7215275cd9ae8d8426eb91dfb4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa6785218f754ef90bb5d5b308a6b1bd2078c6d1c03845c874515ae4fb2da4b44dd4d34dcfaf5a5057b8f90d0e9154e56155038a0dd687eca319de2270b634a6d0038f72a05b6c89e85c00c53a4ef259dbe3f1300c7bf4c63c2fd1e7b62488abd" deposit_data_root: "0xdae505a2425fa70ac7714c907d1918d77c0ef04f4654bc884353791f0b148071" eth1_data: deposit_root: "0xbab7a3b70441e52c82a2a43408ca1f6957abf9f2189daca60838341f23a14cbc" deposit_count: "365" block_hash: "0xc56ca86bea734411f9a9a8ce247094bbd5d632888cdbe1938df31acb880e662d" block_height: 366 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" - "0x6ad91868ba8f36bf1cf9fc3a3226e8fa1b5b3182911ab1db6c7bfd830938d689" - "0xdae505a2425fa70ac7714c907d1918d77c0ef04f4654bc884353791f0b148071" deposit_root: "0xbab7a3b70441e52c82a2a43408ca1f6957abf9f2189daca60838341f23a14cbc" deposit_count: 365 execution_block_hash: "0xc56ca86bea734411f9a9a8ce247094bbd5d632888cdbe1938df31acb880e662d" execution_block_height: 366 - deposit_data: pubkey: "0x8cfd6c4fe7aee61657f1d6e5cff1d41d24bafab7ceea78d2f5d680f8b51aeea83ddbb39bf6978bbf1327a2d240012551" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8e2e30e4d30c5401f9fa6260da87b0468c53580f230c36255690955f4fddf3433da05d174390d687b79749afac5870c19b33d828ee655d6084b4a346df8d0aef3ef8491e99855e80d9e6413d0e28ae091303e3af2148166eace0d828eecf868" deposit_data_root: "0x2873cca6fb60ed389212d5624bc18fdd882ccfb57d60c6fa5858bcee68ce8f8d" eth1_data: deposit_root: "0x31afd21b630f676a5b7673355f85afc5c2b4206ff10a7200586b0a61e918c632" deposit_count: "366" block_hash: "0x6d39ef06bbcadfcc1889b64112e7060c1f2065d6b254466e765603decd8b505d" block_height: 367 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" - "0x6ad91868ba8f36bf1cf9fc3a3226e8fa1b5b3182911ab1db6c7bfd830938d689" - "0xca7eee30dc4dae479488e27d2be31d92c9f9e2e3cd1b76c56bd8c0f895399c1c" deposit_root: "0x31afd21b630f676a5b7673355f85afc5c2b4206ff10a7200586b0a61e918c632" deposit_count: 366 execution_block_hash: "0x6d39ef06bbcadfcc1889b64112e7060c1f2065d6b254466e765603decd8b505d" execution_block_height: 367 - deposit_data: pubkey: "0xae7c6ebb4d7b5f462da2004698a6dc54f1e55ef0f3ecd0bc155c9b58f67a038422e209492c86c986d8f24f5261126f51" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5e4a27b8a2a022d4f4748b6277a7a3400866ccbef70d8b13578af0227c4491a9fb4934e23342bef47277ebbecebbcf101334a722540f70c1d3d768c870cfbf2cc3fba8cb7260dcb794b455083f4a092e54d441d5acee80b57d9d9ca8ee34057" deposit_data_root: "0x0b99abe0654b3fdb3e10c60bf63da44170f75887fb61a4be8119ac5d7f84f7e0" eth1_data: deposit_root: "0x25e729835c195d00e120e374d28e26a9e19eeab013878aebbc5b37b29f2c61a0" deposit_count: "367" block_hash: "0xb187bb0435d4f02e62beaaf1833b7ae3cd93e1acc0fc9dbfdf24f6d0b48d3d1b" block_height: 368 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0xc93d9dcfae7c9e728958d0b093f1fe4ae72fb7d51eb5bc91a9a106e417426fc1" - "0x6ad91868ba8f36bf1cf9fc3a3226e8fa1b5b3182911ab1db6c7bfd830938d689" - "0xca7eee30dc4dae479488e27d2be31d92c9f9e2e3cd1b76c56bd8c0f895399c1c" - "0x0b99abe0654b3fdb3e10c60bf63da44170f75887fb61a4be8119ac5d7f84f7e0" deposit_root: "0x25e729835c195d00e120e374d28e26a9e19eeab013878aebbc5b37b29f2c61a0" deposit_count: 367 execution_block_hash: "0xb187bb0435d4f02e62beaaf1833b7ae3cd93e1acc0fc9dbfdf24f6d0b48d3d1b" execution_block_height: 368 - deposit_data: pubkey: "0xa4ee2d6f77a08089c71194ab48c338632c6b1041c326a483033aecd1bac1baf5de221053ea15c9fbdb8584edec6a731f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa868efa2a6b92d1cc547bf3352b67b142dcb106cffd3510caa09eca8071bac276d217af7aec4551b8da80f1dd7c5d62117c74d40e9204580cf0d68ef795e9c226ca17a0cc54f8da1fd5c9ed4a9721c27f646d3c8166cf711de031d1442793bd7" deposit_data_root: "0x8ecabb629b1e1da971d5edf0f68c6f7e56a15adf30f5a224ced581e1307efa17" eth1_data: deposit_root: "0x71a7e69529e1627bebfe2eb84e5387960b67bfb45ea7c73b36e9f26b039abb48" deposit_count: "368" block_hash: "0x24625a939c0317893b0a4ff7e485998efedcc1219caf706cdcf98a955ac6eed0" block_height: 369 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" deposit_root: "0x71a7e69529e1627bebfe2eb84e5387960b67bfb45ea7c73b36e9f26b039abb48" deposit_count: 368 execution_block_hash: "0x24625a939c0317893b0a4ff7e485998efedcc1219caf706cdcf98a955ac6eed0" execution_block_height: 369 - deposit_data: pubkey: "0x82d62ceb1242d6dc6527d8f885fe301f4313b87e7e336a34a8d3a898ffca180dbc624f45e1dc07695cecc54023207400" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xafe8ea26e0356b1ffe34ee1f6e50d8f046ab3d7eaa3decae78fede0b56b8b04903031de2fb45a877b80ad5baca8dc6d900adf83f4617563bf9658627a40b601f5ee3e53980bc51584ee4c05ce88c3ca720b1214697668104dae210e7cbffaaaa" deposit_data_root: "0x73aa59f819c871ac6651030e64fbeb030153e12d230d516c22b768230dd7c65c" eth1_data: deposit_root: "0x427c76f57c454b3d1154f3df3f645e88551b6d51f544aef9789dd63f26dfb705" deposit_count: "369" block_hash: "0x791a39d5642a805a00de9be73ed412bb5870ca828e2b8bd41e1ef0919336860a" block_height: 370 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x73aa59f819c871ac6651030e64fbeb030153e12d230d516c22b768230dd7c65c" deposit_root: "0x427c76f57c454b3d1154f3df3f645e88551b6d51f544aef9789dd63f26dfb705" deposit_count: 369 execution_block_hash: "0x791a39d5642a805a00de9be73ed412bb5870ca828e2b8bd41e1ef0919336860a" execution_block_height: 370 - deposit_data: pubkey: "0x9337d74573784dae1f5badff018e4f1c5a2f19d1b57ac07a2f12dd628ed97a4b3a4c84ff4c7d291063f78ec15ec163ca" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96eb75a5657091aa6019a5b6755aca55b675e7ea964b4e88c4f3528d47768cf37b5edc524325b3f969ccfab550d0e3f4027ea30bb3a2ba00c9cb850a7391a7d37175b5f790ef21b710b25bfa0e48b18ea67d8f51c77fda44da5356750a1d77da" deposit_data_root: "0x0bf34b47edadc088a1567b156f78bf0b3ba212689efb7262d3e992f106b79228" eth1_data: deposit_root: "0xa7bda8ebefccf3bf5ec32d0a67a48d1266fdcc537bea36a2c2e721aa2149be77" deposit_count: "370" block_hash: "0x47a677735c1aa41443778a8f1d010fd55ec000d87ea1b41d9f7b06e3ae6108f3" block_height: 371 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x415cb916cdf12ea2e3a80a5a17730fb71ba09e3dee19953b2144ff451717f33a" deposit_root: "0xa7bda8ebefccf3bf5ec32d0a67a48d1266fdcc537bea36a2c2e721aa2149be77" deposit_count: 370 execution_block_hash: "0x47a677735c1aa41443778a8f1d010fd55ec000d87ea1b41d9f7b06e3ae6108f3" execution_block_height: 371 - deposit_data: pubkey: "0x91fa5a8682921fa6dce932b8a9cd3e58ac485c03ef81202f69635f463ced2b366a85a3b6aff905542840c05b5739d7d4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8360efa2ef67875dd7e4ec4d36b39f47adcee01a71d891c61a398413a3fd4e4d26f47f4dd72e4eb193f309d65409567302f99039c476d4f43a03d47285af9d9cd4ae8ab5ee1b9f6f0fc2c90511704414619a4de063ae1248fafc7d0c3822ec6b" deposit_data_root: "0xde1d11e466b6199447c8461b2b04c55cc78b3d53aba3dd0f663c2eaa0e6f3d8d" eth1_data: deposit_root: "0xa6897fb6ab9ffb723e0af72cf18a2f1baa6356017f5931ac3a96050d0a02a0ba" deposit_count: "371" block_hash: "0xb6ea6ec5773f90cd394c362390e482e0526049017d7027be09902e00dd800d05" block_height: 372 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x415cb916cdf12ea2e3a80a5a17730fb71ba09e3dee19953b2144ff451717f33a" - "0xde1d11e466b6199447c8461b2b04c55cc78b3d53aba3dd0f663c2eaa0e6f3d8d" deposit_root: "0xa6897fb6ab9ffb723e0af72cf18a2f1baa6356017f5931ac3a96050d0a02a0ba" deposit_count: 371 execution_block_hash: "0xb6ea6ec5773f90cd394c362390e482e0526049017d7027be09902e00dd800d05" execution_block_height: 372 - deposit_data: pubkey: "0x8631b733c42dcdc91e0852655e1513864b50fd75ca1078a205205afd3d2c0de2cb2da63c06f4f547212132fd66bd7d16" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4258cf976f155bb4eb8566777cf34184a34b1c8090f931c9160c0b616afae1182256741674af7df73e11ff1db5dad7e165d952269a1aa8a68a523e87a9de14d00c3a928e97a1e7e74aab45331d12f23ec55fface9826bec0c71d3d985624b49" deposit_data_root: "0xf449648967e51c3ddd171deffae8afbbd69753f29f5f65659a6a2c6bfe4191db" eth1_data: deposit_root: "0x96fb5489ed0128e41f8d22f65a9e02b05e3febfa35b4a0c2ead831cb68e0f1dd" deposit_count: "372" block_hash: "0xe7dba8e784a1897ee5404a1cfb172fd5e5897c784e72596431b8b6cd7caf0fa6" block_height: 373 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0xfdb57c8fa36c5390b466ad79c9bcd9f3991ab173af3c339170f8c82eb63f0251" deposit_root: "0x96fb5489ed0128e41f8d22f65a9e02b05e3febfa35b4a0c2ead831cb68e0f1dd" deposit_count: 372 execution_block_hash: "0xe7dba8e784a1897ee5404a1cfb172fd5e5897c784e72596431b8b6cd7caf0fa6" execution_block_height: 373 - deposit_data: pubkey: "0x965258ea99b6f1eefc8d8196fad346c44b559e00fb31baf7cdda18e25b185eaafa91e3e366712514ab3ab855f41c9600" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb70f284e086d2d8d95b2fc7adf1937e52732e39294ef3b836df58c7cd8cb3fbada21137cd66070b82799cce72a4d741f0b66bfc892c5c3ec6ae1aa6e583f2abc05994af795607753085b556955cbd33df389e9ed86addc952a78a8f959c42711" deposit_data_root: "0xb2b1703e6974ab25bd10e04e11c2e1f427cae39f2a5cade05266982616651ec6" eth1_data: deposit_root: "0x5af7c0eefdca4998093fee555e6b38acaf0ab646a17afb02712b2fc83f405d20" deposit_count: "373" block_hash: "0x5967feb20145233cf4deb33b3595e0f074a8c3af859acde36bf21d8d412020f6" block_height: 374 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0xfdb57c8fa36c5390b466ad79c9bcd9f3991ab173af3c339170f8c82eb63f0251" - "0xb2b1703e6974ab25bd10e04e11c2e1f427cae39f2a5cade05266982616651ec6" deposit_root: "0x5af7c0eefdca4998093fee555e6b38acaf0ab646a17afb02712b2fc83f405d20" deposit_count: 373 execution_block_hash: "0x5967feb20145233cf4deb33b3595e0f074a8c3af859acde36bf21d8d412020f6" execution_block_height: 374 - deposit_data: pubkey: "0xaff02f3635554e57d140069596a9c3463e85408521b2349b6d1d5c4223874086dfa5a58f8ca73256ebfccc63fb88e58b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa04bb8b421c6e3a97b2d678db62adffaded29db686da4adfe0e05dbb50e55cb95631a5298136778ac5d0fed413b291cf042ea8fd3406cb4cb196bdf190eac79e2e3526943df94b58465e40925255d38fcf6238069bfab4a3349d7e02490ce24d" deposit_data_root: "0xb2bf57e882657383825bc6f7228e5a6c1c518c48de44a855ac853b521d8d28a2" eth1_data: deposit_root: "0xc88fceb356cfdc6fd64eb70a98fb873d921cbe2bfa77f357695682a1db122bfb" deposit_count: "374" block_hash: "0x4cbd9a54874e2dff03520d5313f7d0f436fd15e2e6adf2010430159f3c884345" block_height: 375 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0xfdb57c8fa36c5390b466ad79c9bcd9f3991ab173af3c339170f8c82eb63f0251" - "0xaa4ae80e4b97e7e7234fbf9b4581551d8b01473b0e06b9ae16eda5add93de3b1" deposit_root: "0xc88fceb356cfdc6fd64eb70a98fb873d921cbe2bfa77f357695682a1db122bfb" deposit_count: 374 execution_block_hash: "0x4cbd9a54874e2dff03520d5313f7d0f436fd15e2e6adf2010430159f3c884345" execution_block_height: 375 - deposit_data: pubkey: "0xa166c85614c5b0d5af165a42ab98515c009b6eccb740213e6ec1268e35aebaa73b8c9b22711aac0d5087f2534604eb36" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2f0a3f9d23101580d45e327cb58559a0eb0da2ef98ba8296040c0189c32cf5d400e49e45d408961a44ec1755f303be516949f3ed899d1b0afaa4cf3c237f7c1dcf538539d48c8b013601db131b2753b456bfa683922a1be60f306c491958146" deposit_data_root: "0x635116788f81411826a4bab6c7b0c4d22d8a100053efca983cafed46f19c1128" eth1_data: deposit_root: "0x41e8cec2e3a73c8bf38474b5ca18043b11f11c9ee9eb0cacc2ffb740e5a57c12" deposit_count: "375" block_hash: "0xafa631155e92b5e36aa357fdcb2c59894f96d85f0cd7e7704da84c28de104088" block_height: 376 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0xfdb57c8fa36c5390b466ad79c9bcd9f3991ab173af3c339170f8c82eb63f0251" - "0xaa4ae80e4b97e7e7234fbf9b4581551d8b01473b0e06b9ae16eda5add93de3b1" - "0x635116788f81411826a4bab6c7b0c4d22d8a100053efca983cafed46f19c1128" deposit_root: "0x41e8cec2e3a73c8bf38474b5ca18043b11f11c9ee9eb0cacc2ffb740e5a57c12" deposit_count: 375 execution_block_hash: "0xafa631155e92b5e36aa357fdcb2c59894f96d85f0cd7e7704da84c28de104088" execution_block_height: 376 - deposit_data: pubkey: "0x967633e5396683a4d51ac8e531194d8243fb808b3237c5ff635afcc0c6ab3fab8443cf9bc7268c25c85d5c9d3b42463c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x920074fe4578a343f3c10a152857b1301b3bd370b5fdc6e9f806f46f59360c24cc06b6736572613ec332d06032280b2117f89e75a93ce3102032f5326382113bbb300c6b3e5ce36921f661212338f5342683ede2eb3505bb4ac720cc3c60263a" deposit_data_root: "0xfd47af7a32eeeebd5d5e99faf7988bc11d295a16351dd61802acf29bb7c7c48d" eth1_data: deposit_root: "0xc334c97c33e4fbbd1cb28802b5845db45ba26f0583b88374f650c08f577a4629" deposit_count: "376" block_hash: "0x0477978ff52a8aadcc642ebf3e523c6fab4b2be5cd8e92abaf545f1f4974aabc" block_height: 377 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" deposit_root: "0xc334c97c33e4fbbd1cb28802b5845db45ba26f0583b88374f650c08f577a4629" deposit_count: 376 execution_block_hash: "0x0477978ff52a8aadcc642ebf3e523c6fab4b2be5cd8e92abaf545f1f4974aabc" execution_block_height: 377 - deposit_data: pubkey: "0xb3dab04913697100af2268f8d71e4daaa6475d08785b4ab816d1a9d209703abdb3e890dcec518c88cb5983d30e977408" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x84f73f81a47107e055c2332123f547da1c2d16e3434b8f2a2cfc18d2f23c17257cd047b6bc12cef2c1e32473afa897f802ada46f50d4c910ff4048927c64c3983e42c8c5e3681da8ed296589b8481314ddf847049451cdc7e429520f2a2f5ef3" deposit_data_root: "0x6dad28a69491a04e60893860dba1bc4be2ddc602499a2c1893fbbc9f3a24ebd6" eth1_data: deposit_root: "0x2817a89668f5bbc79855acf38ecd0089aebd5aed31a3a919aae56f2609d16eb4" deposit_count: "377" block_hash: "0x5e0a1b630591445514724260df8d60a7c36529f0d6c532b19b8115681c754df6" block_height: 378 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" - "0x6dad28a69491a04e60893860dba1bc4be2ddc602499a2c1893fbbc9f3a24ebd6" deposit_root: "0x2817a89668f5bbc79855acf38ecd0089aebd5aed31a3a919aae56f2609d16eb4" deposit_count: 377 execution_block_hash: "0x5e0a1b630591445514724260df8d60a7c36529f0d6c532b19b8115681c754df6" execution_block_height: 378 - deposit_data: pubkey: "0xa4bdf84013dca6a9af8d56d0bec9767a969d7b0b88802ef0eac99a9551dcbc7e03336e63943d8cd072be2d2915d9db25" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8da17c87dc9aad2a3ac17331e00065d70a1c5351f063d22e23f9047d45938cec61ce0f0eba5966a85694dc30298fce9f1726b82286483f93c9ee867095eb398daa696e6ff40d0b525c1d249f48359d70f7f115c53f45a517d1dc1d024a40991b" deposit_data_root: "0xd9d6dd6ace596c76d133833e081bfb09dae6f0b3fb68ff016b2c3157e19ecc16" eth1_data: deposit_root: "0x0c72dbb6dec2b4a4f0b06aff6b28e5d323de1238e9c38b01414d588302cf341c" deposit_count: "378" block_hash: "0x613eb202e2e6e48ddab9d97aa5bc39164d7dac1613890ea7840783b6abc54c58" block_height: 379 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" - "0xe1fb9fc453a915b6bddc83453cbc120de96754c37d0aabe33eae0320527ced59" deposit_root: "0x0c72dbb6dec2b4a4f0b06aff6b28e5d323de1238e9c38b01414d588302cf341c" deposit_count: 378 execution_block_hash: "0x613eb202e2e6e48ddab9d97aa5bc39164d7dac1613890ea7840783b6abc54c58" execution_block_height: 379 - deposit_data: pubkey: "0xb83a5503f8875dba99bfb8077c50b56120456f836cbb8b89a24e17d88c76071ed9b08a54500ad8e24382a43fa67df89a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb5eeec2defcdfb4015ec6f688f641a597f533106ab62765585e59e86a27e807cf322008469bd8e3649fd7ae4a367ff8a05956b65081161d7f227bc72a5385696e36a77a1c9b77d4bd553be66e1166efa80b9708605f6480dbf72ffa229a43c29" deposit_data_root: "0x174145bc6f9323ff01709c7c767c1a2f3e2608a17e8393966c64a5f1a34ad0b3" eth1_data: deposit_root: "0x32dc12145beb7653b4766efb4d84b1590f50be40852bb4281f0f29c0e1c5d874" deposit_count: "379" block_hash: "0x76901b62737505430cab3df9d5e8bcf58ec8f86c3db8c95a3cd14838a28a923b" block_height: 380 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" - "0xe1fb9fc453a915b6bddc83453cbc120de96754c37d0aabe33eae0320527ced59" - "0x174145bc6f9323ff01709c7c767c1a2f3e2608a17e8393966c64a5f1a34ad0b3" deposit_root: "0x32dc12145beb7653b4766efb4d84b1590f50be40852bb4281f0f29c0e1c5d874" deposit_count: 379 execution_block_hash: "0x76901b62737505430cab3df9d5e8bcf58ec8f86c3db8c95a3cd14838a28a923b" execution_block_height: 380 - deposit_data: pubkey: "0x83e32149769b6c9091f8921195802c8948cfd2b6c9bf9760e70641757719e028d0e65c85bd0fccbc10b81cbad1c87d9a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x93b8c60e836c5181647760ae65b7b5f14a89c2b09dbfbfd96aad5dcd2f569414e50e0008e821b9abf0b7b7e7c7e389a00b7cd596c6410826d484d31aa303a134c4f518d7351abf82d8d745944924bb3240ffa81d2bbfb4b2ebe1cc241aa9bf65" deposit_data_root: "0x8970139619fc0b0d1fcb5f385618ce7d725d20c55c85a77aea8b749d5ae5dd33" eth1_data: deposit_root: "0x1fcd7cba4e2a28308ec039550a5044e24d2e76576f39e7e5d6d08325cd8f820d" deposit_count: "380" block_hash: "0x941b810b7df953ef1c939599bf5f91fa02b40c02ecdbc9db3b835903b85b4ee9" block_height: 381 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" - "0x05b6bbc7f807ab0dcc2cc1033e4743bfa978b4068e735ef860846a4ef71e4ef3" deposit_root: "0x1fcd7cba4e2a28308ec039550a5044e24d2e76576f39e7e5d6d08325cd8f820d" deposit_count: 380 execution_block_hash: "0x941b810b7df953ef1c939599bf5f91fa02b40c02ecdbc9db3b835903b85b4ee9" execution_block_height: 381 - deposit_data: pubkey: "0xb3b60189b0b7dec69db000719fc89cc811c60e70b80d764af86a9dde1c4becba8e561d9f4ca5437481f01b0d7d1fc807" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x959a30b65aafdc7e021fecd8d5eba6e2b0a4d0dd63aff40824a6a3b9b1b63804be39acce4df08e4025ed5445c606761d0f0090182aaed4727b7d5da87b0437e3a5ff8b395e9e4d241fc3f822ce92717733c58d54172fb14e7ca07aaa85243835" deposit_data_root: "0x4282b4b40da830d37635588ea701f4837f32e70f1a4177192b5f3f9e53991a86" eth1_data: deposit_root: "0x391f2ad9469d6191d978da35b42beddd2f61857f0ca40c88b395913d472c1b83" deposit_count: "381" block_hash: "0xdc138b7ce041cc906320c6e6180e0410b939b18fa470ad5531bb3eb5484dad2c" block_height: 382 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" - "0x05b6bbc7f807ab0dcc2cc1033e4743bfa978b4068e735ef860846a4ef71e4ef3" - "0x4282b4b40da830d37635588ea701f4837f32e70f1a4177192b5f3f9e53991a86" deposit_root: "0x391f2ad9469d6191d978da35b42beddd2f61857f0ca40c88b395913d472c1b83" deposit_count: 381 execution_block_hash: "0xdc138b7ce041cc906320c6e6180e0410b939b18fa470ad5531bb3eb5484dad2c" execution_block_height: 382 - deposit_data: pubkey: "0xa290656399af969e0a3c03ab8529b6b0173e40c049101115120628fc09d549256f3a358f4cd858e02a9bd025a3e01dd7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa3cc5bb444b669055ebe709357821e7e18e273b2bef53252325b7dba386016c718cf01557b29f1bb465d3fbf13f7fe1a090b1d24145d090c89e8d6a4ad67b0f23b0bb60fa897bbd65b020c97450e34d7ae4ee61e0685727fab624af4d866ecc7" deposit_data_root: "0x1d58a6e4b2fe07612286e5452c9c0bcf810331fdcf21e40471e007178d7ec239" eth1_data: deposit_root: "0xf40cb049da0e82cda435267314359e780d03f4490204998272fa00a9bd6dc6b5" deposit_count: "382" block_hash: "0xe1768f362d8733dc9330f62b62842ae31dd708e9d58a0ef208fcb174527cddc5" block_height: 383 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" - "0x05b6bbc7f807ab0dcc2cc1033e4743bfa978b4068e735ef860846a4ef71e4ef3" - "0x1c38bcf92acf3077bcb07ca54de94f552d3128d9f5abc93eabaabef945993183" deposit_root: "0xf40cb049da0e82cda435267314359e780d03f4490204998272fa00a9bd6dc6b5" deposit_count: 382 execution_block_hash: "0xe1768f362d8733dc9330f62b62842ae31dd708e9d58a0ef208fcb174527cddc5" execution_block_height: 383 - deposit_data: pubkey: "0x8633815ef4ecf32dfd3e6221d877176ef1460f7147edae206349cc816431f1a2d60fc547e6dcf0bd31111fce6a822328" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x877082c5d8d68ce8a2547eb2fa81d42c67b1a0a0da9f62ca4f3ebb6a9f3f5853a627b3cff7e8700a801af5f81e9fd42f0f6dd0952a070a88b3c2ee73adf17e72cc8751ec6dc2f1a513bbe86e25eefd129d532e50ad77223116fb5912233bb858" deposit_data_root: "0xc11805cef7cb401d83cfcf73cee9526e60d319d708fb6d19761dfe576352f404" eth1_data: deposit_root: "0xb93ebaadc7951cd5056e2f900ee21ff1b94a0ef410be2345e9daa5798ee47321" deposit_count: "383" block_hash: "0x12fcdcd7f54e4f71eadbf4f1c91ab1b40ef47344411169c930298858a1bca8fa" block_height: 384 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xc9521569f6cd236e7893e6e538cfe9b294455c57d6738e0d5402dfb51e9edcfb" - "0x2e17dc08bed4ab4138ea54b4389d7956de63422e1f873bac51997acd6fc8a70a" - "0x7472f8762e7585ee829a64478023f69abff5f1a3c9c0b7eb37c5e0e530fd27cb" - "0x14503e81d68b81b6107b25a5cff097ac43e0ded9988b742805a287d02c1ac8ec" - "0x05b6bbc7f807ab0dcc2cc1033e4743bfa978b4068e735ef860846a4ef71e4ef3" - "0x1c38bcf92acf3077bcb07ca54de94f552d3128d9f5abc93eabaabef945993183" - "0xc11805cef7cb401d83cfcf73cee9526e60d319d708fb6d19761dfe576352f404" deposit_root: "0xb93ebaadc7951cd5056e2f900ee21ff1b94a0ef410be2345e9daa5798ee47321" deposit_count: 383 execution_block_hash: "0x12fcdcd7f54e4f71eadbf4f1c91ab1b40ef47344411169c930298858a1bca8fa" execution_block_height: 384 - deposit_data: pubkey: "0xad5539f19d8358478970caa4fb524b274867ca7449141a21fbd07e6b6291177200e9dca369b665e12ed40dea80b69cce" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x99788b2afa65fba3d50ac737cc372707a61a66423e03ca9a96b2bad066a3e939d61ea38ff6abcce5d89dacddde104e701318854c92d09513078171314dfd7f894e818db650e6385bf42748af1b6775d3c7f78f0e344ba1f2e7e01bd812da6c85" deposit_data_root: "0xd381809adc653a2cd994826ee024c272920803b10751c15699eeb345a8640448" eth1_data: deposit_root: "0xb7dd432c5408611d1368a238e7a462ba9294b34e29406a499ead95c513360199" deposit_count: "384" block_hash: "0xdee05ca3f55492ca6f2e09310db9339bfe0dc2e250f129950c5a430178c04398" block_height: 385 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" deposit_root: "0xb7dd432c5408611d1368a238e7a462ba9294b34e29406a499ead95c513360199" deposit_count: 384 execution_block_hash: "0xdee05ca3f55492ca6f2e09310db9339bfe0dc2e250f129950c5a430178c04398" execution_block_height: 385 - deposit_data: pubkey: "0x981a72fc476e4f532a10da80f235deb940e4cb6597c8e0f868171488f0eeb5fcc988048dd9ea3bef015aaec0cd79081a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x84dd84cfaf29083c34505098112ad7f439c066376256a5869e77cb6e702070d864684ac093e37eb26759aca78505bcf5189047ded56671cb09b0eb630ffce2d6407747fbed2530efeb0dd07beab083eaed840e3e8440319f97aad670cefc83fd" deposit_data_root: "0x298c5a5474ec0f8a9a1e151a9ee7fc14ea9597803b32884678851dab464385ba" eth1_data: deposit_root: "0xfc0287e35ac5abcb9e2eac1a295d56d943c303bbb69ed02009c816a1e95ea769" deposit_count: "385" block_hash: "0xe9257489f72b1836a2f5243c212386fe13e7f1302fde45c66355f7f053ef088d" block_height: 386 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x298c5a5474ec0f8a9a1e151a9ee7fc14ea9597803b32884678851dab464385ba" deposit_root: "0xfc0287e35ac5abcb9e2eac1a295d56d943c303bbb69ed02009c816a1e95ea769" deposit_count: 385 execution_block_hash: "0xe9257489f72b1836a2f5243c212386fe13e7f1302fde45c66355f7f053ef088d" execution_block_height: 386 - deposit_data: pubkey: "0x9282d6526651dc5e7caf69877a2209d4346bb231b3caed98fec1c95ce3eed284da0617c4d1722e7c316eecebf73601f4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8a07056d6cbc4955204e276e443ff9d0b7a22247a7481efd0329dd3f40f7935a8d1a7057ae628f58e4979550025eeb310ac822934b696c3f1988586a32b3b050f4bd34a74b522fbd8e94d6ac66b0127b95d3ff2e0a4d721c2564cead9c8714ab" deposit_data_root: "0xc39e707c0c1997a5199a59f529dac27feaa0591599dade101c6bc98e39c500d0" eth1_data: deposit_root: "0x531ee9c8985bee7183a5dc8fa5639fdf10c28f326426db8a657b0a5750cdbd51" deposit_count: "386" block_hash: "0x7f66e053d87f7f7b0687a29bcb1b42034b3a318d2918fb763a75a2f7e252cf4a" block_height: 387 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x6eb578b1e3f55c300c0071b7f22d0ee4d4a1b7a8415e8756521f9f68caca8852" deposit_root: "0x531ee9c8985bee7183a5dc8fa5639fdf10c28f326426db8a657b0a5750cdbd51" deposit_count: 386 execution_block_hash: "0x7f66e053d87f7f7b0687a29bcb1b42034b3a318d2918fb763a75a2f7e252cf4a" execution_block_height: 387 - deposit_data: pubkey: "0x836f2b3e00dfa069e4f315454cca69a56a36b6d32514ac81d168e34beabc42ea8a27918d60fe14a8c93ccf040faab02d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8d45bf64b1cdfabf3d9d5f86008ed55b03b2e8ca881d85c0131ebde4834c423a8da16e0abb9e963b7b7a3b5e8229dfbe04c89313f74b9e8f319a5f27d19af4c01605129e6bad45047308c4e5d024e47f69a1f84863a770927434625853032b70" deposit_data_root: "0xe21a86f0256ac65cb7260bbf774eafa1ca0467dacb31a1fbe35aeb795000470a" eth1_data: deposit_root: "0x897cea6ff0ca2f5472bbae1583e7d256c8fb1cb9729a415ed2d6fd497ecb83ec" deposit_count: "387" block_hash: "0x1a8b424e0faa53f76a7a87fb68d980aae685c81c9e79734f883c5a3116bfddcc" block_height: 388 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x6eb578b1e3f55c300c0071b7f22d0ee4d4a1b7a8415e8756521f9f68caca8852" - "0xe21a86f0256ac65cb7260bbf774eafa1ca0467dacb31a1fbe35aeb795000470a" deposit_root: "0x897cea6ff0ca2f5472bbae1583e7d256c8fb1cb9729a415ed2d6fd497ecb83ec" deposit_count: 387 execution_block_hash: "0x1a8b424e0faa53f76a7a87fb68d980aae685c81c9e79734f883c5a3116bfddcc" execution_block_height: 388 - deposit_data: pubkey: "0xb4d3e8864dc26809ed314a03e60c7fbe63ce8921dcb52affa19837e59639513782a1e526823f77fc9564d8fcc15bb0ba" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8768e4401b70479e0e321cf92cc78d75b597714854e2b28ebe847e50090e3a0c9dfa3e226f80b6b44e070bda975b11a10990f572268d88d9a0060051998c3151bf839bf91b05e417ce5d98978dfdaea0166cac0b3bccddbe52133c47cc5b3917" deposit_data_root: "0x67c70be65243658ef363ce8536fd2c09c653a3cd1be0cb7673f8a103ae07b7dd" eth1_data: deposit_root: "0x707a55c126befe50ff91b08a62770102096b0a4c87aca8ea8821733237f9b4fa" deposit_count: "388" block_hash: "0x016e4d950de17f13291f14596645de6ae51e40614ce2e39c02159e18a7c9414e" block_height: 389 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xafae78b562f726681144ff9aa2563edbda5e907e1eb32ee2babf8792cca6c552" deposit_root: "0x707a55c126befe50ff91b08a62770102096b0a4c87aca8ea8821733237f9b4fa" deposit_count: 388 execution_block_hash: "0x016e4d950de17f13291f14596645de6ae51e40614ce2e39c02159e18a7c9414e" execution_block_height: 389 - deposit_data: pubkey: "0xb35c3469a78ea17878cbb166377b8aaea461a0f7d58cc5f77862cb9a232c5a95452d523362808b661cd24a1e0baa67ab" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x93c7d303f1562b87c5f15c0d45026ba2f5ac22a3ccba6a96310a8962192e0577f6464223375100a8f053cb9fdc03f3e40a91ebe2014116b316a79bed10235831dad5c2886e0cee562b06f2098c70a652196cfa73585d4850f16853eac161d702" deposit_data_root: "0xa9dbd218ea842ca62f1647881f4fc2e3bf1dd7a67a4b99eef47d43d74c34ce59" eth1_data: deposit_root: "0xd9d9f4dadee20fe6a1213a8e4919fe470c34b5315061c12c3326281be071b803" deposit_count: "389" block_hash: "0x6ebdc4ce688958aa6c4d76d6ee80bed95457f73964cbfa10b2553a44158e1a94" block_height: 390 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xafae78b562f726681144ff9aa2563edbda5e907e1eb32ee2babf8792cca6c552" - "0xa9dbd218ea842ca62f1647881f4fc2e3bf1dd7a67a4b99eef47d43d74c34ce59" deposit_root: "0xd9d9f4dadee20fe6a1213a8e4919fe470c34b5315061c12c3326281be071b803" deposit_count: 389 execution_block_hash: "0x6ebdc4ce688958aa6c4d76d6ee80bed95457f73964cbfa10b2553a44158e1a94" execution_block_height: 390 - deposit_data: pubkey: "0x800044ce43a3eec0738b16300361bc744173822642fdf7184a7ac58f6b315478c03f8b57efc36b37c262e08b66260dbc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb0515fc2450c616acbe03511afc4c02b85e0e2ca0793135a3926fa0b55665f37a181379c67f0bfbca09743436891a3a012b8d06ddbadd8ae84a7526b52168b3c19c075917482b5e6347dd134c5a4304d3d4f69310c4a51f611b61756a732acde" deposit_data_root: "0x86f5cf1fcdedaef646198af6429d7bfd31f55700f6f9c39625d93b6de78b01bb" eth1_data: deposit_root: "0xa62e54acb14771006dd11ca8e80ccb43520f1921a58c955e555cef5e45750ee5" deposit_count: "390" block_hash: "0x1a7e29fe5e78f36f6249c8d0afb846a437d99ec96465d6c64a8bd1fdca8640c0" block_height: 391 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xafae78b562f726681144ff9aa2563edbda5e907e1eb32ee2babf8792cca6c552" - "0x879021b47e1a1c0942dad2c1b18300857aff607246ec88ae3ff1558391e07509" deposit_root: "0xa62e54acb14771006dd11ca8e80ccb43520f1921a58c955e555cef5e45750ee5" deposit_count: 390 execution_block_hash: "0x1a7e29fe5e78f36f6249c8d0afb846a437d99ec96465d6c64a8bd1fdca8640c0" execution_block_height: 391 - deposit_data: pubkey: "0xa3fe94ea52c28c985a901f8d895f8d2493dd1d939da8f775c7e595379431d557b83efce814b3f2d9b5a463c8ab5234d0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x84653812b348ba58c6eeddbd85870a0a3109da32bada6c5fb0ccb4f360c1d63866cc3548b03b066c0ff568f82b6bc4ee0e0b6665459569329878cb2a9cf5ee6169ff8b47ebefdc104e5cc3abb9caedd508bce5d02e6a5997b0f2c75f3b31781a" deposit_data_root: "0xf4f62e401aa56826818ca1a510a840ef08f374eb55e4c193fc58c64d15dfd9b6" eth1_data: deposit_root: "0xbb7338e44b9b1773d9a2537d33916a39047df59cf8a83b83ee15c4ebd7061f17" deposit_count: "391" block_hash: "0xc54fa15d7cf7e89fe249a3d43dc9aa194d89b7ed0709a9c453d63725a36b4bb0" block_height: 392 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xafae78b562f726681144ff9aa2563edbda5e907e1eb32ee2babf8792cca6c552" - "0x879021b47e1a1c0942dad2c1b18300857aff607246ec88ae3ff1558391e07509" - "0xf4f62e401aa56826818ca1a510a840ef08f374eb55e4c193fc58c64d15dfd9b6" deposit_root: "0xbb7338e44b9b1773d9a2537d33916a39047df59cf8a83b83ee15c4ebd7061f17" deposit_count: 391 execution_block_hash: "0xc54fa15d7cf7e89fe249a3d43dc9aa194d89b7ed0709a9c453d63725a36b4bb0" execution_block_height: 392 - deposit_data: pubkey: "0xb04bbe642a86b34459811d60affa8c72efaa288a34d4f2e5799807ced34747ef09ca47f90645d36c0a43fd9ce592e41f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x87b573600a6f5a6af8a6c8493ee98b9b179cf34aebd27ff4f063982a34464ea2faea6896f599dd885b0812f2829529e8066a5ef915c4b756ffe094a5c9e33c12ceb27daa3f272e2b8532bfda9724b799662a8c9030d4671f03224c391e283977" deposit_data_root: "0x08525bcafc67d143769778c202899f3bef45d03b0b4c47f40782dbd2d714ecf6" eth1_data: deposit_root: "0xa3b155eea9ce7c9e359bdfeaaa3226882a88b472ebc2f6dc20d63249f87fc31a" deposit_count: "392" block_hash: "0x54ddd2ee62cb4efc55efbf284b7c86b390754e6f0ebbb8a92c3546648444f7f6" block_height: 393 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" deposit_root: "0xa3b155eea9ce7c9e359bdfeaaa3226882a88b472ebc2f6dc20d63249f87fc31a" deposit_count: 392 execution_block_hash: "0x54ddd2ee62cb4efc55efbf284b7c86b390754e6f0ebbb8a92c3546648444f7f6" execution_block_height: 393 - deposit_data: pubkey: "0x80609da89da3d8a011674d17aacc7378a9ed907455c914c3adfe80d9d5ff1b903cf0195f7999cd27af91de5177af295d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa38c302d9ccd055c116a22a63757dc3cf5a4dbe498beaf638f0d90446ee263292b388036081585309c41b39c6d88622819cf63b6a5fcf985d5b6c01190b5d08627bf7d13dbf0ad9bd4b2489e1f4f1eb970c1e29c9f76406e49e04275b2bc65e2" deposit_data_root: "0x55cc13b5b52558f81535da2bf312b7430662936ea5e8f78f1042d174acfae930" eth1_data: deposit_root: "0xc4950b3e40fadc566118b3124e334889bd809244c4fbd2fb4e2e00dd940c6052" deposit_count: "393" block_hash: "0xc9e0def5a794986bc01573227a104a80465d774957b94c3fb5f66f6507226276" block_height: 394 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" - "0x55cc13b5b52558f81535da2bf312b7430662936ea5e8f78f1042d174acfae930" deposit_root: "0xc4950b3e40fadc566118b3124e334889bd809244c4fbd2fb4e2e00dd940c6052" deposit_count: 393 execution_block_hash: "0xc9e0def5a794986bc01573227a104a80465d774957b94c3fb5f66f6507226276" execution_block_height: 394 - deposit_data: pubkey: "0xb929600f99e80e834dd9220a02e8b395bdd8cdfd9f93f201e6cd89ae1950e0789f93862082f0c7efd45e4b69224bd92a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x98aba9f2310ac87434cb6e273c5bf0854789024046d4eecdd20edc20d59e9c9585e3be1a9197a928444de4ed37e582720dfc1fbf5a765c7cab9bbccf5d91b27413b681e853690ebea5aa8b757f69b9c2bcb704a9bbe9667573f1820ab1ebc524" deposit_data_root: "0xe6c9a1e53fa2bc6dfb3a0efcb15d5b61a0b00d40c05e85fdc7c73c22c0f1fb2c" eth1_data: deposit_root: "0xbb0d4f28737877ea198db2552a20e83fa21712d68f256fb4c47b00bc79a6e725" deposit_count: "394" block_hash: "0x07a4841aeadb48375c77cc7bbb85952ed2a2d8590b379cbc8296b93e5bea89fa" block_height: 395 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" - "0x0d997180aceeb9c78bfd8dff8c8f847e603e9ef4da82207e9ef96fa26dd60c18" deposit_root: "0xbb0d4f28737877ea198db2552a20e83fa21712d68f256fb4c47b00bc79a6e725" deposit_count: 394 execution_block_hash: "0x07a4841aeadb48375c77cc7bbb85952ed2a2d8590b379cbc8296b93e5bea89fa" execution_block_height: 395 - deposit_data: pubkey: "0x9052bae965368c78db0d638faf2ea9beb0e42b469adabbba09f85936f948a1cd77cf811a20ae759498770855068adae3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8fd3066f0eb12e45912dad9e0f03999efd048f5c3a7cd0ef0c1b28469d734e0900faa8208d9f3c2ea4475c4b0edef88f01a0b0c265ff4adda81d58422b1512db9e12fadc2ee56a87d17f98cb1d403321af314954be68de1ef1626645c9d0b58b" deposit_data_root: "0x8041edc01aaaba30de8f64e99b463e7884fe5d7927a8e1ac0f8c26e4eeefac63" eth1_data: deposit_root: "0x159cb3175d894680b3f9885f0bd4fdf130731ae6fbed0bb8ef6c8ae22d3c141b" deposit_count: "395" block_hash: "0x6f29a9e99967a5b3ae5da3eca55e429b68e12c0a3ccf3765743baef29c1509aa" block_height: 396 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" - "0x0d997180aceeb9c78bfd8dff8c8f847e603e9ef4da82207e9ef96fa26dd60c18" - "0x8041edc01aaaba30de8f64e99b463e7884fe5d7927a8e1ac0f8c26e4eeefac63" deposit_root: "0x159cb3175d894680b3f9885f0bd4fdf130731ae6fbed0bb8ef6c8ae22d3c141b" deposit_count: 395 execution_block_hash: "0x6f29a9e99967a5b3ae5da3eca55e429b68e12c0a3ccf3765743baef29c1509aa" execution_block_height: 396 - deposit_data: pubkey: "0xa7c693916f59a0ee41b13d045632d4c5e8703a0e1431b50ba0450834747e41a6634ab9c0c1efa6af140f2072c29cf7a6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2b6db61ed48e65d9b02339ec3dce5b65082ddb6e88f2a9d68bb008213c2f413e884df2e36a2df4ef4872a1d7918d8d60b4b0cecf20345016d9fb90f823950b40b56686cfd73a60f366e89c0664b512fa6b1fa7e03d10407e5391a01a793f180" deposit_data_root: "0x58e50fcd08de046408f42ef030f88327a7090e3f28d86b90c33226f625d8591d" eth1_data: deposit_root: "0x5659e739fa58f5bac4607770ad5735be507757cc931e78a32971dba1062f9f79" deposit_count: "396" block_hash: "0x98492c4ba8ab648f0b7347fd237f6c97e28f8c9276202b7ceeceb4e2b55a4caf" block_height: 397 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" - "0xf317c693e0d6b8255336757d18a3edf61408bfb581694def9ea146abfe6ee676" deposit_root: "0x5659e739fa58f5bac4607770ad5735be507757cc931e78a32971dba1062f9f79" deposit_count: 396 execution_block_hash: "0x98492c4ba8ab648f0b7347fd237f6c97e28f8c9276202b7ceeceb4e2b55a4caf" execution_block_height: 397 - deposit_data: pubkey: "0x83a40895d9005f007df9ed7fdb17d820d3d66fe419480cede7518e1f54e4c1e2a97ffd71fe2f01187c3707cde5bf9915" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96d6a5708588333bbad7bf98de64425be3f93c823588a7f30a2391d2fea7a68d4d46572edf9b5884a3669648b6233f970049e50e232746643e3e7edbdc733853ecff22492cb6d7befaf83f4f9331a9d8f1b4bcb7e28f2d1bdfd94903f7c121ba" deposit_data_root: "0x4b89dcec503cf535c9cb9f034604ad431a3baa5f8ad939a9fee0f17a518c58e7" eth1_data: deposit_root: "0xfe07bcc8cf3812b6959665a4d69ac7dc10210db6de6b5cb3cc3ab4e3731a553c" deposit_count: "397" block_hash: "0x9adc7e62cd440bc4c77546efdeb7d185348964c8b7d899634d8c442ae02f0cf3" block_height: 398 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" - "0xf317c693e0d6b8255336757d18a3edf61408bfb581694def9ea146abfe6ee676" - "0x4b89dcec503cf535c9cb9f034604ad431a3baa5f8ad939a9fee0f17a518c58e7" deposit_root: "0xfe07bcc8cf3812b6959665a4d69ac7dc10210db6de6b5cb3cc3ab4e3731a553c" deposit_count: 397 execution_block_hash: "0x9adc7e62cd440bc4c77546efdeb7d185348964c8b7d899634d8c442ae02f0cf3" execution_block_height: 398 - deposit_data: pubkey: "0x8ee8e926da165b8f34d249d194864a3994278aa4b829295480edac18395167fa016b2a4ffb0b0f3c89d18622bec2409c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96e64eb4225338a95db3620d53f114ce50c67c76f2775479d43b43dc99cc49203bf4cdb0a2f32ae8bc38871d5ea159f71573f7f17cff542489bcf03f71757e447cb1d3a88fbcb1849d406547f2ea18acdda8999dec66c611c66572435d27843b" deposit_data_root: "0x6f8c0bddde78f7897c2d2fa74c01ad7d54767bad64e1a110cecd9a13ffb11f31" eth1_data: deposit_root: "0xb10c6eb035b9b3ceaf4c5fabef893bc0e20d0fc473677948cab48835462cc8eb" deposit_count: "398" block_hash: "0x1aafe4f6b5beb8fefa9b9f17b11e8c330f1485d6b915bba56cd48ee2fd300ffa" block_height: 399 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" - "0xf317c693e0d6b8255336757d18a3edf61408bfb581694def9ea146abfe6ee676" - "0x2a66533bacc64203fa52d8f62fd219a28a45bcbb7c0e29db839a9d9b19a5f91a" deposit_root: "0xb10c6eb035b9b3ceaf4c5fabef893bc0e20d0fc473677948cab48835462cc8eb" deposit_count: 398 execution_block_hash: "0x1aafe4f6b5beb8fefa9b9f17b11e8c330f1485d6b915bba56cd48ee2fd300ffa" execution_block_height: 399 - deposit_data: pubkey: "0xadd60d6bf2abc6935ffebfe463c9b305ed2c898a00e2a84b997c014e140a7b254dfddc5be39e406ef0a893c4d67dd1ba" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x956032f3c008672890406790f1f6df66918c5b34b5c99bdd3e9e573b5c9eeb38457dad357d91bf63a5b40712f033196717c67639a675074a273d807ed38cfff57d5ae0a5da85425cc5e09a4fba69ef1ac8fde490e2acfcccf84593275ac13b6e" deposit_data_root: "0x9af6c4251177b012f498c5a6444e89a07f3b1f99c0c47c4370943fb4a19875a8" eth1_data: deposit_root: "0x2986d1af8658f87aab3fc101470d46c5875124b69e93da963cd7ed8a0815db27" deposit_count: "399" block_hash: "0x3f9fb82bf76f4d04409151836ea7e82696193cab3ba0a6505f8fea426708f118" block_height: 400 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x7e5837337e12008bc00095f95c4579a110096a154443242630b70a200c8eb25d" - "0xf317c693e0d6b8255336757d18a3edf61408bfb581694def9ea146abfe6ee676" - "0x2a66533bacc64203fa52d8f62fd219a28a45bcbb7c0e29db839a9d9b19a5f91a" - "0x9af6c4251177b012f498c5a6444e89a07f3b1f99c0c47c4370943fb4a19875a8" deposit_root: "0x2986d1af8658f87aab3fc101470d46c5875124b69e93da963cd7ed8a0815db27" deposit_count: 399 execution_block_hash: "0x3f9fb82bf76f4d04409151836ea7e82696193cab3ba0a6505f8fea426708f118" execution_block_height: 400 - deposit_data: pubkey: "0x8f48795cda6795e9af514489989a9f9e8b6db2b52a36881e4ba166327153d6db922e5148db044b27efe1831b54e16270" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89b774642bd7faeefc6435c7184df11dd2fb34464f7ece0430b69d220032f77eccf6187839c5d7e233d463b48640bba211cd063cc9b638a954ea2c782919656980c7491ca632a83538146d9e6156ddf6f7260fb5ad1b4756549ba7a1b1f2cc1b" deposit_data_root: "0x70721ee8848f77b3243c3ea7b1193970abadc48446a2f47116cc9371f55745e7" eth1_data: deposit_root: "0x452498ecbea92a19db703d3e4544acfa45d9890b43883f5f88081533a826f236" deposit_count: "400" block_hash: "0x604f66f12e19e8be5538632835dc419e722d35e3e15b6bc7ba305348680a4ec9" block_height: 401 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" deposit_root: "0x452498ecbea92a19db703d3e4544acfa45d9890b43883f5f88081533a826f236" deposit_count: 400 execution_block_hash: "0x604f66f12e19e8be5538632835dc419e722d35e3e15b6bc7ba305348680a4ec9" execution_block_height: 401 - deposit_data: pubkey: "0xb43ccddb32f15baaa32d69abf4b298d38e835607fd74aac5b25b5b161e8c865744a06526594faf39521e51fe44d66658" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb35daff1750c7ab2ff3ec29d401f83dfcc035bd5e0de5e45bc7ef789558349839da1c3588a263359ba86b4812b6c28360c960dd5aa762c7ef6123dc3e2ce63064f9ef2ed74eb9efbdbda96d87cfc2b50f4947e66ecd0244c546b9450277e6861" deposit_data_root: "0x0f94bc880af7f796e05590236751522502362f586d3bcf4d42799a6931676193" eth1_data: deposit_root: "0x9c53aafb0bf05b211e3d12a2771506145ca19774733164e549865501fb0f26a9" deposit_count: "401" block_hash: "0x897487f0b6c2ee25dee391c9b855ac06fcbbcf4f8ced76cceda3081c27d461bc" block_height: 402 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0f94bc880af7f796e05590236751522502362f586d3bcf4d42799a6931676193" deposit_root: "0x9c53aafb0bf05b211e3d12a2771506145ca19774733164e549865501fb0f26a9" deposit_count: 401 execution_block_hash: "0x897487f0b6c2ee25dee391c9b855ac06fcbbcf4f8ced76cceda3081c27d461bc" execution_block_height: 402 - deposit_data: pubkey: "0x83249b11efc76fba2ab77df9b5ffc607e6e2265c7f761dbb3099f3b4ff74ad8b9570036cb04942898f8c33b8442adfcc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa7e93b3bc24dddcd889bcb9d313f632eeeea863ac36f6bf45cdf2aa3817eea3d58f8e133f3d7c52318370ca3d51458e3195aaf7dfb8affbf789e294893b93e1420a5417e2bfd42ef06d3a0a93d35e6ae4a89aa4a3887c53fecc5a5784951a7b8" deposit_data_root: "0xe1f17fc61185cdbeb20440550c2bbee0b02afd1bbcdda44938f893fe92e6d2ed" eth1_data: deposit_root: "0x636af0f0424726b4060828f72a3186c6b7dfaaea3591c5e7691d3a62fe183a7f" deposit_count: "402" block_hash: "0x6cae019fcf9937f0efea9dc1ab3a9550aaf34af27f8e63b644f9329e61176a02" block_height: 403 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0xd120ef8988987a3de5b82d1b73dbf94fd20b9ab5bf7b3297255bc0ea59ffcd70" deposit_root: "0x636af0f0424726b4060828f72a3186c6b7dfaaea3591c5e7691d3a62fe183a7f" deposit_count: 402 execution_block_hash: "0x6cae019fcf9937f0efea9dc1ab3a9550aaf34af27f8e63b644f9329e61176a02" execution_block_height: 403 - deposit_data: pubkey: "0xb049dc45fd585ef8bc67831dc47690f95e466cf11127def6ef9fdfc43017518752aff3df93c3e5f68083f590f554f3dc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9411afc1b608ca75c7e4af02d1688588ca24b611b9b7250ee87dc7504f1c60543932bf50745b64c363537ce553234a62195d605f970744979913756525764b61e274665c5811d56b13928fb1bee16a35269bc2a466726ddbff0ebde348680e50" deposit_data_root: "0x11af26393dac3ce8fb05c12d6ece2cfceec9489fd2d915646bb4840993138571" eth1_data: deposit_root: "0x9c778cae240d62b556752b616662c7ac895a162e9a7730ff0d52b82bf469883c" deposit_count: "403" block_hash: "0x40daf225c72e6c2923e9ad5544c472bed26439a283682bb93688fe3d88d2e76d" block_height: 404 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0xd120ef8988987a3de5b82d1b73dbf94fd20b9ab5bf7b3297255bc0ea59ffcd70" - "0x11af26393dac3ce8fb05c12d6ece2cfceec9489fd2d915646bb4840993138571" deposit_root: "0x9c778cae240d62b556752b616662c7ac895a162e9a7730ff0d52b82bf469883c" deposit_count: 403 execution_block_hash: "0x40daf225c72e6c2923e9ad5544c472bed26439a283682bb93688fe3d88d2e76d" execution_block_height: 404 - deposit_data: pubkey: "0xb0f4dcd488f6725946e1a384d9ae9cd6a12824dafb426e15f4b848b6dabd46ec1177fccd0fa5c0c2260fc57aaadf1e7d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x91ca8e45fc3d7c4003d0ec4602231b3f86e119931a1c8d605b86d36191a2d32193bd10741920bff28e2d2d2964f01b9c034ddaf18f30d326b6f91be845c9c75ef0201cd50ff50f39c29430b7492a1e4537926c786525091e1c2c238ad4698b49" deposit_data_root: "0x686a7b22bebf76249ffc853c5122014578f3cb65dd2c6b70909ffce37e88150d" eth1_data: deposit_root: "0x2a08f81dd020438f364a87bf7dab7624c404e0934662a5588c924c5fa10abab1" deposit_count: "404" block_hash: "0xd4e4fc76c0e27a2f700ade91f2510b65de7045289c1c22f964ea29e2a7dca632" block_height: 405 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x84a7921ef234cafc908a09e2bbbdd215ec6e0c4aa800834f18fd8592b86fb2cc" deposit_root: "0x2a08f81dd020438f364a87bf7dab7624c404e0934662a5588c924c5fa10abab1" deposit_count: 404 execution_block_hash: "0xd4e4fc76c0e27a2f700ade91f2510b65de7045289c1c22f964ea29e2a7dca632" execution_block_height: 405 - deposit_data: pubkey: "0xb400b2f5705dbd2905c5d9fe3b2f29cedb380954a60b4fab0e55009c47e1908a30bf286f7e01b7125985c9007015f37c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb8303c6fe8a1f35b218d48f838cd459dee1422b6f202c1b710c0179817f1085c8556cb71e6b0a97ad0484349fe854f6b0d4da3f69c0e3d5708843d4c0ad4d3f2bdc1cdb40db8a654a1f708b4318274ea613e75be4d0f6c9a26a1d52d950c1f5a" deposit_data_root: "0x54285447a3b3f65166091d937d7557f012b904d001e24cc43c8f0899522bab1a" eth1_data: deposit_root: "0x2964d0b869c2a6da631d3e589eca0125be3775f099f3cd1e6b7013ae66384abd" deposit_count: "405" block_hash: "0x227229f14dc54a592bdd03b2d84df40d64d0e6f51dcdfdf1c42ff87a1291c6a3" block_height: 406 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x84a7921ef234cafc908a09e2bbbdd215ec6e0c4aa800834f18fd8592b86fb2cc" - "0x54285447a3b3f65166091d937d7557f012b904d001e24cc43c8f0899522bab1a" deposit_root: "0x2964d0b869c2a6da631d3e589eca0125be3775f099f3cd1e6b7013ae66384abd" deposit_count: 405 execution_block_hash: "0x227229f14dc54a592bdd03b2d84df40d64d0e6f51dcdfdf1c42ff87a1291c6a3" execution_block_height: 406 - deposit_data: pubkey: "0x97580566e3ddcde5b3e0cedf688aede17a8b738a21f96a0c2efff77061e232ad877e6bc71649d0fbb3ec0dde584bb8e8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb680f12cff8dff209469f418f731a144cade0471dff2ee7b656baa3d0b2ada286bafcf1487ec3ec47b1fa83823fc237211352f5d3c28842d50124206019b16a9f7baf7c22405fbfcb49123aec9289fe8a2a6d894634a936297f0bd08d591074c" deposit_data_root: "0x5db3228f5c2c952907c045dbb394ae8e84db47a0e25ffa40de6b58e9c6ab257c" eth1_data: deposit_root: "0x056d0f3598f7c612c9d73dd3adcb0dc54a8861b4c3df6b4df8ff7511a3966207" deposit_count: "406" block_hash: "0x5b1c9467bdfcf4b7555e748b80e684419a23798fa52716ac92aaa14186dd85b2" block_height: 407 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x84a7921ef234cafc908a09e2bbbdd215ec6e0c4aa800834f18fd8592b86fb2cc" - "0x85117723172be560339b88739cf982d8b35cb46f757778b547dbc224ef314c78" deposit_root: "0x056d0f3598f7c612c9d73dd3adcb0dc54a8861b4c3df6b4df8ff7511a3966207" deposit_count: 406 execution_block_hash: "0x5b1c9467bdfcf4b7555e748b80e684419a23798fa52716ac92aaa14186dd85b2" execution_block_height: 407 - deposit_data: pubkey: "0x9504350e6a3ad1a5f711d9e5904bd25b1f6571bcaa66403f1da9fc8200ebd8073308dcf462371073bd8b076fd25df949" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x97cf502d6ce9a1a4dadfa044a55404625dce825856a24d235e58e31726d6c656c6848a4f614289ffdf2ce52b065780a60f2ed591833b178369bf7b84e6d7f0a5bba85e79c5a37f7d7087b54f12f78dc94fedb49668d62cf052d3d36ba14cfc6a" deposit_data_root: "0x1a6a9e33d429de9d71c1f84e4476edfea7c21cabaaff5663bf0737e75d503644" eth1_data: deposit_root: "0x45ce45d9a35f5bacc28372385bd446592e1198cd983a9cabf423ae68844aca63" deposit_count: "407" block_hash: "0xe25780387a9c484c23c6252bd8518d02fca68bbef3de900bb192b8bda868017f" block_height: 408 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x84a7921ef234cafc908a09e2bbbdd215ec6e0c4aa800834f18fd8592b86fb2cc" - "0x85117723172be560339b88739cf982d8b35cb46f757778b547dbc224ef314c78" - "0x1a6a9e33d429de9d71c1f84e4476edfea7c21cabaaff5663bf0737e75d503644" deposit_root: "0x45ce45d9a35f5bacc28372385bd446592e1198cd983a9cabf423ae68844aca63" deposit_count: 407 execution_block_hash: "0xe25780387a9c484c23c6252bd8518d02fca68bbef3de900bb192b8bda868017f" execution_block_height: 408 - deposit_data: pubkey: "0x94184bf24da31a8ca6561c17aa36b6933f07d4966063972bfcc6c97d8daeefd05b7c22d41fa5133327cc0dd000139175" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2147f430cef90e44d212f911fb86e018b4757593fc5830f5df7c227d66c3f9498ea97f5d74fad123e7a1485589d17d90297d6203e5a815a8e154d548daa55b9f13901bc297b8fd4e6ccb909dbc8fd2f93a889d64186fc2f9a4be67496d97b61" deposit_data_root: "0x687e4fa71fd82af6ccca467fb6b5e48f142ad7fc09fd986e2d2c12bc08e2e318" eth1_data: deposit_root: "0x85996ca4642a553cc8fcf6d1c797c38df7fa374a2a8a420064114c4b7b576779" deposit_count: "408" block_hash: "0xa1d4a35fa123ddccc268e408c9c03c5351b323e42eeae7b8415b67725957f8dd" block_height: 409 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" deposit_root: "0x85996ca4642a553cc8fcf6d1c797c38df7fa374a2a8a420064114c4b7b576779" deposit_count: 408 execution_block_hash: "0xa1d4a35fa123ddccc268e408c9c03c5351b323e42eeae7b8415b67725957f8dd" execution_block_height: 409 - deposit_data: pubkey: "0xb88add150c36e8c338f7ff8efa8efb4e302a5a01afb8e331282eb075ffc3f2f5e5e783a4cef6a0d9c65dbedea48cc093" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xadc8bcc68efed61ce4039fba63c806c6e59282810427369f0967c765e052048304bcb76104660d30ca2667f406c445160240514f7b07c762a83e1f7a27e5cb7b4fc81b40b5a4f8d24fb3cb1640129132578819e404da56557e5f6988e8064708" deposit_data_root: "0x99422ecd07eaabd6d3d3380ff689d77656e191b82317f01a8ca95cbc98210d4c" eth1_data: deposit_root: "0x8d152a557390c7b500d1a4eda65c8491268e58d25a936cb8e032eb06be13de35" deposit_count: "409" block_hash: "0x864f7b84cd151b4359c1767fd03f15e94769a4a96b65a3e299b7984d6cd397e6" block_height: 410 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" - "0x99422ecd07eaabd6d3d3380ff689d77656e191b82317f01a8ca95cbc98210d4c" deposit_root: "0x8d152a557390c7b500d1a4eda65c8491268e58d25a936cb8e032eb06be13de35" deposit_count: 409 execution_block_hash: "0x864f7b84cd151b4359c1767fd03f15e94769a4a96b65a3e299b7984d6cd397e6" execution_block_height: 410 - deposit_data: pubkey: "0xb25827b6746a0ed3bf133beb7e465ba08c39e1960c4555a81384502d6c244bdd7ca19f521c6d192436d71dfafa64b4a6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96aa871044bff32644f18d02e67e8dc0755621ed06eed2928626f653aa927e8976f39447954e3e0737533488633a319f16e573f70137eb877bc792b12df25b72847efa7c334309070109492bdd07b6f12641ef30895d71503755f6bd186a373d" deposit_data_root: "0xbe183759a8073454fc423aba202855bb3537be2a6772f75617206143e492583c" eth1_data: deposit_root: "0x3e6105f13f3575420640b86bf5967844ef363dbd91cd6d2f3d7b55bb2cafa1cb" deposit_count: "410" block_hash: "0xf59f3ccc775a6fd25443c8bd4d39aee5653b9399d8db7028a1244b2b36fa601a" block_height: 411 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" - "0x8938612c24e370ad407b03900d58216a3677570a6393d86c1199e168ac50d0f4" deposit_root: "0x3e6105f13f3575420640b86bf5967844ef363dbd91cd6d2f3d7b55bb2cafa1cb" deposit_count: 410 execution_block_hash: "0xf59f3ccc775a6fd25443c8bd4d39aee5653b9399d8db7028a1244b2b36fa601a" execution_block_height: 411 - deposit_data: pubkey: "0xb5ed6e77bd6f1661a5ab3f2e13743385c7ee99dc240e9575b3e7639b4f73a017cf4edbd0932e02577acd2bec274be3fc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9304d4d21d94213e2e17afba7d41167249086d34837591a7ebaa998ad31dc2085f1f11cfc01b9a0651dc5bbc4785a9f6084549527e1d9f4a256d9d6b73a1cebcbd10c9e88984acc11ca85eb8d5ff5b53cecb6bc4a366bb5cc3a82db259accf9d" deposit_data_root: "0x56410aabb7658f5072e9d3caaafc6d06931ecd574f6af0b0c6780765b81b2efe" eth1_data: deposit_root: "0xf81fa25a4547d3ea55b14e7ac66c2e4d9f96c32c843d3ccf32efc7e625142204" deposit_count: "411" block_hash: "0x2ed4ba87f94e8bf64d8fa37d0b7cb7a67eeddfd408a8838ee62cdf8b63e36533" block_height: 412 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" - "0x8938612c24e370ad407b03900d58216a3677570a6393d86c1199e168ac50d0f4" - "0x56410aabb7658f5072e9d3caaafc6d06931ecd574f6af0b0c6780765b81b2efe" deposit_root: "0xf81fa25a4547d3ea55b14e7ac66c2e4d9f96c32c843d3ccf32efc7e625142204" deposit_count: 411 execution_block_hash: "0x2ed4ba87f94e8bf64d8fa37d0b7cb7a67eeddfd408a8838ee62cdf8b63e36533" execution_block_height: 412 - deposit_data: pubkey: "0xa25579ff3efe83b344ac7ca26d45d5aac4fd4fdb1809f20e4e48026e154e95d7ea8c7abf6e91628f8448a6a798dd07f3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8915d4d355035a608f37b9c2402a9c3b95ef8c68209b0607cc8bcdc4f10a47a12b0708da53442b82348470e179f128bb02192b872b8ea16d388ed77ac173e4b9ae9456734fc33cc05b6bce98dbcb8f69bfae7583286ed548b4711916eb059055" deposit_data_root: "0xb55d26ad397fe717b187f5c40e5103bee6c3ba6d8a2b0d73a357f950fd172c34" eth1_data: deposit_root: "0x1d2b4ebde6a17b6badc11d3f4a4d67e5938f2b536fed42e015b6ae501b88bbe9" deposit_count: "412" block_hash: "0x616b1268dbde68f7f9ba43b43cbd7f721c94d1ae793f0101334af4ad8d8e82ec" block_height: 413 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" - "0xa1c5ec665c8d856db67a8496e9dc6082278b339bf70b3a4f35f6d79670fa00e7" deposit_root: "0x1d2b4ebde6a17b6badc11d3f4a4d67e5938f2b536fed42e015b6ae501b88bbe9" deposit_count: 412 execution_block_hash: "0x616b1268dbde68f7f9ba43b43cbd7f721c94d1ae793f0101334af4ad8d8e82ec" execution_block_height: 413 - deposit_data: pubkey: "0x81dc3529a283023f70fec5eb65ef8e3b394b0239bfe40095574a881c5dbe536a6b119e6cc95668b62d6e5944386c07ca" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89053f18cbf904592529a1710bd771229ebf0709d2c637684eae158bdd5821469dcbe1263d3649a8e04b92d2d7e326ba1895598c591a69fd1048f58d2d34c1cc432dab87f8f0bed2afee9500f92ea000462b9ffb80f5ca409e0d05ab8b821aca" deposit_data_root: "0x315194fcfff6c0dc8855f81729f8993f67b38330dbec183119694e330fec78af" eth1_data: deposit_root: "0x3801e05532040093e13e5b25b9afb7ebc97618181c41afec4e929e7cf8458a24" deposit_count: "413" block_hash: "0xc49c428e319c98556fa261f9a6a3184d5149ea8cb773b47fef238c2f8d696641" block_height: 414 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" - "0xa1c5ec665c8d856db67a8496e9dc6082278b339bf70b3a4f35f6d79670fa00e7" - "0x315194fcfff6c0dc8855f81729f8993f67b38330dbec183119694e330fec78af" deposit_root: "0x3801e05532040093e13e5b25b9afb7ebc97618181c41afec4e929e7cf8458a24" deposit_count: 413 execution_block_hash: "0xc49c428e319c98556fa261f9a6a3184d5149ea8cb773b47fef238c2f8d696641" execution_block_height: 414 - deposit_data: pubkey: "0x93da5217b698dcee39d36c25bd79f2a152e5053add9e4b17cf60cc5dadc0e2d1713d05f7b5917840b6748d25d68f4878" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaeebc4af4e5b90582f890827b760f39de6f9adf57afe53e74fa7dc7718e1a1ff4f70eb119c2f1042ee9d06264c07347b0d052699ba9145d7c3e38ffbc2d23d75f15c169b88e35810317e80281889f5a86248d05110ac7ce727996de71967cb29" deposit_data_root: "0x38ae0e785551cf674706d6ec349cb2a8061d5a6175b87857f9c9a9f51631cd71" eth1_data: deposit_root: "0x64149d892f598e8b77cb82d9ec6795bb77780c16ec7519ba12d9a3dce230179c" deposit_count: "414" block_hash: "0xa79d343f7dca460ec92a84fe1186ecbee2f9bef1270a4cf1999cf944a86f85ae" block_height: 415 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" - "0xa1c5ec665c8d856db67a8496e9dc6082278b339bf70b3a4f35f6d79670fa00e7" - "0x48e639af938e1404ea96c354be4721b397a5acce7ffa49d37f8573ee8158a522" deposit_root: "0x64149d892f598e8b77cb82d9ec6795bb77780c16ec7519ba12d9a3dce230179c" deposit_count: 414 execution_block_hash: "0xa79d343f7dca460ec92a84fe1186ecbee2f9bef1270a4cf1999cf944a86f85ae" execution_block_height: 415 - deposit_data: pubkey: "0xb54437d1547e9a87476f03c094c86465f36376c09ef3c8fba0c8906fdeb0421d523a20ab6ce6ee18da9fbab39ede3bee" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9334c266b645d6cc2dc62f8dd0e6ec5224dacee0db27c912db0b41422bcbc20f85589fb41bfd51d22ee7030c75b52c6c0a54185c8385f95a36e97d241f32f0b903caaaea7e2cf27ec93870c1264f2ed07d73e84fac7402f03ebf77b9b5464321" deposit_data_root: "0xaf029eb95db881e01d26610b29fb72f3e787f515905568178e89caadffceafe5" eth1_data: deposit_root: "0x3f34a92f21f233bbf81b0c43288483f2e79ce0d95351eecc830a97b3dcec3eac" deposit_count: "415" block_hash: "0x455ef1eda7e29f3ed4bbb1c6d34330abd172c4626032644f0242b4d4defa1835" block_height: 416 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xec52edc11cb65e2c16d2dfd0ab3223c608e768e70c9e808e0a0196c82ad1736f" - "0x0901c3b3e1bacfae214532d21ac897c470123fae6d333b9af964c91ea57d286b" - "0xa1c5ec665c8d856db67a8496e9dc6082278b339bf70b3a4f35f6d79670fa00e7" - "0x48e639af938e1404ea96c354be4721b397a5acce7ffa49d37f8573ee8158a522" - "0xaf029eb95db881e01d26610b29fb72f3e787f515905568178e89caadffceafe5" deposit_root: "0x3f34a92f21f233bbf81b0c43288483f2e79ce0d95351eecc830a97b3dcec3eac" deposit_count: 415 execution_block_hash: "0x455ef1eda7e29f3ed4bbb1c6d34330abd172c4626032644f0242b4d4defa1835" execution_block_height: 416 - deposit_data: pubkey: "0xaa5367fff8db3ba5017bc601e9f9ceb867d54c3b17ade967b0bc905f644f6aadc8aa53d3e9ed0e278bf3fc2b0b56a7b2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b8a5f542223fdd7170978a36e904c31ec430dd68cd608a3aaac5b6514f1e817e1bb2374aa7359e85d0c280f17c99daa0049c57e853088b8ae3a23d77911c12d6094558aec8dff5a9dc917d7799e6a86d06bb54b394473fd4fdcd273868581f3" deposit_data_root: "0xd202196054c6e1cfa6f16d82399ef65d80f0765564b15c5111da4720bec9b495" eth1_data: deposit_root: "0x2bbfa716fadba6b4b1d4d2b4cbd5b031bad662ad0a18d60f8fae3a9ff2238c8f" deposit_count: "416" block_hash: "0x376a52185e4457c7d3536a168e21870ecbb58babc27d4a74189316e089e4a69c" block_height: 417 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" deposit_root: "0x2bbfa716fadba6b4b1d4d2b4cbd5b031bad662ad0a18d60f8fae3a9ff2238c8f" deposit_count: 416 execution_block_hash: "0x376a52185e4457c7d3536a168e21870ecbb58babc27d4a74189316e089e4a69c" execution_block_height: 417 - deposit_data: pubkey: "0x874305f7d11e69b74164cad10ab88ea7df22208c954fcb6872f34a5f9c8292341f85a6250716270563a19b5a112761d4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xae8bde36d9ebdb5a259f005703d09b72d1828bb4b4dffbab5e145f1bc0cc857b24ba1365ead8ce0953aa67e3afa4c9a40fc79fc0da93c7a5b350e0c528f91fe7a1b124c27d0d622711be2a85abe3078010c584576b919e438721dcfe7a5f6d1c" deposit_data_root: "0x0e431cf7531088ea8e7aa4b2ad1e3a2971548ab2fc6967219a91861599293180" eth1_data: deposit_root: "0x0cc28d5ecfca85f1d141d409373c12e5ef93e7fab9d3d667737b8e3e8b9d567d" deposit_count: "417" block_hash: "0xcc9737753a8b74792a5df80adaa5eeeb97c6d8656eaee16fcfb04a63bddd791a" block_height: 418 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x0e431cf7531088ea8e7aa4b2ad1e3a2971548ab2fc6967219a91861599293180" deposit_root: "0x0cc28d5ecfca85f1d141d409373c12e5ef93e7fab9d3d667737b8e3e8b9d567d" deposit_count: 417 execution_block_hash: "0xcc9737753a8b74792a5df80adaa5eeeb97c6d8656eaee16fcfb04a63bddd791a" execution_block_height: 418 - deposit_data: pubkey: "0x96917c5ff8bd2debf697fbc64455d19cf1efc4e1327b3dde2eef7db7cab762effb43025c4162db0008a0b43b4d060748" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa16d8a141171087108c9f042e0915736a0eb801ccaf8b889a124bd6d53eaffef6518a982b0214e9b6c9a95860d5a2da50f5b3eef099489a927545bbbba3d9e0126f7720c367e93bbb64353d8b7b86363792c35e1d812fedc3495921910051be7" deposit_data_root: "0x3dab6d15efd096307e6d2f0f3465f10a35147b60564a52e9a69c2a9d20c16a2d" eth1_data: deposit_root: "0xcb8c6981b53a98be40422412d265fd54abc7329f49ba6028981465210544c9c0" deposit_count: "418" block_hash: "0x3fb793716ced3b8a456415e801d6e847ee18b269ae9600bb2b42d698d23c6d17" block_height: 419 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x696db144fa18876c4f737f199bf14a3d8922bd7a5c7469f783cd255b766ac02b" deposit_root: "0xcb8c6981b53a98be40422412d265fd54abc7329f49ba6028981465210544c9c0" deposit_count: 418 execution_block_hash: "0x3fb793716ced3b8a456415e801d6e847ee18b269ae9600bb2b42d698d23c6d17" execution_block_height: 419 - deposit_data: pubkey: "0xae77044f5f689ef3c59fbb1afc7fa2e33c5406121f9c2eb1dd089cb320b9d82ab51d6fadb545327dfcc2688c201e9e07" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2229d26b8942b36b25e0231246148d635c4abf51fbab950efea2e4f0e4a9b7f6f9ee366636bc42801930330fd7b197a11cac3cec7abfccfa29323a2810f2d209ba953a45bf11058bf438d66cec626c4c6be647cc6c0c88fe372e333863d5766" deposit_data_root: "0xb1532d97dbb8c85040e1ebc08649670b8980fd97cae2e23ab7f1b5af06c1f597" eth1_data: deposit_root: "0x76d0915685d7293f2ad3c227cfd6208d198fc11d6eb154dca9ebf9f08b57a863" deposit_count: "419" block_hash: "0x08a0fbfdd1c3183824d6f51a123e89b1a8dd1c208dea3a167bb8c47ff7697390" block_height: 420 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x696db144fa18876c4f737f199bf14a3d8922bd7a5c7469f783cd255b766ac02b" - "0xb1532d97dbb8c85040e1ebc08649670b8980fd97cae2e23ab7f1b5af06c1f597" deposit_root: "0x76d0915685d7293f2ad3c227cfd6208d198fc11d6eb154dca9ebf9f08b57a863" deposit_count: 419 execution_block_hash: "0x08a0fbfdd1c3183824d6f51a123e89b1a8dd1c208dea3a167bb8c47ff7697390" execution_block_height: 420 - deposit_data: pubkey: "0xa174a13601df492b77a263ff54d9e30a0d9b248a1bfc559a4bbeb251fead9b72790f08bed89dbf224c1cb5548c44abab" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8a8d011198c4e426421f2563dbf5552ba950849f6b404a77de5f397f470ad349fc35c62df521f34d4ce8e5135f514df11654c7868da1b45d6d10193597cb0e1c33b8bff2f005c2eba783f1e7f5526cc85be30fda5d481ecc526b5a0a5733815d" deposit_data_root: "0xb5100ee2bc58e4bcbeb35010d28c99f25f30db2dee32e8d8be5abfff81c6b980" eth1_data: deposit_root: "0x4fbb0a4745d73910a0e83ed47c036e561d5a974ba373106f4be04ee184f68009" deposit_count: "420" block_hash: "0x8644b9495ba9e4ea664a3d613b9aceb7e8a7efb507635cf2eea237ccfb3eeb5c" block_height: 421 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xfb785265dae57039dc1b110d2edb8556f05c9f2013e0cd5b57982be1642c2375" deposit_root: "0x4fbb0a4745d73910a0e83ed47c036e561d5a974ba373106f4be04ee184f68009" deposit_count: 420 execution_block_hash: "0x8644b9495ba9e4ea664a3d613b9aceb7e8a7efb507635cf2eea237ccfb3eeb5c" execution_block_height: 421 - deposit_data: pubkey: "0x88a09d6756a015068efa04c8fca73dd96e2314e4f6e9d1aefdf19ef139eccb2000c3f382a18a3ade202641ed2c4b4267" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8bae90cb3fad0db9242b14e40a799f7ad163ca2a720864f4abdb6e28a352d19655d557420a4f4965108d247c82d3cf050224c04aecf9a351e57cfc008e27b60c991b02446d19ef1f3bb6f6bc932010d9bf6c54b4b09afd8131fd2d95fac89c11" deposit_data_root: "0x87c39cef2326f57395a3143b07c46e7077d23cab48b40a25631ba38381e3f15a" eth1_data: deposit_root: "0x1bf71fb13806bd931b817a8be4dc90de192c8f2baafc12d99eb8ed922bcf53a3" deposit_count: "421" block_hash: "0xad379a83ea80b1aae55e118cdadfb133bbcedb14842e6a1a1fe4cdae049d0739" block_height: 422 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xfb785265dae57039dc1b110d2edb8556f05c9f2013e0cd5b57982be1642c2375" - "0x87c39cef2326f57395a3143b07c46e7077d23cab48b40a25631ba38381e3f15a" deposit_root: "0x1bf71fb13806bd931b817a8be4dc90de192c8f2baafc12d99eb8ed922bcf53a3" deposit_count: 421 execution_block_hash: "0xad379a83ea80b1aae55e118cdadfb133bbcedb14842e6a1a1fe4cdae049d0739" execution_block_height: 422 - deposit_data: pubkey: "0xb41b17006e2a6a6bce8055ee459557cf835fccaa851885903846dc190adc223f6cad199446ca225b6a65d40382344227" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8c1ba3a40657d6fc08753d00115125acec2821bfcdb6e272758086cf5eb38f6653924da5b296a24ec4099958edb6c42d1539bafe103f62c926d09f03424abb0cf189985dfbf042fee90cdc4efb1204eb251825a9b5771862686271c0744ea62f" deposit_data_root: "0xdcfe0566760412e34ef921467df75a7ab63ba33709d01ec51509c229ea7f1f8b" eth1_data: deposit_root: "0x7ea9a20183569c27fa282cf8f41035a826ad1a4055bc201b03bfffd70a4ebf7d" deposit_count: "422" block_hash: "0x623deab0585c9ba3256328022621d3ea83974a0e95bd98cb4974fab7ff84c458" block_height: 423 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xfb785265dae57039dc1b110d2edb8556f05c9f2013e0cd5b57982be1642c2375" - "0xaab1605a8179a12b1e4e07684af74b5398445a216df5219be25801f44d75d56e" deposit_root: "0x7ea9a20183569c27fa282cf8f41035a826ad1a4055bc201b03bfffd70a4ebf7d" deposit_count: 422 execution_block_hash: "0x623deab0585c9ba3256328022621d3ea83974a0e95bd98cb4974fab7ff84c458" execution_block_height: 423 - deposit_data: pubkey: "0xaf9a969a70272ac2871fd689f13c0b478e27bdc5127f02c41efabd5814a902dc1e3ed8b3ca1786aafb8f112aa3c87db7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4b4f5e4b3bab060290c43259af77f83aab46b0d5b47cf7ec63e252bc1a1cbf4473bc03b6e0d70cd822d80b93a5d686109087af68ec598e991234c5692ca91844404d7be411ed10fe57100f9d29a89fbca2b3869ab58177079fb916d7a488573" deposit_data_root: "0xed7664e9d1230b810ae66e70f7216a6cfc8dd8dfffb6781b25a724317713c991" eth1_data: deposit_root: "0xd4d4345b1ff711661fd8c50cb40512e1535b1e50b1abc36db5ca5ddc1d998963" deposit_count: "423" block_hash: "0x76d7667e463891a1f70c269d1a0113126715969b01f74733050cf0fed12f1f41" block_height: 424 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xfb785265dae57039dc1b110d2edb8556f05c9f2013e0cd5b57982be1642c2375" - "0xaab1605a8179a12b1e4e07684af74b5398445a216df5219be25801f44d75d56e" - "0xed7664e9d1230b810ae66e70f7216a6cfc8dd8dfffb6781b25a724317713c991" deposit_root: "0xd4d4345b1ff711661fd8c50cb40512e1535b1e50b1abc36db5ca5ddc1d998963" deposit_count: 423 execution_block_hash: "0x76d7667e463891a1f70c269d1a0113126715969b01f74733050cf0fed12f1f41" execution_block_height: 424 - deposit_data: pubkey: "0x8faef0de1c486a7638c2a50af8f34e42b7f11bc1168c03678408702f8d11637f1faf893955a39897d797c851d1e6267e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa03d1ab7e650e5b593fc076f109653b6ab3bcbd4ab214a638c91c182073d90e44dadd8243ec6b6055a08d7876d67231d11be579189b12e04ae0f6aa2071fbfa25680102c2cd9612955bd5ccd11e6924acc1aca90f17939eb50e364484707d58a" deposit_data_root: "0x618c9f801c71c3abb9c4a6b58ecd7bb0ee58537066ab15c04b86466d53acc316" eth1_data: deposit_root: "0x0ff9c5f8f3fce635e0c513c911e919396b682a34471d7a6d95f709fdd15c8713" deposit_count: "424" block_hash: "0x987c1a8ce6e27f94a0bac01816f3f4f54c057350d36bee07c00d83a62555e92b" block_height: 425 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" deposit_root: "0x0ff9c5f8f3fce635e0c513c911e919396b682a34471d7a6d95f709fdd15c8713" deposit_count: 424 execution_block_hash: "0x987c1a8ce6e27f94a0bac01816f3f4f54c057350d36bee07c00d83a62555e92b" execution_block_height: 425 - deposit_data: pubkey: "0x95bff09876e40fee59003b08bab452d9bd2dfae2c6411e153c4fc531f4aa26af8966049cf303865472d56643e3a3ad70" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa74bde4e1b2c55840198a66fd62671eee5e81c69c0d8418eb07c16c2003ba3eef1b8a7454b4fe1df5108e22bd8710288053fc45216787688320c3bebda2fb6e0402035ec9aa54f3f23e27c541e602f7fbbd4a259f5e359592486d027da49df31" deposit_data_root: "0x370e5d74a292574246d28b1c7e721565b32b960f041768ff4727d395b42de7d7" eth1_data: deposit_root: "0x1e3367c89e570fe259bed5fe2dcaaf6cdf1130c88b0cbdbe3880cb020a578772" deposit_count: "425" block_hash: "0xaad57c3a976f49af3a86b03765169a35d6d785bb020ff2cf5ce6e6725d4e5669" block_height: 426 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" - "0x370e5d74a292574246d28b1c7e721565b32b960f041768ff4727d395b42de7d7" deposit_root: "0x1e3367c89e570fe259bed5fe2dcaaf6cdf1130c88b0cbdbe3880cb020a578772" deposit_count: 425 execution_block_hash: "0xaad57c3a976f49af3a86b03765169a35d6d785bb020ff2cf5ce6e6725d4e5669" execution_block_height: 426 - deposit_data: pubkey: "0xa186ad3532db69f509d3f38223e388c9300031630ae02c5e13e6b55db6094554647fe52dbad51f931678c43d97f6b4c6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9464130c7ad45c27345e3383ba1e3a94ef7e5691fd9abd97b0cbd7c253a744ed2e953c561aa7196d2326a75c7a2410c4115b0968abf336ca7fa9414ab9580aa12b42e5bf991863df7ac526b8b00624704f025e6f8cdbdfb21411492fc0f30b38" deposit_data_root: "0x7d7cc85629154e45c92dcc1032aea2cb10f384ef24c4d8903cf3f6f7f4140a11" eth1_data: deposit_root: "0x2b3611ca950982c5bef154794766299407c48416ca3e3326072e108f83081f01" deposit_count: "426" block_hash: "0x34b26f56bc1b5b8b92acee8b5514178a4e1262479ba3c67294330a2d9dab14c8" block_height: 427 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" - "0x7f0c9697e17536d1ed08f791074bb7a4acf1a34de4a9d0e99d8e5057c1cd13f3" deposit_root: "0x2b3611ca950982c5bef154794766299407c48416ca3e3326072e108f83081f01" deposit_count: 426 execution_block_hash: "0x34b26f56bc1b5b8b92acee8b5514178a4e1262479ba3c67294330a2d9dab14c8" execution_block_height: 427 - deposit_data: pubkey: "0x976ecc14c14c93f8d0bcd6ee0a6f829de29fc13e167204e83d9c13d69065994af9c38424443114913e3142ca96138094" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x891aaeebcf8b8e5fbf12ae568c2782ac6ef3d42856d9476d12e7638bebd5f669bbaae802a46d7b9a41ea456547434ed806b583f696903bcc2a032961e7f123b4c0dc71356edb0db37de478452407fb48984e3d174fc821f707de94a67ef81100" deposit_data_root: "0x3e4beb332aee13ce0e48353814b5368e9571a2467f070677265eb9b41c1514d3" eth1_data: deposit_root: "0x3b62cf4ee50ca126c3da8052bae1db595a921d5aa400aa5a4e7b14750e8aaa5b" deposit_count: "427" block_hash: "0xfee92ed291741bf5c0e55f66775aa3b61a501b735d0b4b1c633dc48a1da857d5" block_height: 428 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" - "0x7f0c9697e17536d1ed08f791074bb7a4acf1a34de4a9d0e99d8e5057c1cd13f3" - "0x3e4beb332aee13ce0e48353814b5368e9571a2467f070677265eb9b41c1514d3" deposit_root: "0x3b62cf4ee50ca126c3da8052bae1db595a921d5aa400aa5a4e7b14750e8aaa5b" deposit_count: 427 execution_block_hash: "0xfee92ed291741bf5c0e55f66775aa3b61a501b735d0b4b1c633dc48a1da857d5" execution_block_height: 428 - deposit_data: pubkey: "0x847ec3a8b963b0a40506ad2e2a2f9119456d36150eeb64856f12c85a85e12d59b295d953d845246be5aeccfb70c1dc04" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb9cb0dfb5fcb39c230277f2574438a7c19d54a4ec2e3e2ffe7129f492ddca723f92f30e73dcd08649dbd534ca2cf2adf1002df9dadd275afc05f4043b5ff7dbe6e85db48ccc1b2939652c7c2dd67553d40935ec4c8f6af52125096afaea8bdaf" deposit_data_root: "0x7246ac04b767468d6e6962003af7f3c181600a6061e568046b7d4674a8cb6ba9" eth1_data: deposit_root: "0xd644b836a3cddf49cc1de8df9b2147a89e2cfcfe1eb18ea7d5af3415d20c5adc" deposit_count: "428" block_hash: "0x50f3f0653ab23862d6539b59676e3f7b9d7af24750232050ac04473e7d14c2ca" block_height: 429 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" - "0xabd7629e265df3c45f91829f510911e1a6dc607cf1967e4cf7a6a1978741a35e" deposit_root: "0xd644b836a3cddf49cc1de8df9b2147a89e2cfcfe1eb18ea7d5af3415d20c5adc" deposit_count: 428 execution_block_hash: "0x50f3f0653ab23862d6539b59676e3f7b9d7af24750232050ac04473e7d14c2ca" execution_block_height: 429 - deposit_data: pubkey: "0xa6be6fc30a561b92e84333e413ce5be1d83de64ff5cef73611840fde672bf26763901912b37dfd8f1af85c3af87c8718" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x97b2556b101e1c5b723317713a0bc7ec78848d693b16475f1d0ef7679a75189510913cd7e211a9347242dfaae7ebd71e05010b840b2920cc1a36b4402ddbbab8d299b67cf49a171c8a39b30c75880a455f2055717a5021e390f1073d398825f4" deposit_data_root: "0x28bacf6966c371a93169d29ba14a8a7f29b578c65832e521502eec860369c813" eth1_data: deposit_root: "0xbfc44c7d1d7f6b4df91c5cf86fa7b578915638c69752caa00aac61cc88f2531d" deposit_count: "429" block_hash: "0xd6afed7b6d18bb3524ad6fb17e2c46acdbcfbb3197f82e2b287d17e945a2b8cd" block_height: 430 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" - "0xabd7629e265df3c45f91829f510911e1a6dc607cf1967e4cf7a6a1978741a35e" - "0x28bacf6966c371a93169d29ba14a8a7f29b578c65832e521502eec860369c813" deposit_root: "0xbfc44c7d1d7f6b4df91c5cf86fa7b578915638c69752caa00aac61cc88f2531d" deposit_count: 429 execution_block_hash: "0xd6afed7b6d18bb3524ad6fb17e2c46acdbcfbb3197f82e2b287d17e945a2b8cd" execution_block_height: 430 - deposit_data: pubkey: "0xb1ea18e5c0a7424d06a9e77c65f2ff5047b5c4530e34e700c0d1bf15579e2afad228a8213c68eff8c14353d2e1f10053" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa965b7ec3ba5eb7d723ae622732f9398f875bffb7941b121c14daace185523a42e662151832132b8b296903c4432f77b02e06400a84268834eae712813f6bd4af66e571fd397c2dca316dba4c5ef7091ada36ddd5726d1db8e1e1f8ef6c40f6e" deposit_data_root: "0x81e40c00c14deb34eb65e0a158104b60554fd0624bfa86b560cddcd29eb66750" eth1_data: deposit_root: "0x46bb5f072f410bcb56d1f87830a0db231802265dec6ac59acd451360db8f3eab" deposit_count: "430" block_hash: "0xefef471cb7829f27db63a66917e6141f86a58f90c076f54a2ea35302ac6bb5d3" block_height: 431 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" - "0xabd7629e265df3c45f91829f510911e1a6dc607cf1967e4cf7a6a1978741a35e" - "0x3bbb471bc80341245a119253a0bd27206485c8d671ce2ab1904d70b635c83297" deposit_root: "0x46bb5f072f410bcb56d1f87830a0db231802265dec6ac59acd451360db8f3eab" deposit_count: 430 execution_block_hash: "0xefef471cb7829f27db63a66917e6141f86a58f90c076f54a2ea35302ac6bb5d3" execution_block_height: 431 - deposit_data: pubkey: "0x8fff13510ac685f51ae914b7177bdf296ecd757385442ea0dbfc8841685b79b7d52c780a40e07723ea34d6179c6f3ee8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb501c7b840d94f74b23e82caa150fd57a830cc20a665a84267e069fb8a93ccc56e7faae237f875e910a533a8eaa20cce06783be38427523d18ceb88bb4fef649c256ea05bd54cde8e05bf82826857e023afdfad82da136a1586ff0cd23435430" deposit_data_root: "0xabffe715ca708ebf5bebea360ea9c27f48e040dccc482bce560d84cf0c0f364f" eth1_data: deposit_root: "0x19e7f6f59f1a6bfc99344743800d79127bfa93e93118783888f7fd6bc3d23087" deposit_count: "431" block_hash: "0xe61cdc39257cdd0b1d973ef37bde4c7ad35fd8b5bd245be06da6a869f3be5364" block_height: 432 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0x60f09c9d72bd6a4e2cbb2f9f54623e280baddba85f8c51e5a07912c0782c2997" - "0xabd7629e265df3c45f91829f510911e1a6dc607cf1967e4cf7a6a1978741a35e" - "0x3bbb471bc80341245a119253a0bd27206485c8d671ce2ab1904d70b635c83297" - "0xabffe715ca708ebf5bebea360ea9c27f48e040dccc482bce560d84cf0c0f364f" deposit_root: "0x19e7f6f59f1a6bfc99344743800d79127bfa93e93118783888f7fd6bc3d23087" deposit_count: 431 execution_block_hash: "0xe61cdc39257cdd0b1d973ef37bde4c7ad35fd8b5bd245be06da6a869f3be5364" execution_block_height: 432 - deposit_data: pubkey: "0xad2d0e0c00b5a16d50a4ae56a3c0cf2e1b2263e2dd53ddad54679cdbf338300e1003af5ecb73ac3dacb8636661e142d5" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x841c98171049ea19762d010391bf195c097c130667801133259262d06ab7464e26cf14bf0dac3c8d08890db416a3301519474ab35920fd9ea961ebe80ae7a076f609fcf8cadf99c3bd46aac91456c6f543783cd042525bad6fe94730755330da" deposit_data_root: "0xa2a0f194432b58ec992b183815bfd4f21a1acdde93677175ec830dc8ada25092" eth1_data: deposit_root: "0x83784abcabf728772306f379a348e2329b6b03428e8120b6deb3ba1aefba2407" deposit_count: "432" block_hash: "0x98b16968453d04262b7c05ee1a2b09bcbcf8e29473c6d1a74bcaa3d03af6eccb" block_height: 433 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" deposit_root: "0x83784abcabf728772306f379a348e2329b6b03428e8120b6deb3ba1aefba2407" deposit_count: 432 execution_block_hash: "0x98b16968453d04262b7c05ee1a2b09bcbcf8e29473c6d1a74bcaa3d03af6eccb" execution_block_height: 433 - deposit_data: pubkey: "0xb854086bc1f668ad8ccc4ed3a7a52eab65210717c3f8b9e6ebc27c1cf27ccba0a4056311c69cfefe875fa45e2cd26e69" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa94b7daed00dd9fdacdb5cdc0635b588e5c3ab124438d7a1a59b068708e2fc3de327e35ce66800db13f100ca332db93219ff60525e13d868c66b5920d76c38c4264b9e68ada4586642ca4f02ec33438989c7f1d00cb9b02dd49dfc47d401d8f8" deposit_data_root: "0xda7276d3cd6c2ea2db69550570f8721ecb14d9e122e35c2d6090c600ad286bd9" eth1_data: deposit_root: "0x25028b90b69a3ff62a7a3cb3e67cf58130aa8868027f3b41613d71e8156162c8" deposit_count: "433" block_hash: "0xa783b7745e047a84c6270ab3910a09b000044ee37bca6caa2446153767236733" block_height: 434 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xda7276d3cd6c2ea2db69550570f8721ecb14d9e122e35c2d6090c600ad286bd9" deposit_root: "0x25028b90b69a3ff62a7a3cb3e67cf58130aa8868027f3b41613d71e8156162c8" deposit_count: 433 execution_block_hash: "0xa783b7745e047a84c6270ab3910a09b000044ee37bca6caa2446153767236733" execution_block_height: 434 - deposit_data: pubkey: "0x95000d5a88212033fcc30690e930c2128685b97f26a9e2c52b75e1fb562a1db1b9af071207823ef1927db3ca65ee00ef" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8444dfc139521e5236c5f5637cfa17c87b6fd06e5ca8d4e33e522f02cf9fee562903dcd42f173696c981e1113be5bee5102f84730a31c9e03b45b753178c65d87335bf82cd600384fc4d03151ca94880b0df31bad1ab4f09d760c604ca16487a" deposit_data_root: "0x184c58ea01f5c0c47d5dec98d30cfd9edeb11060b1c931cb3d117fd5cd6d7c4a" eth1_data: deposit_root: "0xbd639adce24d58cfbc0f226d6a045f400506c30d3388b4e520816c2ad1a5776d" deposit_count: "434" block_hash: "0xa36bde80ad1b5c6fa8848e656ef5c9c95411042e1fff4ffc23b4bc2bcb7e6bee" block_height: 435 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0x923555fa4c1bad92de2ae74472f84089b9f15bfcf562d84eb249313dc6bb6ae2" deposit_root: "0xbd639adce24d58cfbc0f226d6a045f400506c30d3388b4e520816c2ad1a5776d" deposit_count: 434 execution_block_hash: "0xa36bde80ad1b5c6fa8848e656ef5c9c95411042e1fff4ffc23b4bc2bcb7e6bee" execution_block_height: 435 - deposit_data: pubkey: "0x929ab4e52386b139d32da163a4e1be5760f1d97bcfdaaa146f8b0348c94896b33fdbc3083ff3a41063e1b969a1f84080" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x81b4e7bf1ea952ddeba8fdf3e4b81162e5f7481fa9f59a95604fb0b8f8e4edd17e114d264ce0a236ce2459880a68c11317ac8aa2faeca6f80eb2e5cb53f106dd992e687c7b86536de330630e0c7de7ae16ef04646f05e98340d689157b704f0c" deposit_data_root: "0x27578550b83a805d25278e7004eb819236d723c8e1be90d61b65d3fc50314abc" eth1_data: deposit_root: "0x27d9b9761517e56e0c390781d9e7e967a7376a27a09380615594f756608ab48d" deposit_count: "435" block_hash: "0x51f5137c853e6e77ec221f4c6185e11aa1f03537aa9c94d91d4a58ec8287466d" block_height: 436 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0x923555fa4c1bad92de2ae74472f84089b9f15bfcf562d84eb249313dc6bb6ae2" - "0x27578550b83a805d25278e7004eb819236d723c8e1be90d61b65d3fc50314abc" deposit_root: "0x27d9b9761517e56e0c390781d9e7e967a7376a27a09380615594f756608ab48d" deposit_count: 435 execution_block_hash: "0x51f5137c853e6e77ec221f4c6185e11aa1f03537aa9c94d91d4a58ec8287466d" execution_block_height: 436 - deposit_data: pubkey: "0xb126e91bd72a3289a04fa01e108f3ab4b77f2d20a93edc1c70f8ceda1df286461e92f73b7d2f85874abb1454ae1ef535" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa7f2a03af6e7075f289910a5b4348a6b2ff4d2f02633a44faeaccb965e6c2eb77647bc1489e6a8e39746fe29cabfaa92065161485194301a25617f81b96b7fc420eba955e13b04df59214faee482a439c3a2dd7cf5e3c9ba31a0309150b7d545" deposit_data_root: "0x5ed3598bdbce2f0bc4a26dd562b02fdc5c80ee35c013ee7c28610ae954b6b5e4" eth1_data: deposit_root: "0x6dff34424e745612aca561b1be1d10859787245ad98e2447b7bc9fa7bde0f008" deposit_count: "436" block_hash: "0x4820d0b8cf715941790bcc4e7ee618bbbace730c2bdba686471fac3746020dc1" block_height: 437 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0x7aa625d524b4796a9c8870fee5a28d37b822d5a6c4a9959b084e764ffa123a94" deposit_root: "0x6dff34424e745612aca561b1be1d10859787245ad98e2447b7bc9fa7bde0f008" deposit_count: 436 execution_block_hash: "0x4820d0b8cf715941790bcc4e7ee618bbbace730c2bdba686471fac3746020dc1" execution_block_height: 437 - deposit_data: pubkey: "0x8fe3f04f04422bb2c76f5cfddf80a7a2b01bef7170af5f52c94e64ba1f8f523ff18d09af9235e37d10b3ac8ba3cc6ac4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x94c9697875b08a8f6dd31af84ba20b702f8ac2a3488b6ea694bc1a3afd582bc5d52dff92b0c9dfa4ab6ab7080ed434b6047e3743f1007c560cdb7482eb09147d49c79f3118dc1fac66e918d25e86226042ede65d1ed7a262b8c165b78df81e3e" deposit_data_root: "0xb40085a98ecff79943839d4d2cdd7ab9bbb72f90e94daf08c50efd26eba09c72" eth1_data: deposit_root: "0xf52ca6c22904e0ebef5336e0f010308fd124d5caed6a6043da92e1cbdd7afc56" deposit_count: "437" block_hash: "0x7692a6ca9efd1b0796eb01fcdb2b08fbc1739837e6f24eeefadf8cdad2a8062f" block_height: 438 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0x7aa625d524b4796a9c8870fee5a28d37b822d5a6c4a9959b084e764ffa123a94" - "0xb40085a98ecff79943839d4d2cdd7ab9bbb72f90e94daf08c50efd26eba09c72" deposit_root: "0xf52ca6c22904e0ebef5336e0f010308fd124d5caed6a6043da92e1cbdd7afc56" deposit_count: 437 execution_block_hash: "0x7692a6ca9efd1b0796eb01fcdb2b08fbc1739837e6f24eeefadf8cdad2a8062f" execution_block_height: 438 - deposit_data: pubkey: "0xaaf6cc6cfc559ca26b82790935d4919ccc630438032b76874a40c25d77e4b87db2401cef8ad1871011569061ec7badcc" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa47e64f4d650537e9cb7d858267ee6862b97504ed46d11def724be28d05bd9c08e34420d5f06a1342536a47f120e8a540eb453b08c94fdb4c2deb3400f9cf87ce90a7cc1b14c8dea450111fb91f54fe4460e238588a6b4ab8778d48b99438a84" deposit_data_root: "0x99e08ee836bfaf2e9ccdcbfb308c88826e060edae11e3248a155049d4eaa772d" eth1_data: deposit_root: "0xb54a726ffc39347df5841efcdcdd4936894b92463db82208a447cf0071dcc95f" deposit_count: "438" block_hash: "0x3f48bbc9894a9a76b6faf91af106f773ade4285ed0b2e82591ff87514e41720b" block_height: 439 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0x7aa625d524b4796a9c8870fee5a28d37b822d5a6c4a9959b084e764ffa123a94" - "0xb3aeed2eb2f5e99db75fa362a4e6c7dccfcff20b110983ffd36ad0aaa1783e50" deposit_root: "0xb54a726ffc39347df5841efcdcdd4936894b92463db82208a447cf0071dcc95f" deposit_count: 438 execution_block_hash: "0x3f48bbc9894a9a76b6faf91af106f773ade4285ed0b2e82591ff87514e41720b" execution_block_height: 439 - deposit_data: pubkey: "0x8533f1c4e38a4f72c3593ab28ccb163bfb429242a8c23e731478e57950f563b62101b06882f25c8133ea357fad66522c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x861858db0f3721f816791c002f9d8f09254d0ba5015fc2fc609783cff8a36efc267392c0525e4e0fb4bfa96d58626732091853af4c16b9fa309e5295331a32f84b2c3be61d2c2dfc34bd9e59117c54a8c46ee50f9291ba2793450fc960e14530" deposit_data_root: "0xbbb5ada0d7f4efa62bf0ba927747f1af9d4cfcbd76eb084f24ace3c8b0167fe5" eth1_data: deposit_root: "0xf75c37a1a191b865e14c6dac867208ae436a48d454410ad13cc9410bd8e3bdc9" deposit_count: "439" block_hash: "0x00c49ac28a1512771b4a976e03f723442c209b14068daba22e931c5b7e357594" block_height: 440 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0x7aa625d524b4796a9c8870fee5a28d37b822d5a6c4a9959b084e764ffa123a94" - "0xb3aeed2eb2f5e99db75fa362a4e6c7dccfcff20b110983ffd36ad0aaa1783e50" - "0xbbb5ada0d7f4efa62bf0ba927747f1af9d4cfcbd76eb084f24ace3c8b0167fe5" deposit_root: "0xf75c37a1a191b865e14c6dac867208ae436a48d454410ad13cc9410bd8e3bdc9" deposit_count: 439 execution_block_hash: "0x00c49ac28a1512771b4a976e03f723442c209b14068daba22e931c5b7e357594" execution_block_height: 440 - deposit_data: pubkey: "0xa20e3bcb6b38b66c2de7a7b3d1731cf430ebb94e38897d9ab9a9463bfe813ecf65f39297d2a3daa803f66bff80d6b653" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x880a58b82783d37fac7f207c9ad45e6c7fe7f98cf843bd52733e328a87ab81a4b585f598907d594b2abfc03913e0983b00cba405f0478ec3ff59954244f36467b5002354dc3f56001cf0c06fe12535dfd3813a03e561f27d0fe475153a7cc46e" deposit_data_root: "0x05bb8954b6ae43cbaf05ef800efe85d1755df3df92888c1390ac7524d332f2f1" eth1_data: deposit_root: "0xee960dbb2cb5694f6bd15e8fbe5d67369629cfcb89920dd6e05dd8c95ed484df" deposit_count: "440" block_hash: "0xd597af80422338ab6dff2432fe3d82e43c817e4512bb29e120492a6dfe622bd2" block_height: 441 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" deposit_root: "0xee960dbb2cb5694f6bd15e8fbe5d67369629cfcb89920dd6e05dd8c95ed484df" deposit_count: 440 execution_block_hash: "0xd597af80422338ab6dff2432fe3d82e43c817e4512bb29e120492a6dfe622bd2" execution_block_height: 441 - deposit_data: pubkey: "0x8cd7d05a46ad2e98ea82c438f12dc9fad70fa0b8cff2a731847efedc0efadef9a3f4d9e12cf8e9469d157d106f12626d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa580ca98af67b935e7b896aa223bb2ae6fc23313da1d47595e244f5f9f6aac65b7b396a196be2722d6cf036f8c293de81736674e13303d5a6c8d8893ae1fc5b572edd9a84bb0feefe7ec293f6d9050f9687bf930ef42dffabb554094c24962b1" deposit_data_root: "0x4c2f5d2c7521c2fa4bc78d77d66c44bc032f688fdeae2a216221fb20f49645ab" eth1_data: deposit_root: "0x03e6ba3922640836649ecbb7649e8b5361eed51edc0e24919c4a2f258350be34" deposit_count: "441" block_hash: "0xf4a32ac25eb43a2dee79b2620ab6d79fcecfe26f5b4d1743a6c6e47057f8f478" block_height: 442 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" - "0x4c2f5d2c7521c2fa4bc78d77d66c44bc032f688fdeae2a216221fb20f49645ab" deposit_root: "0x03e6ba3922640836649ecbb7649e8b5361eed51edc0e24919c4a2f258350be34" deposit_count: 441 execution_block_hash: "0xf4a32ac25eb43a2dee79b2620ab6d79fcecfe26f5b4d1743a6c6e47057f8f478" execution_block_height: 442 - deposit_data: pubkey: "0xab5fec7f75687d50f35f4336b7ac78108834f98d9979f0327cd11b1557b6ad9dc119889003384b3940b10f0af7b8314e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb71c223a9819d28964a114bf849fb9f765087d4d32019a5fccc1062ea217a68ae8475708179e926d60f60df70a39973d09e6e387807f287dbf2d02db7a45be47f428330d2d2900a531b716ea53f90e9109c3aa061c1291b484eacb3f574372bb" deposit_data_root: "0x1d605f33e04dd29303dafd86bd3dd88e3fa4fe9f8a690c596af384d1515e4d23" eth1_data: deposit_root: "0x3f9a271478e34f229dbde7880720bb764f94cc3008ad30fc40b822fa46551e7c" deposit_count: "442" block_hash: "0x1306dfc166e3c7fdfe93ce194349c64b49f57eb0ab103fc426be4cc1ef7256f1" block_height: 443 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" - "0xacc05a3daa1af57565781fd828122e22e64a429030d2e8b20702611e6f49bd47" deposit_root: "0x3f9a271478e34f229dbde7880720bb764f94cc3008ad30fc40b822fa46551e7c" deposit_count: 442 execution_block_hash: "0x1306dfc166e3c7fdfe93ce194349c64b49f57eb0ab103fc426be4cc1ef7256f1" execution_block_height: 443 - deposit_data: pubkey: "0xaa93eab6f16b0bee0a2eaf3d548d354a716e1bfa4047ffae14af55bb49bb994310265e10c7ab47ffa33d1c3eceadbb4b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa4d489afd3c027948032978b0384fed21b6013e19108ebd8f2937e3b32854c91ea80dcf183670be34574a05634eb06b4109970b34b0e998f9d09615a7b8ec277c2d62b43daacc9d346733060dd7f08208164c57cc54dee78de08c4d42774e51b" deposit_data_root: "0xc91ecd7959d5713b9f528f6fdfdf456416f0c19514640347fd465d24352e35d5" eth1_data: deposit_root: "0x7bc70f5b38014ee13c40977439be4afa105e103bf24aff9c687c1d52def0d90c" deposit_count: "443" block_hash: "0xb6fcd3780b78de4f093046724aba76445fff193f0aab33ee3e08099403f5d076" block_height: 444 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" - "0xacc05a3daa1af57565781fd828122e22e64a429030d2e8b20702611e6f49bd47" - "0xc91ecd7959d5713b9f528f6fdfdf456416f0c19514640347fd465d24352e35d5" deposit_root: "0x7bc70f5b38014ee13c40977439be4afa105e103bf24aff9c687c1d52def0d90c" deposit_count: 443 execution_block_hash: "0xb6fcd3780b78de4f093046724aba76445fff193f0aab33ee3e08099403f5d076" execution_block_height: 444 - deposit_data: pubkey: "0xae363ffe8d6c6858d3c32967150ef670a2262ab9f46b3f2e3e4ae8910092bad1e7208ff9ba3f28b151dfab12f3474a19" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x803d1670174da10aa0eae9a24ef57151ce4fe2eb9f8c3144761f90fe483fd38d06aea4b7e6879afd43c5e1e3dfa223230edb7385dcd41d0d4eff69f94690ceab02bf9d5c35ecda1e30cc929403f64b0a08e9de644cbba5efcc5814ffbfc51322" deposit_data_root: "0x1ec544baffa893fc7cc179cccb186cae5d98da2920f837e49b6cd683abcb8fb6" eth1_data: deposit_root: "0xb81e9256ace4aee3308b567f7fb37713dff69385afb6b57a436070f318c2bd7b" deposit_count: "444" block_hash: "0x3c24b3a1983001debec5a13e73083d0bb99ab232cc3b26985f78dae529564581" block_height: 445 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" - "0xa1b8c431a46186490644ac091a8a657e248fdf1dbabd59a9e6c69007dce25c3b" deposit_root: "0xb81e9256ace4aee3308b567f7fb37713dff69385afb6b57a436070f318c2bd7b" deposit_count: 444 execution_block_hash: "0x3c24b3a1983001debec5a13e73083d0bb99ab232cc3b26985f78dae529564581" execution_block_height: 445 - deposit_data: pubkey: "0x83ae23912c04f49176c912a5d728224c3bbfac588e2203e37c6ca7520b01c6225b2830b0d37c8eb641d9abb44a648e28" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b5366124d214e3f88667a97297b75e2feaf3f54e09047b6e1d805499c961c76685f4dd16c8d169cff4fc17c401747ac0b6685693e80ab3324e4c77fcde51afb210799489d32a8251d6c25623abd5eb4930ab097b4d6d6daa38ad752cff3b435" deposit_data_root: "0xe76b1cfd301efe07f3af9878e54067b811f1872abd8cb7a02442fdf7cadd6d54" eth1_data: deposit_root: "0x99b58fdf354bd79892edced1978af6264777847c433d692efbfedff57526c7bd" deposit_count: "445" block_hash: "0x7480cf6cd450d4e3d9a461c222e8e0fd3a4416ac6c66a18d95bd870ed0294806" block_height: 446 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" - "0xa1b8c431a46186490644ac091a8a657e248fdf1dbabd59a9e6c69007dce25c3b" - "0xe76b1cfd301efe07f3af9878e54067b811f1872abd8cb7a02442fdf7cadd6d54" deposit_root: "0x99b58fdf354bd79892edced1978af6264777847c433d692efbfedff57526c7bd" deposit_count: 445 execution_block_hash: "0x7480cf6cd450d4e3d9a461c222e8e0fd3a4416ac6c66a18d95bd870ed0294806" execution_block_height: 446 - deposit_data: pubkey: "0x86d99bd43392d34879ff4409aaa44f1a42b34471a59136ff2fc2c5d0f3bee905108958f4a0de383597476b6f8fa380eb" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8560371d260fcc434e0da634b18e1216ca8d63ea40486020c9568fbd959ed350f8b8b3fc1f6f88a48b7517d927c08c04190dc945da272ece929599becb29c8ed939ccb31cc4f316bf2c7341e2373f44ff8515858606fab8165e4ac6356f037bc" deposit_data_root: "0x28f2965716ad7616ab299ba34a56b5da43142e03867076aa477efc5774f7aa12" eth1_data: deposit_root: "0x440365613909570f9c374a476876624deed2636114a1dece1e7051d565d687f9" deposit_count: "446" block_hash: "0x452bf66254b503662848f580173b6b13a10efdf20d2016683b67c4d0beafbad4" block_height: 447 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" - "0xa1b8c431a46186490644ac091a8a657e248fdf1dbabd59a9e6c69007dce25c3b" - "0x22ee861ca07aca649f7d8b981e6c3bf4615ac3944a6acefbfbc843fe66b2d14f" deposit_root: "0x440365613909570f9c374a476876624deed2636114a1dece1e7051d565d687f9" deposit_count: 446 execution_block_hash: "0x452bf66254b503662848f580173b6b13a10efdf20d2016683b67c4d0beafbad4" execution_block_height: 447 - deposit_data: pubkey: "0xae47eed8ebfbd33bf1e92f52fc40d16f4b2b5e0cf4f54f2463af76f83cf0fef26475dff6c5b9d78f81925ca7d51190ed" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x80f785a5c57201068c993fde0c2efb2004cfe05a03a65bae1562b9663fd62aa6a27fc529c69966838b3d2e41014eacdc1211d67c7ecfafb32d92e34a1bfdbd4df20f3051b7398715b95f34046e1e157186f2502725000322f66b6684ac7a5679" deposit_data_root: "0x4c4ee3b1458b7a43155652b0c8e734776ed957d7f0baadb41e9c69615240a8fb" eth1_data: deposit_root: "0x024dc727a35948ddc2d5c8def41df75d4ab5f9c638d8420fc130ce350d4ebf5c" deposit_count: "447" block_hash: "0x5d0fc230f957aec298b3a4f35bd4dbbdd2a71de4696668501310240d0c3c36ff" block_height: 448 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0x2586924062b8d4cce4bda9de914e2a85d8352e0ea9d1512a816b099cbcb65c05" - "0xbe065ffe4f04afdfe075ddd6d51b69a8b470abe91f51e18845e3dd959b272134" - "0xb009f607491090689f616596852977e7f2617f96388353655e0b01bb9e3c5477" - "0xa1b8c431a46186490644ac091a8a657e248fdf1dbabd59a9e6c69007dce25c3b" - "0x22ee861ca07aca649f7d8b981e6c3bf4615ac3944a6acefbfbc843fe66b2d14f" - "0x4c4ee3b1458b7a43155652b0c8e734776ed957d7f0baadb41e9c69615240a8fb" deposit_root: "0x024dc727a35948ddc2d5c8def41df75d4ab5f9c638d8420fc130ce350d4ebf5c" deposit_count: 447 execution_block_hash: "0x5d0fc230f957aec298b3a4f35bd4dbbdd2a71de4696668501310240d0c3c36ff" execution_block_height: 448 - deposit_data: pubkey: "0x9286bfc698dd8f807748245c4d13de02910fcd8bc9b375a308d8a2bc7c73a05c8254b73931e448fbb2cf2d24f8b42f56" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa4d210f5d05cc9475174d918b7f495c5a91291e08eb6e747a513265d3d7b52444df7213e1d476b8513f6ddcc90bf97c0e5ce888570f5537cc450b14ae716bc5bde3a8a251b9feb35129b63f52df8926494b921c0c2317548c680109503acff0" deposit_data_root: "0xffe2744a1f6606c4f333a1163e422c905af1da3faa8355a7c1d14b4d96cf3a12" eth1_data: deposit_root: "0x783f4af9f9ff701317e0a1fe3c9772aba6748d2c3278d5ab1bd30feb212dbccf" deposit_count: "448" block_hash: "0x3ca4825aa555d4e316dcf61ea7d127988b176af164b1705bab9831427b3a48c8" block_height: 449 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" deposit_root: "0x783f4af9f9ff701317e0a1fe3c9772aba6748d2c3278d5ab1bd30feb212dbccf" deposit_count: 448 execution_block_hash: "0x3ca4825aa555d4e316dcf61ea7d127988b176af164b1705bab9831427b3a48c8" execution_block_height: 449 - deposit_data: pubkey: "0x98857d698710dbc26a57f167d463de3fc8e15fa4221d8ef6d8853c7843b04d2119a865215075f52674340300e1ff58a7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xad731a0a79a0d708d244ee8766bca38692a89fb89abca67ed6ed6bb672daf44ab77fa66ad298f0a158e72d3f7b3a55c719700c6173b8447d7cb46b07336fbae244fa124e3f98b825b7dc10c9429fc85dc4a5aa671006021aa0a72e5552b95ef3" deposit_data_root: "0x6af628d2a153eb81599f51910fd685f52bd32fb10ac3556bb0c608b35afc0c5e" eth1_data: deposit_root: "0x03cfe15696d6d04ec988563cf653ae99e72a85641c1de5499e287c0dbfc3fe86" deposit_count: "449" block_hash: "0x090750899e4923ca431e67389a655fe6080af94162863e81712b21111ffd5587" block_height: 450 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x6af628d2a153eb81599f51910fd685f52bd32fb10ac3556bb0c608b35afc0c5e" deposit_root: "0x03cfe15696d6d04ec988563cf653ae99e72a85641c1de5499e287c0dbfc3fe86" deposit_count: 449 execution_block_hash: "0x090750899e4923ca431e67389a655fe6080af94162863e81712b21111ffd5587" execution_block_height: 450 - deposit_data: pubkey: "0xabb8d751f2f97cd345688187accda8e00395503e500bd727b82b0be88484587776c225d64ca72703c186d6d0cb248e76" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83ea0cdfe5f2641f06f69411ac348b2429f34544f17fba693e58a7c395b86afe7cb52ec681ee2b92865b38a2ef600f2708eb9746987cd9a4bd831a2d74953e17077c8eff72002d1e6dcfc63693c42e6c48801ed6960480cb8e88b36bdd67df5a" deposit_data_root: "0x966d2b44d3db4cd7fe7b890d54612f94f5e66aff6bb82f352e17ad42a35c7f60" eth1_data: deposit_root: "0x31cb5ea97e5cdb9ca3d10a4098e70b8fd784e6796603c63634eec24610665a1a" deposit_count: "450" block_hash: "0x1b42b2023d6aab58dcf21a8f96a4fd53a9980a99a92278d95bad77b79b3eb143" block_height: 451 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x2ee848cde5b8b481d247e89b448dbd7e7fb077ce49a7a8777cb3d52d858452ef" deposit_root: "0x31cb5ea97e5cdb9ca3d10a4098e70b8fd784e6796603c63634eec24610665a1a" deposit_count: 450 execution_block_hash: "0x1b42b2023d6aab58dcf21a8f96a4fd53a9980a99a92278d95bad77b79b3eb143" execution_block_height: 451 - deposit_data: pubkey: "0xb88f1156883e6edf6df2f4f94079d373992e2d236ddf7003cd8cf84d73e371d16d4397fc20163eb4d8b5ff134beb4b51" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8fcd914835883541cef44b08c1b3fc7c91b28f6fb491b9beff48554ac227dcb6ed535bb1a6cf8cd9be97f495420f358116c39749895d17784a6828bbfacc22c6bf3c42d17f8e4a8900ea17be43e6c5b27f4a83793ff68b26a9d9fcebc6a376e8" deposit_data_root: "0x88c1120bb5fa6ab67bf2b80803a27302619bdee14a10cf97df1e56ded1ed54d3" eth1_data: deposit_root: "0xe8b7f46dc7475278120b4752ae46cf7b4dc209ad1948739a5559bb8ad2c43846" deposit_count: "451" block_hash: "0x58a48bedd093c961425032a2b01bcc2789f04af84e1474c57d1739a0288553ce" block_height: 452 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x2ee848cde5b8b481d247e89b448dbd7e7fb077ce49a7a8777cb3d52d858452ef" - "0x88c1120bb5fa6ab67bf2b80803a27302619bdee14a10cf97df1e56ded1ed54d3" deposit_root: "0xe8b7f46dc7475278120b4752ae46cf7b4dc209ad1948739a5559bb8ad2c43846" deposit_count: 451 execution_block_hash: "0x58a48bedd093c961425032a2b01bcc2789f04af84e1474c57d1739a0288553ce" execution_block_height: 452 - deposit_data: pubkey: "0xb37a06d51bf2a06b938b2a1d84fc0e9a0d45e753401035d0c7557b01d200c302169a06c5276ed77b7b832a885376522e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb8152b87ca263de22dd75f0ef8197369bd750813ce33e8d49a67ee27ef560f384fe388f05a14aa0ac1a15cc43b7dcabe02bbd2035531e677009d17a552338e34e1bfdeedffecdc32982ed80ff2d863f39ee6b1e04136ea43a129edc137f60114" deposit_data_root: "0x719a442d020d219e23f2c202c972311f1eab73fd8bfe61a3518405c83c4df232" eth1_data: deposit_root: "0xb522e60c52c239b043e08c2f0cda07c615337f6067f9f76e794b1f71145727f4" deposit_count: "452" block_hash: "0xc276347716f8b77e58ce6840bae2e5fa0167bcc32590b414298060c7c70bc921" block_height: 453 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x6cd34b4abd5cf459af14ab7b1b53f14c3f3c752241056a9b64349432d18e4f4e" deposit_root: "0xb522e60c52c239b043e08c2f0cda07c615337f6067f9f76e794b1f71145727f4" deposit_count: 452 execution_block_hash: "0xc276347716f8b77e58ce6840bae2e5fa0167bcc32590b414298060c7c70bc921" execution_block_height: 453 - deposit_data: pubkey: "0xb960a785f7ea8fc1d9886ff43e3b736cf7fab383087b6f1d85727473d909a91215ec515fe72783d703e8d214cc72dbde" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa429b2d68b1a5e8493e942954a03d4cf7234280c5c48ece941bfaeb877351da8c9fc915141afb1e9f8ebca3eb4c1a7f006f4ba60b43df7951a87f9dcb7286b8bdcb8e34e3b1e73b53645425e35d68a7b95688b3557bcb30f7c45de075d3620d" deposit_data_root: "0x80b0dadc1f658351f89567fc40f0775d9a496f4e72380fc1187690de3223a11b" eth1_data: deposit_root: "0xc9f3220a5eef0065415e6ff59ca524424b32ad98e61d6a5fa58e3addf0c1d3b1" deposit_count: "453" block_hash: "0x99799c65563071761573abee510fc22423fd463f2f1ffc6c1185038e82171f51" block_height: 454 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x6cd34b4abd5cf459af14ab7b1b53f14c3f3c752241056a9b64349432d18e4f4e" - "0x80b0dadc1f658351f89567fc40f0775d9a496f4e72380fc1187690de3223a11b" deposit_root: "0xc9f3220a5eef0065415e6ff59ca524424b32ad98e61d6a5fa58e3addf0c1d3b1" deposit_count: 453 execution_block_hash: "0x99799c65563071761573abee510fc22423fd463f2f1ffc6c1185038e82171f51" execution_block_height: 454 - deposit_data: pubkey: "0xac748de8d5418285e99661d22ef888ee9b19fee4e3bb2db1fbd4404ac32fabf9ba2d41450c2f2ba42bd97cdf28a349b8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x89cb911ffbffec15dfaec2c21298681348e4c02cf3e6dde9c7fc73093b94115cf433a485dea3561efcf7feb2cf9c2ede105004f477bad9be075e408dd73ef9c3be78862c8b6b3bf4122b28f887ae0a0120bc7a754e1f46dcc6b4b9606ddbc23b" deposit_data_root: "0xcd7377eac780c66d2dd90fbcda1563fbcc7f4cb53c0d2e2f4c22f88005755562" eth1_data: deposit_root: "0x20d947edb9a78bcf6b5a8ab78f2fc9d1b08a451d553977ae010d2cdc39566e59" deposit_count: "454" block_hash: "0x60bc4577621cbd0cbeb9238733a408f77bc2a1958775e864f8dbaf88e09be44c" block_height: 455 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x6cd34b4abd5cf459af14ab7b1b53f14c3f3c752241056a9b64349432d18e4f4e" - "0xfa8b871b3d268957a0da1ff487492cb4e8ac619d397f80e1a36987ca54ef56f9" deposit_root: "0x20d947edb9a78bcf6b5a8ab78f2fc9d1b08a451d553977ae010d2cdc39566e59" deposit_count: 454 execution_block_hash: "0x60bc4577621cbd0cbeb9238733a408f77bc2a1958775e864f8dbaf88e09be44c" execution_block_height: 455 - deposit_data: pubkey: "0xa89895024ffe3c247d5515a8f2cf3e5275dec9c1c3143d7a4dbabe1aa16761ca69225bd2921a4afee83e01cb4c83c25f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x84d1d54c7b7afe591fd9be6342e92f4a1e0a0983a73cbf620c9653f602df0b9f1fd205e2b5e21edb3529cfb4fb200681012beaf6de044ee3198b256134c1a2b655df3fdeba942999f6f4e1642fa34b6185c5016d353e19441fcf55cebf6fd085" deposit_data_root: "0xd5166ba088a056939b9bd3f7fc516190e2dd84b2f2872c225236a97908cf5d60" eth1_data: deposit_root: "0xb9093524f50637874422a739e135b55224a74123bf8d04b993a02921a5401dae" deposit_count: "455" block_hash: "0x6a4fb53350211cabe2bc406b3da41c4fc959922aa4953a42326fa0c58b5db8b8" block_height: 456 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x6cd34b4abd5cf459af14ab7b1b53f14c3f3c752241056a9b64349432d18e4f4e" - "0xfa8b871b3d268957a0da1ff487492cb4e8ac619d397f80e1a36987ca54ef56f9" - "0xd5166ba088a056939b9bd3f7fc516190e2dd84b2f2872c225236a97908cf5d60" deposit_root: "0xb9093524f50637874422a739e135b55224a74123bf8d04b993a02921a5401dae" deposit_count: 455 execution_block_hash: "0x6a4fb53350211cabe2bc406b3da41c4fc959922aa4953a42326fa0c58b5db8b8" execution_block_height: 456 - deposit_data: pubkey: "0x8e0cd6b49327ba93279e394f62cb84375fc63bbac7c72eb4f90cd5d71e4cf34f1fe0d92b82ce51e60d9255a0fe99e021" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb16f03ea11ebd8f5f5c864bf87df767429229be5fad7b41bf26fa025bc4248af339ff07be292f5661d975344c4947d871368db8fd3ab8995c7ba358e4e73218b169fa32fbcc4839f9d1a1a9ef52b4169929d48d400783cc959ad4ca27a3432ad" deposit_data_root: "0x35d372da653d0c041ede27965e52876b47afacc14fc6ed6eaf37580bd5f85177" eth1_data: deposit_root: "0x88685588119ba1394dfd58c01b558e18fd9e1630431136f478f0099a37fad6f4" deposit_count: "456" block_hash: "0x16b9630f3d0113ff5a3688bd3ecff00d4958a1136f6e3e9c6155a35288c51cd6" block_height: 457 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" deposit_root: "0x88685588119ba1394dfd58c01b558e18fd9e1630431136f478f0099a37fad6f4" deposit_count: 456 execution_block_hash: "0x16b9630f3d0113ff5a3688bd3ecff00d4958a1136f6e3e9c6155a35288c51cd6" execution_block_height: 457 - deposit_data: pubkey: "0xab195eaafc5a60c4c91722f53e19fce9c04ba9655f433a18f0472606ec826fbf77828d16f859297a9272d2b4fe50403b" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9297d77b34934381a63a39e25ae8ffd26a67bb1baaf6ce2d39ae53dde9e0ba2eb9ea5f6cd61d9f82a73e3c8f00220b5c14ded82f49ccc953a82a6f352a693d57ec256877122b2caf56c8405269a44ca255de858a1af5504388c4a04b71bdde1d" deposit_data_root: "0x69c7a9d2550955ae43c7a6790737017c37d9d2c353af01686d4736259ab45a77" eth1_data: deposit_root: "0xcff79088a43be898c147090a135293d6ac0b9a05370a36aa6403897e449b6d74" deposit_count: "457" block_hash: "0x66e0fcb1ac380fb70e9a3bf4771276b0a1bd23bf7cf6eb37fb3b919c7da07e98" block_height: 458 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" - "0x69c7a9d2550955ae43c7a6790737017c37d9d2c353af01686d4736259ab45a77" deposit_root: "0xcff79088a43be898c147090a135293d6ac0b9a05370a36aa6403897e449b6d74" deposit_count: 457 execution_block_hash: "0x66e0fcb1ac380fb70e9a3bf4771276b0a1bd23bf7cf6eb37fb3b919c7da07e98" execution_block_height: 458 - deposit_data: pubkey: "0xaea50380eaca9b09e5baec21e5f522c964b0ac8d4aebb8e1a1a196a01fb5c2c87f524be56a57d2f80274d1a0d2ed7fa6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x954643a0a8494712b0e1c45e089b17e84bfe57e4d901841e2e2381b303b724caf34741564ba450c8ef8469999f22a9a811c4b14c4599e2c3caa45f306264b7149402c643e4c82fafa3c966cd0bef954a214c06311ccf6a812b1ef43ea279a2b2" deposit_data_root: "0xb131ceaf7a69f35f76b5c8e6ccd346ccb2f10cf14a173d12758dd4a9fed3c0d7" eth1_data: deposit_root: "0x1ef3716bf7e7a51f7fc622319f07a89a2ea1c2bd4a6149e5ea6e069e63a5dc66" deposit_count: "458" block_hash: "0xbca1858a0a0f800b2b1921341c915c917e67ba447b530834ddab39c1b4b5dd59" block_height: 459 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" - "0x2f22c52f2268d8873a91866c36b0c38a75a64c6598e974ce14cf6b0b783fcf8a" deposit_root: "0x1ef3716bf7e7a51f7fc622319f07a89a2ea1c2bd4a6149e5ea6e069e63a5dc66" deposit_count: 458 execution_block_hash: "0xbca1858a0a0f800b2b1921341c915c917e67ba447b530834ddab39c1b4b5dd59" execution_block_height: 459 - deposit_data: pubkey: "0xb68a35785d29094de3457406b8f974581ab72e2aea2c3ec1ffd21b0326297f09a838b669e3e1409e127a3bc3eaa8cb72" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xac9f75a49603af9cd321f521460eda36c3a1dd7eb88bff394e7692b8d4dc7e7c33868025c7cab4b365693a8743d514d5029c238b47357486bb3b4cf31f87c9ac07327ec39858fc89b580dee5ddcdf7d089acfb238cec502403de5bc2487ddb6f" deposit_data_root: "0xda57dcc5780f0fe914a0f88d1db9b36324b9e13a0fc44ad777ebec7a8ac154a4" eth1_data: deposit_root: "0x6262414f9280a354022ae8b80692ab01589f0f022775dbc08e7cbaabe1feb343" deposit_count: "459" block_hash: "0x88421a8eac3dd6665ad9040506148cbb90c37ff8278e3286d36eb41939177435" block_height: 460 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" - "0x2f22c52f2268d8873a91866c36b0c38a75a64c6598e974ce14cf6b0b783fcf8a" - "0xda57dcc5780f0fe914a0f88d1db9b36324b9e13a0fc44ad777ebec7a8ac154a4" deposit_root: "0x6262414f9280a354022ae8b80692ab01589f0f022775dbc08e7cbaabe1feb343" deposit_count: 459 execution_block_hash: "0x88421a8eac3dd6665ad9040506148cbb90c37ff8278e3286d36eb41939177435" execution_block_height: 460 - deposit_data: pubkey: "0xb90a59e63d66d20d5e9a3b45be51fa7963da5ee137a126740036f432c50eecaade78c4a5bc92fe1908a153b15ad92a25" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8397c642292c99d42f208b26b2dd82f1e8d214dbb6829b70cf5a55c710a37572fb77e02beafb4c2208e7c6a965529009021b0d55dbf63c6eda839187158f5cb2141f25464da3802e2f411ec7bf5671225b231d2a4a48ed90c72ec8bfbabe30d9" deposit_data_root: "0x51c105f98c9892d6d1cead0485fe9058e733fbff334a4442e409140899cf445f" eth1_data: deposit_root: "0x34fd2a662b2220a66fc9b966be349b6c80781bf702a8702957ebd775a35e2e6c" deposit_count: "460" block_hash: "0x07fd13866775681d13fc3a2f7fd2ec38c86341a724a12140ed79d6c95bf1ad8b" block_height: 461 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" - "0x689f0a0b6d57f49f4654c506592ef965bcdab3336c358f30213e2d5d3630415a" deposit_root: "0x34fd2a662b2220a66fc9b966be349b6c80781bf702a8702957ebd775a35e2e6c" deposit_count: 460 execution_block_hash: "0x07fd13866775681d13fc3a2f7fd2ec38c86341a724a12140ed79d6c95bf1ad8b" execution_block_height: 461 - deposit_data: pubkey: "0x9826a9986a35754dfdc31e69bb8b073eb7293aaa747b0990da43c2c04bc001c78257ab3a1a91d3c7f2bb9c8395ed9424" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa569d9ac3ef0d59e22d7776348817afbbe1c4213c2d827dd2c75cb4cc7992fafd838e5661b98a8f77712a82eb3a6e798106b7d3ff6b1376de96bebef0a915e648d08fee8478c5e39e8085693ad0af6ab4e5dfb0f22136e9d2f1a7d1b1a6d6482" deposit_data_root: "0xb50cfbee3651658b71f15612069c1ade31ca2a26449985ef20b99f3ffbd78353" eth1_data: deposit_root: "0x76934fb0b2c000d79600b534433d9ae771971013b7e6ff1b5459ff86f9fe09c7" deposit_count: "461" block_hash: "0x9ae6b3c353ce3cb09bfe114d6b4f3a02e3119baff9cd693a7215a3036299c7ea" block_height: 462 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" - "0x689f0a0b6d57f49f4654c506592ef965bcdab3336c358f30213e2d5d3630415a" - "0xb50cfbee3651658b71f15612069c1ade31ca2a26449985ef20b99f3ffbd78353" deposit_root: "0x76934fb0b2c000d79600b534433d9ae771971013b7e6ff1b5459ff86f9fe09c7" deposit_count: 461 execution_block_hash: "0x9ae6b3c353ce3cb09bfe114d6b4f3a02e3119baff9cd693a7215a3036299c7ea" execution_block_height: 462 - deposit_data: pubkey: "0x854de57710b835c0253eef8a20d2e6f0ef8d260eb4443bbd5c38de0acd38035f0c1ad5d09994744588a497f8eb3b747e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa818e6ca068133ba1cb41c57f6b6b16db4ff64bdbe67d8207206989d8efc0021fb002976c3cff587687741db6d1ab6a200730acfe51121f49792c11865efde86e8d7ae4750f047eb18d544fcbe0aa03b73a38210a914cc1eb82012cfc9e0bb22" deposit_data_root: "0x48c0a3d3ca1ae0f20cd20838fac325cdc0b92253a3431bb9033a2b4144afb08f" eth1_data: deposit_root: "0xe74c79921d452c89e27a9414c76a65286982c0951d4ee0eb486361fc8208e5e2" deposit_count: "462" block_hash: "0xa11e6044fdd05aa46ecf17d49edb46d91545f750db221a4edbab2663880d2cee" block_height: 463 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" - "0x689f0a0b6d57f49f4654c506592ef965bcdab3336c358f30213e2d5d3630415a" - "0xc47891c2dae75dac43cad9c632bfbed1549eab22922ad0829e49fb45e3bfaa98" deposit_root: "0xe74c79921d452c89e27a9414c76a65286982c0951d4ee0eb486361fc8208e5e2" deposit_count: 462 execution_block_hash: "0xa11e6044fdd05aa46ecf17d49edb46d91545f750db221a4edbab2663880d2cee" execution_block_height: 463 - deposit_data: pubkey: "0xadc1109ded58e828f3c992b3d367b8e8d9d5cbe102fb171b4f4dfa66a181ab040f13d15a38b10e50c8c87432904b6e1c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb8799635089cb0c7b9703daf090358b53459304538f784eea9802a284bed2adb69c3c2e3b244da77b7ec5b420fbe2a4e1220c59059d904847b4750f7c188c92cc826ecdf1c6650f789856dcb49c7fbf380c76702169dfecd0c7d076ffecdfa1b" deposit_data_root: "0x8e7112b4f311f4c3a3a295185ba65739fc5f0a7bc06e2a561fd9f5ec1e3c56dd" eth1_data: deposit_root: "0x8dfaa386c19f0aa3bb523cdf7edae9a99a54ba5af875225e8ef106d89a9a7583" deposit_count: "463" block_hash: "0x66f1fe4d2e95c883b0a7698c48ad71aaaed1206a9ae8cce0d46c99a2d1834076" block_height: 464 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x53c1bf574da722d22635feb98ceae3cfa185fec248396946d571681fb60e9005" - "0x689f0a0b6d57f49f4654c506592ef965bcdab3336c358f30213e2d5d3630415a" - "0xc47891c2dae75dac43cad9c632bfbed1549eab22922ad0829e49fb45e3bfaa98" - "0x8e7112b4f311f4c3a3a295185ba65739fc5f0a7bc06e2a561fd9f5ec1e3c56dd" deposit_root: "0x8dfaa386c19f0aa3bb523cdf7edae9a99a54ba5af875225e8ef106d89a9a7583" deposit_count: 463 execution_block_hash: "0x66f1fe4d2e95c883b0a7698c48ad71aaaed1206a9ae8cce0d46c99a2d1834076" execution_block_height: 464 - deposit_data: pubkey: "0x87068fec51465d586d65ff531b32fe20d2e02535c08883721654338878b1aee8479fab486a19de804da1f301443f69d0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8e8b77fbdab9f6a210e3d8dac73df968fec07362e42dbddfc5533b103715438897012d2d49b64ecb920ad8eee641cffe06706a2af60897c44a21bc6c6581e878235070c197d57f9f8882bccc88feeafb1d0203569be51063663f82027a3da08c" deposit_data_root: "0x14cab7fbbcb0c52a1c60cb65d05f7be70e33e4d4e6367ddc931482e6d839e76d" eth1_data: deposit_root: "0x42a835e727b7aaf06d891a55d8b7a067512cc87046e043dada051674d3d61438" deposit_count: "464" block_hash: "0xbdb7f8ea7927498e58540bc2b1d70b082c025dbe0d41fea325e7e65427d396dd" block_height: 465 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" deposit_root: "0x42a835e727b7aaf06d891a55d8b7a067512cc87046e043dada051674d3d61438" deposit_count: 464 execution_block_hash: "0xbdb7f8ea7927498e58540bc2b1d70b082c025dbe0d41fea325e7e65427d396dd" execution_block_height: 465 - deposit_data: pubkey: "0x95322a22f4abe8eb0a0f4cf8876c31abeb3684ed984f6b595b9f3b9527b60c5f730d03d4960f5094210a3f6383691348" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x921dc1028ad56faf90a0732ed439ca36f5f4fa643bcad13b95309a6afcab2ef45f535601289b18d3b68244a23b598e6a014d3b75ec07afa43a2718b9c1a670d8587d3fd8e6254204f6d2c3937ca09cd0c80de526b8bbe2150f4d3e05c218a747" deposit_data_root: "0xea4b7f1637589d380ebdd0b75914919c07ef2936943a96865acd55028cd7c065" eth1_data: deposit_root: "0xf289bbf81113da5f485fc53db8a774b6817e4648e8c1f5e7136c68ffe1688fb6" deposit_count: "465" block_hash: "0xf02d6940bc1291413166041a1c800d2d86203d07151c71ed39604d78e50800a1" block_height: 466 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0xea4b7f1637589d380ebdd0b75914919c07ef2936943a96865acd55028cd7c065" deposit_root: "0xf289bbf81113da5f485fc53db8a774b6817e4648e8c1f5e7136c68ffe1688fb6" deposit_count: 465 execution_block_hash: "0xf02d6940bc1291413166041a1c800d2d86203d07151c71ed39604d78e50800a1" execution_block_height: 466 - deposit_data: pubkey: "0xb43fcdad30bb652a82ce6033d6cdd6b004f58eb102d54f4de5a59c17c774c66637e7ed8078b19afe55ed34ac2b969fc7" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83444116edd61f30eb0ad94e86f36834a2b99db16ff37a19139349456b8afd64b7dd6c92e7fa8f6fe9bf13de87c39fa80d3dafdcf00f9285e2610a63da505c2f91bb01d55cb2f75f0aebdfa37ed10d8a8102165adf87d03b421e604231ed200d" deposit_data_root: "0xba13491453796254686b89b3a1d2589d271db8a73cf2420df2f1d7a232c69238" eth1_data: deposit_root: "0x566f2e0bf068a861f4bcbe154f442dd6ae9097bbf4270c7dbfb3221ae6957fde" deposit_count: "466" block_hash: "0x29affc9ff69377a80f0888246a6bc7c98e7b914e4d6ce935f33e017fbb119519" block_height: 467 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x4f223a1f874097defdc9227f99dd60128d5695ed143768671db7ea87ff207409" deposit_root: "0x566f2e0bf068a861f4bcbe154f442dd6ae9097bbf4270c7dbfb3221ae6957fde" deposit_count: 466 execution_block_hash: "0x29affc9ff69377a80f0888246a6bc7c98e7b914e4d6ce935f33e017fbb119519" execution_block_height: 467 - deposit_data: pubkey: "0x801125a4149f3b2ae29f7745ed91492ebd9de91da253f0a267f864302044310c1f9decede6b1b5a9e1719c36841aff5d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa4fd707ca74abc5be01c340ddad32ac490f164119e323928247e7ce5e846f31c7642270acd7cb26b220e1f957a2e1230e4073d742bfc38dc538ed5089e89d1765c8c459f2d0997357d548e797267db7066f91541415aa769fb3eaf964465861" deposit_data_root: "0x344061e3131a0fd07c4f8c46d4e68950c9e0226907b418e7485009a1efca42e3" eth1_data: deposit_root: "0xf92d82cd5cfaaba51447264da8eed8cd65da770562dcedd00ec05ff6da207892" deposit_count: "467" block_hash: "0xee7806737892c8ba330f1d4545aacbee5f0a4b25c44d596f5eecf419ca936039" block_height: 468 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x4f223a1f874097defdc9227f99dd60128d5695ed143768671db7ea87ff207409" - "0x344061e3131a0fd07c4f8c46d4e68950c9e0226907b418e7485009a1efca42e3" deposit_root: "0xf92d82cd5cfaaba51447264da8eed8cd65da770562dcedd00ec05ff6da207892" deposit_count: 467 execution_block_hash: "0xee7806737892c8ba330f1d4545aacbee5f0a4b25c44d596f5eecf419ca936039" execution_block_height: 468 - deposit_data: pubkey: "0xa7852f47c6391e4ea0854d59b4a69ac72be49f7f798c19146a787dcc25a48a183ac3902001d0225f242ced6cc09aa378" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa0a90f6758d780721ada83e733fbda997001304b093517bb175d9b50f903d366f16ca33f47d716197317f81326688aac0c99be675058e687c2391016f28451c82484faa49311ca5b5af7b73e68003ec0b6f10a03a5fb0d735e32a6319bcaee81" deposit_data_root: "0x9da6faf501a235e8957b782d919b8b63d469f9cf252b5786fd8ee778e291a127" eth1_data: deposit_root: "0xd7166c06e1e85afaa7ae992a6aba05a63e6017f6be9acc4bd43344807cbda528" deposit_count: "468" block_hash: "0x29e18f49fc40f155ff1bd424b6af69c1bb1146f5e5060fc5c9c6badabb52ec28" block_height: 469 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0xb6a8aae06157a95d5852c69b8815034853daddd3aea1c41b6082f625f64a6688" deposit_root: "0xd7166c06e1e85afaa7ae992a6aba05a63e6017f6be9acc4bd43344807cbda528" deposit_count: 468 execution_block_hash: "0x29e18f49fc40f155ff1bd424b6af69c1bb1146f5e5060fc5c9c6badabb52ec28" execution_block_height: 469 - deposit_data: pubkey: "0xb0c1eb313f3894f5f19ddd7cb3472f015ccf51c24bf4316fae3e8502d3b65132a8d2ac58f7d17eec0a644ef31afda14d" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaf2982541a4ee7cd7a39ce1f4dd094b64bbdf93763ae134a09c4abdb5dad4830b772b610dd54d8e7fb782de6f6e524fa0bd3dae3737afebb2a10478ba965d1619276a04a3782d3976957c60fa92cf552876ff66db974c8c4fd820a738b980040" deposit_data_root: "0x6bd3f89d5210692fea089c2d827b529bd2c9127d4dd27b152bd78da7bd466f29" eth1_data: deposit_root: "0x17128858a7687c2474b0cb4f79f498a32c46a922afd92d97723efcbc332b93e2" deposit_count: "469" block_hash: "0xc50e70d8f92b0410c880a034aca2ebff5f6b2bd917673b1b7cb095be4b7c033c" block_height: 470 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0xb6a8aae06157a95d5852c69b8815034853daddd3aea1c41b6082f625f64a6688" - "0x6bd3f89d5210692fea089c2d827b529bd2c9127d4dd27b152bd78da7bd466f29" deposit_root: "0x17128858a7687c2474b0cb4f79f498a32c46a922afd92d97723efcbc332b93e2" deposit_count: 469 execution_block_hash: "0xc50e70d8f92b0410c880a034aca2ebff5f6b2bd917673b1b7cb095be4b7c033c" execution_block_height: 470 - deposit_data: pubkey: "0x8c6ccdc900d78ef20d5b22ad540e73864c858baf068349dafc397cd31c571708ec6ee6afef9e5711a587e3e97f1a50a0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8d02c24dbaa0a13109feddc00dba3ecdbccf6f9f89ea859ce8293f131679c24786317f96ec390c847084f7e8ae5f56060b45fda9cbdfd4219e2806f0c2e340947fcb2860ab279860360e936b31e27fad05a4ffbbff514432e3f15f9ac7fbe5b7" deposit_data_root: "0x63bc1e79593a6bc90ad3e76e5cab85bbf3ebc0f95993633ee2070133bb805ee8" eth1_data: deposit_root: "0x0114581f1558b58a8fda8d0fd4d9c8d81e3a0a44e1ee0da77b688940dfcae870" deposit_count: "470" block_hash: "0xc72dde0d8a48244290c055cdcac8a82a10a5c83768430f4216a7f0db007f65bc" block_height: 471 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0xb6a8aae06157a95d5852c69b8815034853daddd3aea1c41b6082f625f64a6688" - "0x1b129cc8ae0d0bcf87188bb66ce17acc25350f28de10249e179c868a9f7a4a79" deposit_root: "0x0114581f1558b58a8fda8d0fd4d9c8d81e3a0a44e1ee0da77b688940dfcae870" deposit_count: 470 execution_block_hash: "0xc72dde0d8a48244290c055cdcac8a82a10a5c83768430f4216a7f0db007f65bc" execution_block_height: 471 - deposit_data: pubkey: "0xa8aa5faaa4bbda5b5e7d610746f27c09bdee3a3f057550bca600ebe1c83749525a135829669a0162c3339ea40dc5525a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x94fb954aed2ccc71dbeac75d03bab4f59bc09a2468b25a12ccda4d50efe9bf2ec3e4188ecbe50c1bee58ee2d90acb83b116085775618887034be7c1487e52e76d2aaa2fca8fc37ebbbf552d4a5996d086fc653b447337a89bcc0ff4e678b2e94" deposit_data_root: "0xc9ed8e05a9be23ad58521dfeda162c75bff62477ac3aea3f373e1c12c5fe5ce7" eth1_data: deposit_root: "0xc05d8b31462806679096a4b5e89c1f82e0c237f65cb53f9dbd7086517aef4321" deposit_count: "471" block_hash: "0x9923a0a46a2f622ff2ada864cb8ce46be4ad5ac7fd386ee8c1dc2df41279395a" block_height: 472 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0xb6a8aae06157a95d5852c69b8815034853daddd3aea1c41b6082f625f64a6688" - "0x1b129cc8ae0d0bcf87188bb66ce17acc25350f28de10249e179c868a9f7a4a79" - "0xc9ed8e05a9be23ad58521dfeda162c75bff62477ac3aea3f373e1c12c5fe5ce7" deposit_root: "0xc05d8b31462806679096a4b5e89c1f82e0c237f65cb53f9dbd7086517aef4321" deposit_count: 471 execution_block_hash: "0x9923a0a46a2f622ff2ada864cb8ce46be4ad5ac7fd386ee8c1dc2df41279395a" execution_block_height: 472 - deposit_data: pubkey: "0xa7c107c72118446d1dc3c5c1c42f95ca2471dddd61c1461dd8ce028a1dae7656c98c3eca5f6dbeae8f9594e3e652a4d3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8cec6a4e726448a24c2f9f4e1f82366bd723596c8d4a62be7a2c8a0e0a513518b9cd9cd00a13000a1d03a5bde2336c920752aa634d77143f890ab2718ecaaa5527fe7ef3b2489ff7548af90eefb857c03b9bf52dc9089989387c8be9141dea65" deposit_data_root: "0xd2602c538061473ff8ada72bccc5cb574ea9811b109867a442ec621a78184249" eth1_data: deposit_root: "0x71d80a6c13aaf2af9b142d5f75859f7f86cf33492301a62d42134810c1a43862" deposit_count: "472" block_hash: "0xd4b509039b3e7f5664ed77eed00addbc90392021394ae1c431c10f9236bf539c" block_height: 473 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" deposit_root: "0x71d80a6c13aaf2af9b142d5f75859f7f86cf33492301a62d42134810c1a43862" deposit_count: 472 execution_block_hash: "0xd4b509039b3e7f5664ed77eed00addbc90392021394ae1c431c10f9236bf539c" execution_block_height: 473 - deposit_data: pubkey: "0x899eaf183acd5beee0899a58c8ee5fff1dc76df143028d9871d231e8a3999d92098538d070fd1c9db5d9db60f23dfd4a" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x88a116fece26c6e4d209321a5c58a8e09e01fe165703b042cb577060a8bc3255a281bc960e65ce253e66d15560e38efc10fadf7f49224583d4d25b34258d46ffd6402356684954e33849e968ce77d484307dbcd7d02a6eaf75185c7512231add" deposit_data_root: "0x57f93038b3cac9f76cb61db2309f1a5853dee6b9f4b3e713c34c4cd2a18631dd" eth1_data: deposit_root: "0xdc3672b4162de2f668f5865ee0f8e00e755777968de8c44b3320c92592c8207a" deposit_count: "473" block_hash: "0x947b126441051344edc68b986f9b345352a4f0420b44dd06a6359204d5d0ac4f" block_height: 474 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" - "0x57f93038b3cac9f76cb61db2309f1a5853dee6b9f4b3e713c34c4cd2a18631dd" deposit_root: "0xdc3672b4162de2f668f5865ee0f8e00e755777968de8c44b3320c92592c8207a" deposit_count: 473 execution_block_hash: "0x947b126441051344edc68b986f9b345352a4f0420b44dd06a6359204d5d0ac4f" execution_block_height: 474 - deposit_data: pubkey: "0x8771579633474fb50075b4c801124f63c4a786e7a618bc50c00122f4fe8c18d1edc123ce9be8436b9bc8159c5d2061ec" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb208ae48bba24e07a4d4dd1465cd92f135487a71353e79657250e66e18e31c08477d6b3f94cd8836b18ac1d6d154fbb50bfc5fb9e261c5117b30a96dbb3ae0dbcfd912b465b1b0c694d0030c97ed3b40437c0559fe95bd2cfad07706345e302c" deposit_data_root: "0x70e6082f9f4c9f7cb7c0d946caac7dd325787fe08c2a6fde05ddc7ee71bc1978" eth1_data: deposit_root: "0x1e2891528f3695be75c16e6f8e948737a6be58ec77667c41f70309fe2d0a0c24" deposit_count: "474" block_hash: "0x05b249730f2706e2825a6c3beb0582bc9430679dae5fa24c864a246efcb97eee" block_height: 475 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" - "0xff8e34dd64f1d9e20b42622f7dd59ce1f29ae93f52847609c7fbedd88e764275" deposit_root: "0x1e2891528f3695be75c16e6f8e948737a6be58ec77667c41f70309fe2d0a0c24" deposit_count: 474 execution_block_hash: "0x05b249730f2706e2825a6c3beb0582bc9430679dae5fa24c864a246efcb97eee" execution_block_height: 475 - deposit_data: pubkey: "0x8416902c51bdb3933ff4e87558121d3fbab9f116f9a5b0ae9cc30c4d145c39dc988f5c0b754da3daeec71fa68144f9b3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9402807f43da37ca29cede163b91633fde7614843314b423db475c86533e0006cf6b1e80a93dc04aedb919afdd9103b617e136915062a66211720207f6b1300da29a44c751251ed097a204b44780275514318e4cf73ad1971b10eebdb3a08aeb" deposit_data_root: "0x3ecd4d4c9a0d1810d3599f12fa62a3085f96dec792ed006f37bc2e2a20d5e90c" eth1_data: deposit_root: "0x04f3ebd098dd6485ad2ad107913118691ce85da75625af5e6fb730e536d298f9" deposit_count: "475" block_hash: "0xb63ee91d3c3edb9a298101f2c5c15a0dcc5fe27f0b564a620e944e7619845b1a" block_height: 476 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" - "0xff8e34dd64f1d9e20b42622f7dd59ce1f29ae93f52847609c7fbedd88e764275" - "0x3ecd4d4c9a0d1810d3599f12fa62a3085f96dec792ed006f37bc2e2a20d5e90c" deposit_root: "0x04f3ebd098dd6485ad2ad107913118691ce85da75625af5e6fb730e536d298f9" deposit_count: 475 execution_block_hash: "0xb63ee91d3c3edb9a298101f2c5c15a0dcc5fe27f0b564a620e944e7619845b1a" execution_block_height: 476 - deposit_data: pubkey: "0x83f8eb02f40f6369cb8836d521390b06ba91c72618056cd103ede2b6204069ff94c7364c2f24ca1db500ef627be3f1b2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8d236cee7ae8ac4a4b3bc5d71e8f1ef916dac52c731bd0992c3fab191cf2aba1e56bd69b708278715248e63d8f8b8724174c05b8ec955faf684b353c7c29c0e2bbc8b045c62c2554c3d5679e932e7ea6415999140f48860c3977c7149d5565b5" deposit_data_root: "0xc157aa44092165b3935d971c9835801dc66b24f54c8d4c387afcc14e2b469204" eth1_data: deposit_root: "0xe7fcb3f12d9fd24d0ebd089fad35d0a4edd4dca4fad112f72a5a42bf313e54fb" deposit_count: "476" block_hash: "0x546c6d2e65b628e3015ee8c2d0494a9a20cc098ce586d738f6de069136472497" block_height: 477 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" - "0xb99e45a812c5eaffd1f6ccb925e913d782b51cd8c371b11727ad48cc0de95d33" deposit_root: "0xe7fcb3f12d9fd24d0ebd089fad35d0a4edd4dca4fad112f72a5a42bf313e54fb" deposit_count: 476 execution_block_hash: "0x546c6d2e65b628e3015ee8c2d0494a9a20cc098ce586d738f6de069136472497" execution_block_height: 477 - deposit_data: pubkey: "0xb08c6eef8be13656c3963726dc3be95a5087e363fd5e72301322ea73a8840520d51f142cd9d94d0da3b7a6f22d111fd4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x974be67dd9641425535b8630a502c72298b86a579adb8f22d77474d3679ec0d3771190515ffea3cea288c5a401f275aa1951f6a3f226f9d0afd58a12520a51479a4ff168d782162ac242169580463e1e6968609fe0e911fdfe39192c816a3a03" deposit_data_root: "0xbafe7c7e5e984655b91e5c85b2a7064664c21483721e8d534bc04ce8c1849a1f" eth1_data: deposit_root: "0xf41c3d61184e6a446360ecb29eada4910b0694a5f26a281fcc7c07abb81f2f04" deposit_count: "477" block_hash: "0xbdb7e08ed1e7f61ee28337d7842866c1b545937e7c247d895e8ba87ac1b87cc2" block_height: 478 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" - "0xb99e45a812c5eaffd1f6ccb925e913d782b51cd8c371b11727ad48cc0de95d33" - "0xbafe7c7e5e984655b91e5c85b2a7064664c21483721e8d534bc04ce8c1849a1f" deposit_root: "0xf41c3d61184e6a446360ecb29eada4910b0694a5f26a281fcc7c07abb81f2f04" deposit_count: 477 execution_block_hash: "0xbdb7e08ed1e7f61ee28337d7842866c1b545937e7c247d895e8ba87ac1b87cc2" execution_block_height: 478 - deposit_data: pubkey: "0x8374c6a0d41b2da67f26a62120128838ab64f3928769a4280d0650ff18d6262b584e8f68a915bf8e4d1f6e18d72a6ecd" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2d63f5fd222d3c4db2c0f7bf4875d7a98cbd9511a43cc448df75d682984ed16035d3a9ea512c8da123d78400a29751910aeb767cf9361e2af7d50f4680796c3fc7a499028508c1de8093f6c4a9faa2d2e8737e39e90efc7b7f6304c79e471a9" deposit_data_root: "0x646da1db4ebfa44f98a74e708b6834ef0b3547d3ed62f4aa5ea28922b9ceb10f" eth1_data: deposit_root: "0xbbae20cfeb909f6a6c3efb0bdbf43a91e0111ac12305726d7c6ff78f0337edeb" deposit_count: "478" block_hash: "0xdad4caa2c941c49d2f6f9f8dba86a411d4cad65a2a89c6a12d017f08ba5bd381" block_height: 479 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" - "0xb99e45a812c5eaffd1f6ccb925e913d782b51cd8c371b11727ad48cc0de95d33" - "0xe4c5f8b27ed915c009a548dee4da3ba212b3c42979ac7fa6c80abfe02d1172dd" deposit_root: "0xbbae20cfeb909f6a6c3efb0bdbf43a91e0111ac12305726d7c6ff78f0337edeb" deposit_count: 478 execution_block_hash: "0xdad4caa2c941c49d2f6f9f8dba86a411d4cad65a2a89c6a12d017f08ba5bd381" execution_block_height: 479 - deposit_data: pubkey: "0xb98aeef39fb7eecc46e6cff2632a543757a8bd80bebe409b5d0eafe2922583040749cee9f130cf12eebf85c1dfc0adb4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x85fb8f084baed303cafc16887d1fd22b1ae16cf9a6978a9bdbea426975b183896a1ea8731b3ad9a61e0211519123cda50cbf3814f821938b9365ab4058228162aa1448881c64f410e15f09de147be4076ab418319748f97c09a57e18f3117370" deposit_data_root: "0xa196eee94becd475763319784c5f9a7ba0854e82893a0d9cf21d4952e08dddab" eth1_data: deposit_root: "0xb491c8ebe5be3cf6e59268e03ebc32a74e64efce2c805e1b328d3d2d8034af48" deposit_count: "479" block_hash: "0x56ca5f2c24ea7f40984bc5b6c97b289b23e33c6199d917b0dff9fa2e12607b60" block_height: 480 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x539c3abb99dc0d3652e3032b3abdd4f5d531d3783ac3c97c10e77108952d53fc" - "0x399784c504476260102e50dbb4284f4f83d3acc78686434e89711b29ffb00b2b" - "0xb99e45a812c5eaffd1f6ccb925e913d782b51cd8c371b11727ad48cc0de95d33" - "0xe4c5f8b27ed915c009a548dee4da3ba212b3c42979ac7fa6c80abfe02d1172dd" - "0xa196eee94becd475763319784c5f9a7ba0854e82893a0d9cf21d4952e08dddab" deposit_root: "0xb491c8ebe5be3cf6e59268e03ebc32a74e64efce2c805e1b328d3d2d8034af48" deposit_count: 479 execution_block_hash: "0x56ca5f2c24ea7f40984bc5b6c97b289b23e33c6199d917b0dff9fa2e12607b60" execution_block_height: 480 - deposit_data: pubkey: "0x8f9e00f60b9b830e72b7d0b45a3dab2cda1f678880db3b5dc5107e07850dc5146afe8b0999102d4a8bca5cbc27cd8a2c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x967c3931f641a1b00bf1d2f1f05b0d39470d3a18009ac4069f5b69f8c3d90129c10d5b0cf81fde69ae27470a47834d3a0946c9d6edbfbb3386910d3e881a34dd9b58ee1c51b34bf3c60920c52d449adcd850fe9a3e662e449cf50e02ef80eeb0" deposit_data_root: "0x1d584d8969a792467db268a84b71823f5421782407a24814519c5480593bdf72" eth1_data: deposit_root: "0x134da8281281e224a0ffb96b845d7792e22fcedd065ef136210928ec2804fc8b" deposit_count: "480" block_hash: "0x0c9865641090c264e1d7cbc1b65b0faf1005121540dc51869caba029aec61f22" block_height: 481 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" deposit_root: "0x134da8281281e224a0ffb96b845d7792e22fcedd065ef136210928ec2804fc8b" deposit_count: 480 execution_block_hash: "0x0c9865641090c264e1d7cbc1b65b0faf1005121540dc51869caba029aec61f22" execution_block_height: 481 - deposit_data: pubkey: "0xb42800735102f10b3e09c11e9113e0f4955bd19d0c5174f587d446de44230b10c3e8b439fbfc2e47f9e82ac2ade917b3" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa26895838394e4ead46ee443e6e76d42af792263bdf42113c206e99cde1d5ec5784f2a072691e1bfa9e29664741c3944009fdad153287feb4c172dde4ac6b63825c4211f2c09c0ca619f8c83b2c82a618aadfc27058df67685c437033cb23e1b" deposit_data_root: "0xc2a1be8de10512de15ce813468cadd14fec5f4dcff841434ef8ac94b0d4a1e8c" eth1_data: deposit_root: "0xd45d33b559eb5e75ad5e92d049659ab27a2c036a7aa315ec40fbcf807a8b78a2" deposit_count: "481" block_hash: "0x8c9122b92253122ed84adea540862612634d94e7c00df5df311278d785176f1f" block_height: 482 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xc2a1be8de10512de15ce813468cadd14fec5f4dcff841434ef8ac94b0d4a1e8c" deposit_root: "0xd45d33b559eb5e75ad5e92d049659ab27a2c036a7aa315ec40fbcf807a8b78a2" deposit_count: 481 execution_block_hash: "0x8c9122b92253122ed84adea540862612634d94e7c00df5df311278d785176f1f" execution_block_height: 482 - deposit_data: pubkey: "0x877968c73d43465feea583c7bde8270773fbcdcf9d1e3e4fe492a208e788bb56b329174b0d2539d96877e9d6f5bf1b41" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x83a31f50234740124160bb83287570c689c12df4415aa7d784fee273425568f566481089d6b910c6477cd982601d9b381333fa40c666da37750771f365a4998d6f2e1c5eb8412df44a7d4038b5528b3a624cc0af754e79e6e310e8669cef79f9" deposit_data_root: "0x5796c508baf67aa0316bd134dfd20381d7ccaa37735914bf83f122dd762e5ca2" eth1_data: deposit_root: "0x9d0ac2b2a873b08b17e722eb0893f30e4518ad523ee623d0567aa82dabc6dd32" deposit_count: "482" block_hash: "0xfde6c5dfbc17f3071be1020ace406b179a5e30640bc33c304b8e8264719aedd7" block_height: 483 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xdd4de29f488ddda22d81e4e7a3e890a1c2fa2f4602bf5612e8af70c852b459cc" deposit_root: "0x9d0ac2b2a873b08b17e722eb0893f30e4518ad523ee623d0567aa82dabc6dd32" deposit_count: 482 execution_block_hash: "0xfde6c5dfbc17f3071be1020ace406b179a5e30640bc33c304b8e8264719aedd7" execution_block_height: 483 - deposit_data: pubkey: "0x915fdf1928be84527b07ceccbc4a278f1e9e010d6f716d8c3a4666bf649411744355ef25b22276c2ab51b3af29c67119" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa3624f6211be2fcca00aeacae32fbc4101e787724ccd33d7293053b35ac8364784da5202037343024f4c94c86ce0a0ba171efaa129810f463e6f1337e59bea4aee8da537b313ccf72d207859d51bc2bec6c585e2598747b0b7e9f824ffb9f75b" deposit_data_root: "0x823ace95fa80327a404d8bc47116e2f39db4807f1547044d2f855459a6910f88" eth1_data: deposit_root: "0x34065c8a5baf250ed894b10d34c0b32b892d3457967219896e660caab4900265" deposit_count: "483" block_hash: "0x15dafdb4863cb94e4f40272996afd55a2772e370e89b8a75114fbd6706099b96" block_height: 484 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xdd4de29f488ddda22d81e4e7a3e890a1c2fa2f4602bf5612e8af70c852b459cc" - "0x823ace95fa80327a404d8bc47116e2f39db4807f1547044d2f855459a6910f88" deposit_root: "0x34065c8a5baf250ed894b10d34c0b32b892d3457967219896e660caab4900265" deposit_count: 483 execution_block_hash: "0x15dafdb4863cb94e4f40272996afd55a2772e370e89b8a75114fbd6706099b96" execution_block_height: 484 - deposit_data: pubkey: "0xa99b23673a9c02a8da9e44fda564aaacabc12fac43b600884e06ff21ca2ece8fb8ca28c593d3966ec6ff427f8f497c05" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa2e5bfd6972dc7e1224cd3a6cb8eb2120f88cb43912bbeac84e359e10ad2c707c6318c1a9edda7f10e0ec8a7c41af9e613fe59d07f50a3f5027e63c11b391ed425d1c6ab7ceea8681f310d34fe9b2c658c81472c30f89a6034d9f79ed5979b53" deposit_data_root: "0x726ba60cf4b669785203993565bb3b21592a22fdd92ed204db8774bd95854cf9" eth1_data: deposit_root: "0x5a94789da4c0fa8f904274e1a6be5fe01019d467234f560932302dc4480c9207" deposit_count: "484" block_hash: "0x5978eac6de2f57ef776f150ff7337be8d7323810da27f674804c0e2c34322109" block_height: 485 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xf8fc1b0c4abcf5d5c5214689c52a6c792ebb882fa93e6cdd79998c5bd752a4e1" deposit_root: "0x5a94789da4c0fa8f904274e1a6be5fe01019d467234f560932302dc4480c9207" deposit_count: 484 execution_block_hash: "0x5978eac6de2f57ef776f150ff7337be8d7323810da27f674804c0e2c34322109" execution_block_height: 485 - deposit_data: pubkey: "0x8759613fcfec38cf67297fc0b956382eb403f1b9126d1de3a26e0ee7142346d5457f09c7765d82d49f51726293b3cf7e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9924c8222eea8672b5aa21d38fca95cdaecadda51e373cd60100f1084e96140d333d2b01f60308bc8ca3ece43f1f915311b478bdefe9302188d636d3321ab684530f32cd8fa62b2ca575e0d3ac6b163a1934dc5e702af08253dd68c61f039e4a" deposit_data_root: "0x9613b659ffe2c9842167aa76d78262e1b72c7815b2751f4e9abc40bdc833a793" eth1_data: deposit_root: "0x301a60c707ce54ecd68bf6ab842130f5687966e5e3d6802c98a93105b8fffa6c" deposit_count: "485" block_hash: "0x33d4c030649788458fa0fc39cb615cac9e8614791d012c471b8f2c45314a398b" block_height: 486 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xf8fc1b0c4abcf5d5c5214689c52a6c792ebb882fa93e6cdd79998c5bd752a4e1" - "0x9613b659ffe2c9842167aa76d78262e1b72c7815b2751f4e9abc40bdc833a793" deposit_root: "0x301a60c707ce54ecd68bf6ab842130f5687966e5e3d6802c98a93105b8fffa6c" deposit_count: 485 execution_block_hash: "0x33d4c030649788458fa0fc39cb615cac9e8614791d012c471b8f2c45314a398b" execution_block_height: 486 - deposit_data: pubkey: "0xa0ab65230a0c9a2e2ec267918366deaa93d80068b14e691de2dff126c604e755b72d0865099078870d6a3d47a2f56d14" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x943d8cdce9bb776c6713cc436e6fe6dd9d3d6f015d79153945078cb204f725192e2bb9c95505b813782265e00532110b10c9c6d08012ead8d3d3ac825dee975cf68caa47a6a83697fec5f753de0480a2c81ec6799f3b9fcee7b561bdf1cd27e6" deposit_data_root: "0x02b77bbb8e3d988f7daa40bb4179390f620f74e3f370ca75e40087e188cfb290" eth1_data: deposit_root: "0xda801f823b9de4864cb8fbac530776a3faf03d59b3a2dbc736799f843ff769c4" deposit_count: "486" block_hash: "0xf40b8bd6aca0d2df5d30673cb93799ab391c73417d9fcd66c0f36061950258d7" block_height: 487 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xf8fc1b0c4abcf5d5c5214689c52a6c792ebb882fa93e6cdd79998c5bd752a4e1" - "0xc40108b2f8489c8b37335014f19abcb82e4493969e2c8ec160e771f38a2ac79b" deposit_root: "0xda801f823b9de4864cb8fbac530776a3faf03d59b3a2dbc736799f843ff769c4" deposit_count: 486 execution_block_hash: "0xf40b8bd6aca0d2df5d30673cb93799ab391c73417d9fcd66c0f36061950258d7" execution_block_height: 487 - deposit_data: pubkey: "0xa76186ca2743b7149ab7b5ab83c843d2d724ed85ef13a9e0e23a697ba048cea17acc68d9dda73d1f4ef97b9747e491ec" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xae8ce2cf4550895297567df5bbe471d3c58caec5fdfb1b526f4f686c0d908b32e3c88e0905344ce7d6c5ccf7d24ac2820da54a60ef97d5ad62f3de61b3f3b5252294b280efb80f24c50c2c9b1e0775b8e263170b373b876051e34e2e8bb14a0d" deposit_data_root: "0x992ec5657a0236c36cdeb5c71669678c8d28314815f3f267ee7791968f93ee5a" eth1_data: deposit_root: "0x178c069965cd1da6422db237305cb7d972195a3320cb2e863a3e36aa0d7a29e6" deposit_count: "487" block_hash: "0xfbc23345cce8edc158f0ca53ecd03de7f09bc65f648cce073dff8588a7195f0a" block_height: 488 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xf8fc1b0c4abcf5d5c5214689c52a6c792ebb882fa93e6cdd79998c5bd752a4e1" - "0xc40108b2f8489c8b37335014f19abcb82e4493969e2c8ec160e771f38a2ac79b" - "0x992ec5657a0236c36cdeb5c71669678c8d28314815f3f267ee7791968f93ee5a" deposit_root: "0x178c069965cd1da6422db237305cb7d972195a3320cb2e863a3e36aa0d7a29e6" deposit_count: 487 execution_block_hash: "0xfbc23345cce8edc158f0ca53ecd03de7f09bc65f648cce073dff8588a7195f0a" execution_block_height: 488 - deposit_data: pubkey: "0xa70362ba9834a49f9f1ffdccf221fc2eb1f7a5cb584bded1d79c44e7e7890ab28d787004c5cc6a45d0e941ae27f1fe39" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9840593dfd806431b6892e7c3026ea49084c25df871ba5dc8c9a28d5b2f8c9bd5379233c68d4af650f4409c6c5d814dd1337059655b61267c924f0f271eb7284702eff667a9ee4ac2994fef2a8c601d32a3ab39406f31c55976b824e5569f2c0" deposit_data_root: "0xd5b2e76b1095e39dc9cd525aab3f0ad77b8e3210c9950cffd3247cca2c2d93d9" eth1_data: deposit_root: "0xacc5e8c62a70a8b48ea72c2b7dcf7e81d33b98d0e7299f96830c4c9a87bc5b12" deposit_count: "488" block_hash: "0xe7952006db942a66abc5319d9ce249354eada481eee6cdaf97fe348f928dbd3e" block_height: 489 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" deposit_root: "0xacc5e8c62a70a8b48ea72c2b7dcf7e81d33b98d0e7299f96830c4c9a87bc5b12" deposit_count: 488 execution_block_hash: "0xe7952006db942a66abc5319d9ce249354eada481eee6cdaf97fe348f928dbd3e" execution_block_height: 489 - deposit_data: pubkey: "0xac66effd5784f677ff6fa5cb96d9cf14552d5888a8cd78ff54581b9fb35d3980c9b34cab41f565288812d77e3a44cceb" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb7d4c0669a88e0f84cfc9c5d53bf41d7703bed37597ccc66902f8d8271e7a595b2f170c13072e25c9630384a5a9070cc18a783226667704a6858fff0e77ff24dba0df19aa8ad71056fd18598dce161e4d547c3f29190803204de160e859af69d" deposit_data_root: "0x952612c181f310ef8c2b53d2022d08549f4d21d9d0d603d44b2bd3809e5b333b" eth1_data: deposit_root: "0xaee05275977d88ab3de85c1ef629864f36fa9ad8bc59500eb34e56ebfb724130" deposit_count: "489" block_hash: "0xbb1f6f7c565f47fa6e524ee0901d2b8b7a402895f4ccb7ee210723d757715869" block_height: 490 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" - "0x952612c181f310ef8c2b53d2022d08549f4d21d9d0d603d44b2bd3809e5b333b" deposit_root: "0xaee05275977d88ab3de85c1ef629864f36fa9ad8bc59500eb34e56ebfb724130" deposit_count: 489 execution_block_hash: "0xbb1f6f7c565f47fa6e524ee0901d2b8b7a402895f4ccb7ee210723d757715869" execution_block_height: 490 - deposit_data: pubkey: "0x933146088cae286d7d0c2759fab13c1f3e7cea13c05504c006e2ac25f322a779905fe4466f0db965620767d6270ac324" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa8a74b8afa78efaabefa3316ed4fb2715e2be3c0bc70b3df6b04c13f8d19ffe08df3558a083a1b34ceb06fb44c437cc9189378d8a785f2a3ac68606189d06f3787944c2b28f249bbd0755ffc2772f523a5cc2502a89f52be0d225c7330d9f478" deposit_data_root: "0xbc62013d7afb2e7f7c9c306c73449cef0f5b76e80568d3efe50744b3586c3c6a" eth1_data: deposit_root: "0x41dcb927c029b48451acb6f81bb177f21ec50556bce33f91939011f29fc834fd" deposit_count: "490" block_hash: "0x0af4b9127af4de48537331081e5d471983a3787901800be316b3060496e718dc" block_height: 491 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" - "0xc2117c26af280c0c49598e0448112e04588ab6a3ee01b2be0a1380ccd6ab884a" deposit_root: "0x41dcb927c029b48451acb6f81bb177f21ec50556bce33f91939011f29fc834fd" deposit_count: 490 execution_block_hash: "0x0af4b9127af4de48537331081e5d471983a3787901800be316b3060496e718dc" execution_block_height: 491 - deposit_data: pubkey: "0xb31a6cb5ab165f4b7b66bee6fcab77e410a3c7d7049ca5a6a7bc64b30a1c49bef4a1ed72454b87c8b879c00c57212ac2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8b9393ad8fe5132742cb3f2cfc722f9f80c98dfec7055a09fe4d9ee744c484d5ab234d1be89e8686ab6173096be867340b7d4c8ec2b76a4974a5e4f75664fcf6a82f95089fa8d284296a9e7608a88e8668974abfc58c0cc5552bdb0633449312" deposit_data_root: "0x38e2586880e59ae2b10e79b4bbea1bbf4fff9eb24c0e76e9eeff1117ecf7e326" eth1_data: deposit_root: "0xdc6d5c39bd67371b5a38d2baa1180139c09dd6e762ed5274586d6fae140aef33" deposit_count: "491" block_hash: "0x10a29b7a13bbba866147b26e86cb01908d83599a1dd6734fc5cbab0c8d5c2761" block_height: 492 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" - "0xc2117c26af280c0c49598e0448112e04588ab6a3ee01b2be0a1380ccd6ab884a" - "0x38e2586880e59ae2b10e79b4bbea1bbf4fff9eb24c0e76e9eeff1117ecf7e326" deposit_root: "0xdc6d5c39bd67371b5a38d2baa1180139c09dd6e762ed5274586d6fae140aef33" deposit_count: 491 execution_block_hash: "0x10a29b7a13bbba866147b26e86cb01908d83599a1dd6734fc5cbab0c8d5c2761" execution_block_height: 492 - deposit_data: pubkey: "0x9570f6171cbc78d58dd8afd84cc2f803ab049dcc15566b4c16406f798b65346f3bb36c45aff846e4604ab79ddba8125f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa93e273b50dbfbc9306d5dc86e49923e641166456f2930ebd3ca51ee1db9bc21bcfc27d90de43a76657c3f302456093b02adc0e553601ee8781f149c9c9e38021222db3614ac89f5789a9d0765bb94d03e0dc034b62a828317dd583d44a47efd" deposit_data_root: "0x52e9547d5df15475ad6635a94d60a382d8170a9e94db26e2948dfbc1838bba10" eth1_data: deposit_root: "0x22824f94535edf7e747a7ffe09ee5000d430a32a5eb63a223e6e888e558d6840" deposit_count: "492" block_hash: "0x24b8b1fb9de52367089b9098ba02dd01657c2da749dcefc4ff56f5c68c6852e7" block_height: 493 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" - "0x4f8311465fde082df60a4db44e53bcd965cf3a8f39d3166b2a769cf8a5cdc758" deposit_root: "0x22824f94535edf7e747a7ffe09ee5000d430a32a5eb63a223e6e888e558d6840" deposit_count: 492 execution_block_hash: "0x24b8b1fb9de52367089b9098ba02dd01657c2da749dcefc4ff56f5c68c6852e7" execution_block_height: 493 - deposit_data: pubkey: "0x871e9ef179706974e0423fb0a6f17673dd3d91ac9625a5c034d2797c396698489dff3c53abea15b7b5604919fd36acf6" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x84eb083fb8262d0a9d6c1ba20a5ceeee8d8b4fa4643cca03b6fd7b8affe3245c57a60294732b27b05adf0ca549bf0187040b38828218e89fa3905975e37a6d0f7c3664b271bda3a996f698fb081f98606c079016017e45388f4abfed55d5acb6" deposit_data_root: "0x366bca78131fd8260d4223c1c7c2c4fed8d22a5f43647b8bb5692ede92d255bc" eth1_data: deposit_root: "0xe5cac4e82791679b4044bfa3435209aa4b6388af630191371a7851eaa79b3529" deposit_count: "493" block_hash: "0xe4511513af4b15a09c1f2e1fd8ca52c6425803ef329133541130331d5ea134ba" block_height: 494 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" - "0x4f8311465fde082df60a4db44e53bcd965cf3a8f39d3166b2a769cf8a5cdc758" - "0x366bca78131fd8260d4223c1c7c2c4fed8d22a5f43647b8bb5692ede92d255bc" deposit_root: "0xe5cac4e82791679b4044bfa3435209aa4b6388af630191371a7851eaa79b3529" deposit_count: 493 execution_block_hash: "0xe4511513af4b15a09c1f2e1fd8ca52c6425803ef329133541130331d5ea134ba" execution_block_height: 494 - deposit_data: pubkey: "0x879391eff950beb2720f83aa628e43b313ec26e20cad9b75457bd8de5b1883fad8c5f28533ebebac4e377d82145d75da" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8a31291a8934809c33b88d68754d8abc0c6740474264c475d2e825f550b79cc4ba4d767f152afd628eb956ab0198014e18c365a66d4e9c6d5c92c8879791a41a9940304a419fabedb6d64d58706083e94afbca69c35718e6dbc8e97ead3ce50e" deposit_data_root: "0xa2d9df9463cd8a99c0caa53d39a2b5339149c329935288339b2dffda66babd34" eth1_data: deposit_root: "0x137fab1083cfe288afb0dc871b75b475b1cab3d6989cea5ec1ddc30588bcf9f3" deposit_count: "494" block_hash: "0xf5faca75aad4bc3195af3ce6e8cc953c804344697267f9621dc4d3d18d919ad4" block_height: 495 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" - "0x4f8311465fde082df60a4db44e53bcd965cf3a8f39d3166b2a769cf8a5cdc758" - "0xa3645b2bae71b310416e701a535d888cc14e78d867e2e88703a09b93af06de0d" deposit_root: "0x137fab1083cfe288afb0dc871b75b475b1cab3d6989cea5ec1ddc30588bcf9f3" deposit_count: 494 execution_block_hash: "0xf5faca75aad4bc3195af3ce6e8cc953c804344697267f9621dc4d3d18d919ad4" execution_block_height: 495 - deposit_data: pubkey: "0xb03bdf830d2cf1c1d8f0bb100fb3d4d399b48ca2e67e8f8513809bdf49beeb4b710438d64bdd9f4d4aebc3cc844e9302" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb81d217f78655216903e2c617be8cc10455b5f58335f522a91c35329693d5af7e906e490edd919f63d74c27b142570bf1407f26517a16835c18f6032683939359fa721e3f9ed56b8a38aec6aa36d4fa344e80a0cf16f0c990bba0d4e1d9758bc" deposit_data_root: "0xd4872c8e2cd8f5fe969e07d8c702201df480500077039ef03baa524e4eecb5d5" eth1_data: deposit_root: "0x89ee072c31cf8d3c38c359eae18f99047dad53e040e404ce65f758d8973dd831" deposit_count: "495" block_hash: "0x2a4557f04eda1cfab40813fbfaa9d0cd3297311d4c35f56aa325e83b44667b4f" block_height: 496 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0x3875f467344ea7151aaeaf8d2f3c78cf2dacd91f8a81b6ab8ca1e02df2fff953" - "0x4f8311465fde082df60a4db44e53bcd965cf3a8f39d3166b2a769cf8a5cdc758" - "0xa3645b2bae71b310416e701a535d888cc14e78d867e2e88703a09b93af06de0d" - "0xd4872c8e2cd8f5fe969e07d8c702201df480500077039ef03baa524e4eecb5d5" deposit_root: "0x89ee072c31cf8d3c38c359eae18f99047dad53e040e404ce65f758d8973dd831" deposit_count: 495 execution_block_hash: "0x2a4557f04eda1cfab40813fbfaa9d0cd3297311d4c35f56aa325e83b44667b4f" execution_block_height: 496 - deposit_data: pubkey: "0xadf6fceba8b405cb2a0e853da1a8db38799eaf868a91294a297f0ba4601731a438f1f7a8b15c91cbc7b4f07734d74ac0" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9055a60776e60b558d5722e5f168b13f4ba31940ad146948423a771e4973081bc99b9247ad648af178b11d1331cadd83014504c0cc289afa2c399b983dca0a01c5a5c4b321fcd615b185f982e6663dbaadb0b9222681e841c452810421ce28c0" deposit_data_root: "0xb89408cff9700bea9c5070d4bcae6f0a4b5171f4232a341f5f6d259b15d51461" eth1_data: deposit_root: "0xed3c614ac36483433d060e8e8576cb18c7aaad8b5fa57c067869a892e83aff98" deposit_count: "496" block_hash: "0x15efa8aba9883de6c511364fc9949a2ce28fd1320914681c40cff4c7d03dd4e3" block_height: 497 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" deposit_root: "0xed3c614ac36483433d060e8e8576cb18c7aaad8b5fa57c067869a892e83aff98" deposit_count: 496 execution_block_hash: "0x15efa8aba9883de6c511364fc9949a2ce28fd1320914681c40cff4c7d03dd4e3" execution_block_height: 497 - deposit_data: pubkey: "0xa931ae0ef4447284cad9e27b334924088b87f489d1c1eb49883cd2f35e4cd445dfac88e564605b32d471b56b4d98a4cb" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x927f3ded1db0e263965b5dc1433649056672f337df5a66e46e23be11287c60fb5fb83cc1878af02f020a41a52a5524730965f98460e4ec8faa34cfa7f82f84f7847e163a97bde7fd6326048787a0e65e71eb49225d2e00ef180a46eacb5821d9" deposit_data_root: "0x8526ea94647b0af12f3cda3d20987c8914451a827b81da295d625c6621de481c" eth1_data: deposit_root: "0x421728e94bc65613888da789ec8a68a70a9396a248416cf46a2ade5debdf71c7" deposit_count: "497" block_hash: "0x01e5154c23dc0820fddb99b9d1c36c7564750cb38a39c18cf3b1f2f6db3d036c" block_height: 498 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0x8526ea94647b0af12f3cda3d20987c8914451a827b81da295d625c6621de481c" deposit_root: "0x421728e94bc65613888da789ec8a68a70a9396a248416cf46a2ade5debdf71c7" deposit_count: 497 execution_block_hash: "0x01e5154c23dc0820fddb99b9d1c36c7564750cb38a39c18cf3b1f2f6db3d036c" execution_block_height: 498 - deposit_data: pubkey: "0xb304ff0820279e94ad069248706d39bddb36cb1ef69e1031f2f0683c69b4e8fe5bee35a64a7d160f8f207253bf6a1080" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xad022d059131eaf12492893f3b4d531ef72f713a18b5965e2f24a30d759e997809ae16fa808210f38cab0f7b3a244a0419913fb6805654a9b0e02e426e47b2aa363b8bddcaaf36569383559214a5a79d8190f9a268a30532c3e42866e02ca21f" deposit_data_root: "0x46c229cd0c3e568093841a1e7d92c9bfa369d9dc633067c83aee89f0cd754c3e" eth1_data: deposit_root: "0xdb3a62269b0ddfe5139f62b8b90c661c1f7e5e36821357e1b6e7e3288d9ec2ab" deposit_count: "498" block_hash: "0xcdd347d62aa299215a836ce87a9f671d2cb8dd4541325c26dfc66b5c87cf937e" block_height: 499 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xf2b54cd30ee3995c110c2028f35d5a400cb8a1ce9600757c8bae0e426db572c9" deposit_root: "0xdb3a62269b0ddfe5139f62b8b90c661c1f7e5e36821357e1b6e7e3288d9ec2ab" deposit_count: 498 execution_block_hash: "0xcdd347d62aa299215a836ce87a9f671d2cb8dd4541325c26dfc66b5c87cf937e" execution_block_height: 499 - deposit_data: pubkey: "0xb51c0882970b04879282a60dcfda6577abd62328859c811ad190b4a77b824e4ef7dcfa544f7e76ad0d0c53372e9ba43f" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb67d9631d1380573c574fc1a57dfd7266a42318b253955bfc2fadb55af3eabdbb311950c219ae6ca5ea8e7a8967ba7a41519a96a7437c7fa24bdbe02ae13f7191308eacab1528639d0efd1b4d195006b63f862202175e8975fa5b7f86461f481" deposit_data_root: "0x5342789288be2a5531cb6f31633584200615948145d3542a266e2b8965edc64b" eth1_data: deposit_root: "0x54c8df95f9d2b54939012347e05c3214e517c55d8540807b1ad754619c5a971d" deposit_count: "499" block_hash: "0x0b9574a4021e274198282a737f25de33d496573581e0912393315b491ea15ef2" block_height: 500 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xf2b54cd30ee3995c110c2028f35d5a400cb8a1ce9600757c8bae0e426db572c9" - "0x5342789288be2a5531cb6f31633584200615948145d3542a266e2b8965edc64b" deposit_root: "0x54c8df95f9d2b54939012347e05c3214e517c55d8540807b1ad754619c5a971d" deposit_count: 499 execution_block_hash: "0x0b9574a4021e274198282a737f25de33d496573581e0912393315b491ea15ef2" execution_block_height: 500 - deposit_data: pubkey: "0xa24dd1ce8d1d5af40401a2c2d47027de989313ead893a646456eb4ea9d6e38cf8cd37f75e2dfa631beed89970848a39c" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x91637e293d8b865c76aa80ccaa42e10dce7e1002647423cefa8e67c740f755a5b7b833a7b201e54a4d1a0a563963716412cb466eadd67b17d67c922d34f9f6e3c9ec1ad09434685cd0c7c3e1008ec84f4db02c3054023cea1d7716739129a3fe" deposit_data_root: "0x721297ec667e7bfec80ee3780c2a99c345a4a4de112c6c18acf2b2f7d9c01539" eth1_data: deposit_root: "0x695c65690f919bc3d1a81d29b03fbe3799754db34e73dd334d614198f58e7f78" deposit_count: "500" block_hash: "0x525ada6ebdc963f5b0cb396229e629557816abb142eb8e8161d5cfc5b7d2432d" block_height: 501 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xf71b0bf2bd3427f729de49cbe1f7cad35e2e80960e2f4a865c936f4197f74327" deposit_root: "0x695c65690f919bc3d1a81d29b03fbe3799754db34e73dd334d614198f58e7f78" deposit_count: 500 execution_block_hash: "0x525ada6ebdc963f5b0cb396229e629557816abb142eb8e8161d5cfc5b7d2432d" execution_block_height: 501 - deposit_data: pubkey: "0x943c88ab60e1b649772ebefea93e27bdc89bae1901cb8f181fb813a753861bf7e3c460b909566f30be2ad7ecc7e345aa" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb6cbee3d623fcd4a2bdf4b372ac8a54bea60d3b9a3c1079336a2250f6584b0bb0f5ff6fe074211a733ba8c0bd52d102e0ead892d2c8c7258d80048f03717498493cba834a30c966fff67b205ad6ac3a1ede20f3c9ed50305f07d3f2ac89863af" deposit_data_root: "0x563286c1b77c9e1d183fb518d9f263071cb48a8069db366a6aeca6bd4ec35842" eth1_data: deposit_root: "0xb11904549318b9f97731d696ceaf2a039e35e5b779234026e50f7e8a678bbdb9" deposit_count: "501" block_hash: "0xa936f16a1d89a846f3001253b571b6ca0f0aba7e546382dee4a0dbcc7a63c63a" block_height: 502 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xf71b0bf2bd3427f729de49cbe1f7cad35e2e80960e2f4a865c936f4197f74327" - "0x563286c1b77c9e1d183fb518d9f263071cb48a8069db366a6aeca6bd4ec35842" deposit_root: "0xb11904549318b9f97731d696ceaf2a039e35e5b779234026e50f7e8a678bbdb9" deposit_count: 501 execution_block_hash: "0xa936f16a1d89a846f3001253b571b6ca0f0aba7e546382dee4a0dbcc7a63c63a" execution_block_height: 502 - deposit_data: pubkey: "0xa2eea192ab4a2213efc58879ce008f8684c3b8da24d7a0124ed33c6ee9d3d12adcac702a938e2ccad79fde467fa413c4" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa25236c672bf2eb19b4a8a9da4564a35e2f3c8545f4190ce5916009f0957a28784622d6840a806f29df5a27e99d58057014595ab84d62f0d8edb67e4fa91504f68b906f9a975bb62da0714929fb0cb1262345bca6e2b71d0db4bc5d7f353397d" deposit_data_root: "0x3691a26d2ceb9f3a6417d2c53d9ed3fd5cc2fbcc1211d78ed5d2e21d7930ac17" eth1_data: deposit_root: "0x601b2c94d23ab5858f4eacb14fda5eeb7408d13582a6afdb24b8fc91f1ade8a1" deposit_count: "502" block_hash: "0x040c9bd5cc7316ee54b15126e380a8795a352165ba3eea6328e65389101541bb" block_height: 503 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xf71b0bf2bd3427f729de49cbe1f7cad35e2e80960e2f4a865c936f4197f74327" - "0xa3d1c3c7ccbc27ed4d1edd2579de324b7a53144a936ee798b133252cb1eb8466" deposit_root: "0x601b2c94d23ab5858f4eacb14fda5eeb7408d13582a6afdb24b8fc91f1ade8a1" deposit_count: 502 execution_block_hash: "0x040c9bd5cc7316ee54b15126e380a8795a352165ba3eea6328e65389101541bb" execution_block_height: 503 - deposit_data: pubkey: "0xa1792fc5047546bc98391908b80fc9b4a790018b580836cfa593426624ab1785d11449a03c93759f34645d277e9f26ee" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xaa2521a398340e4fa390e4335a1cb3fe7e840ad6da4dec4c03332250ebd2d43fb6b7a968c6c06e50389fd654b08c338a143b1ccd26fb428a0b6df28d07d294d87cb214f7be07a59cf4f5326a17b801b9d1c37e8e44930420639784b5ee777cb8" deposit_data_root: "0x4bec8c542e2bfb99d7e4703013705c2c3192f21335f1ea00d5267e869640c31c" eth1_data: deposit_root: "0x3f0fbcbb62eb78578683087a8869a260b30b001bb6afdb53246538c61e686b6f" deposit_count: "503" block_hash: "0x5c8134c7e7bb2f1bc0781ddc9b331afd5be19587aaac6c911a617f8cdb9a6204" block_height: 504 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xf71b0bf2bd3427f729de49cbe1f7cad35e2e80960e2f4a865c936f4197f74327" - "0xa3d1c3c7ccbc27ed4d1edd2579de324b7a53144a936ee798b133252cb1eb8466" - "0x4bec8c542e2bfb99d7e4703013705c2c3192f21335f1ea00d5267e869640c31c" deposit_root: "0x3f0fbcbb62eb78578683087a8869a260b30b001bb6afdb53246538c61e686b6f" deposit_count: 503 execution_block_hash: "0x5c8134c7e7bb2f1bc0781ddc9b331afd5be19587aaac6c911a617f8cdb9a6204" execution_block_height: 504 - deposit_data: pubkey: "0xb2f64f70753f79fc04398f220f2ee1a54d14c8bd31c1b27105aae559d5006434135e516e975f57c7a41241ac74ab6aaa" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa17e776cdecb5f4c33b2a84cd37b12bb2bba06fc0e95ec255a0722ef32b2b273d2dd47001574d9ac254c7451be09614702d2761cada37688adb3babade14bbaf03a480f771ce1bc52824f73518dc1dea9786d1dfd34407fa83974ad8c79c5849" deposit_data_root: "0xd4b6855d328858c320b36bbffda4a196e410d8ddf105c387c8ed7d3781853ab3" eth1_data: deposit_root: "0xd656f74b083d9e27e3d9a38247dc8ef3a48fa128173e054d6e8cc476a07a5dc0" deposit_count: "504" block_hash: "0xfd8f2f9a3cbc74fc6def66bcf7362ab06ffaa26414ec2be744954381e6e6c8e9" block_height: 505 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" deposit_root: "0xd656f74b083d9e27e3d9a38247dc8ef3a48fa128173e054d6e8cc476a07a5dc0" deposit_count: 504 execution_block_hash: "0xfd8f2f9a3cbc74fc6def66bcf7362ab06ffaa26414ec2be744954381e6e6c8e9" execution_block_height: 505 - deposit_data: pubkey: "0x86195e4462e04f6e0f4c2545ecc9c0fa812f1ffd6cde31bef2f59c5806d839937d60bd8180c2362555f73aadf6591965" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x834363e5f9c86333ab75a6a75f31324e5789d3fa705a4cb13c86a8045c27b9a37e8648ce6b0bf3f1d1c57007e40b54d80a3cc975baff2463345a3c438668f70ba5fa4cf906f7a23687eddb0b2c46a2957ecc1d3867ff5c2462c7448112089311" deposit_data_root: "0xfa190fba4e1bf49150b7c76cfd7d07f269d46fe04f08995bb7473345b2bb4499" eth1_data: deposit_root: "0x723a02ae297d5787bbc4a3a1b30783fcd486c0ccd9428873c237d78d97ecdf2b" deposit_count: "505" block_hash: "0xd31b757dc9ab9e121243a12efd22177616a1a0327335121b63f0d91f175b3344" block_height: 506 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" - "0xfa190fba4e1bf49150b7c76cfd7d07f269d46fe04f08995bb7473345b2bb4499" deposit_root: "0x723a02ae297d5787bbc4a3a1b30783fcd486c0ccd9428873c237d78d97ecdf2b" deposit_count: 505 execution_block_hash: "0xd31b757dc9ab9e121243a12efd22177616a1a0327335121b63f0d91f175b3344" execution_block_height: 506 - deposit_data: pubkey: "0x8a6d7746a13800bc06e455dc52786c35065e2b08054ab8e569e28391dbef3d2527eea72aa60e1b53a54dc477055bccf2" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x96725d9c529a3bec9780a7d693e589c2e1b8e2d328d21e52a9ade535810501c0f2f9e45022564b3e8c9c371d9cfada1e03098990f36a9a2e6defd299ce06e9ff8f90a683a2a4bc0083bb2c424a4e3311f95cbd030962305808dfafd5967eb1ba" deposit_data_root: "0x998a3d35a682a46fde29ea288109b96a4b24a246a7d4b24f7572bcff109d6ade" eth1_data: deposit_root: "0xc748ed0905ebcfec8085a8c67091ac467642915c73dd758f432b5e8658a90044" deposit_count: "506" block_hash: "0x28b47914e0960b493976bc8ee4cc861fa19f640d6a3369df08b413c550540df9" block_height: 507 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" - "0x9e659e07ef110f0141fdce5a789ae1a54952cadb33028e879430eb600ef4d58a" deposit_root: "0xc748ed0905ebcfec8085a8c67091ac467642915c73dd758f432b5e8658a90044" deposit_count: 506 execution_block_hash: "0x28b47914e0960b493976bc8ee4cc861fa19f640d6a3369df08b413c550540df9" execution_block_height: 507 - deposit_data: pubkey: "0x961cc399896c8daecb0784f91943dd32077c9ad661f460f27f048ffc557010b4bd9a4a692306b6f70ff0f597fd31ecbe" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x9049a268bf99261658ce1087a0b7874a059b951c7a03bc56f46ab0474efefc1c245bbda655bd994d25576df5ce7ef3e30345a606af54bf4d171dc0dddcf6122f71ec286f57a543767b2869ff2f84df30e324a682011c250e52d2bda21eef798d" deposit_data_root: "0xc0107b388528dd8ec080388c8313dd88c9c6e6fc742a27081881a5209c084295" eth1_data: deposit_root: "0x0c016b6f117e5507d6e740412dda9f7e5cdd539650a8a424e7a06c836408078a" deposit_count: "507" block_hash: "0xf89a37f7162803e84f7ffbaf0f5ea73306993adfd524d7aa060d49316b96c607" block_height: 508 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" - "0x9e659e07ef110f0141fdce5a789ae1a54952cadb33028e879430eb600ef4d58a" - "0xc0107b388528dd8ec080388c8313dd88c9c6e6fc742a27081881a5209c084295" deposit_root: "0x0c016b6f117e5507d6e740412dda9f7e5cdd539650a8a424e7a06c836408078a" deposit_count: 507 execution_block_hash: "0xf89a37f7162803e84f7ffbaf0f5ea73306993adfd524d7aa060d49316b96c607" execution_block_height: 508 - deposit_data: pubkey: "0x8edb799cc0407cf8db901082d7fcd613b7dd4ea03caef14073841e54531bdcdf3f661d551edae045b960b506e70b8dc8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xa88cca9dc14b177d45e96da17be05c999f86f12db33ad5060b82e53f9a94949542bcec1ca0422d16de2439ee5fa1215615d16bd0e50ea1e3f9abcbe8096ca51837243a709a6fb02c9dfe443dc2e175af845465108d49132b0e94a3833e10080d" deposit_data_root: "0xdc384b4f094fc826477b19d9126ec7e2937fc95fb19397073f00e211e9dfc8b1" eth1_data: deposit_root: "0xf0ac44f68f2ebad7f114356cabeee522a8dfd5713da8a875d28630edbf2ba3d6" deposit_count: "508" block_hash: "0x14ce1569b047c9a4015e7ff6b15b90cf19bae216e88e578651af70927afc5425" block_height: 509 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" - "0x755680bc147f24f2b5988a005d2af577aaa2f9364a17d97436a7296698418aa3" deposit_root: "0xf0ac44f68f2ebad7f114356cabeee522a8dfd5713da8a875d28630edbf2ba3d6" deposit_count: 508 execution_block_hash: "0x14ce1569b047c9a4015e7ff6b15b90cf19bae216e88e578651af70927afc5425" execution_block_height: 509 - deposit_data: pubkey: "0x8eab84a4394a69ff45dad4a17d4a8ce3bb04948c68bc70abbdebdd76c2156507a319d5bf9cfcaf750fe3b4d5c66723ee" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x921e0672eee586061a353cb40a0586354fbcf92c7c94be47a0e35f58c183bac72959dac50d83cc6e826ae29540ae4924048bfa5adc5b6be5fc4df54816a41fc265f514e2393796c454e822baff3ecedfcff8c36ca56731df32ca9f868219db1a" deposit_data_root: "0x9538b1a35a2401f1ae3146672fb986168c4872d6ce0ff63f9fd8fcc590b81a05" eth1_data: deposit_root: "0x2be7501704a28527b0cde140e090ae14b1951facdd019b1bbdb5a53165663b90" deposit_count: "509" block_hash: "0xc092fd8e7712ceb3e8b1db31d939638233c0768396159d836fd8fae04a020db3" block_height: 510 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" - "0x755680bc147f24f2b5988a005d2af577aaa2f9364a17d97436a7296698418aa3" - "0x9538b1a35a2401f1ae3146672fb986168c4872d6ce0ff63f9fd8fcc590b81a05" deposit_root: "0x2be7501704a28527b0cde140e090ae14b1951facdd019b1bbdb5a53165663b90" deposit_count: 509 execution_block_hash: "0xc092fd8e7712ceb3e8b1db31d939638233c0768396159d836fd8fae04a020db3" execution_block_height: 510 - deposit_data: pubkey: "0xb4c37ed40d2d3d2ace8ba3e1d0bb1b0651d3d21c3dc5e8a4ef42513d649fc14d6dcd1ba7c8b893a2205f6afc870feb75" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x990065021cd5c4395a74ee4ef2bd3ae57e6a69afbb520c9af1793e2272ccf96252cb24cdc06f566d930939e709493e700610c5de71a888a01ae07f6e9eae7995e8c4a8e2ae2a0c9d19832ebd90dc3218857253a453f419681fe5974a56f5beee" deposit_data_root: "0x79922ab72714b5a5f07b6d4ad531260bdc3da6b2723f5a621a19f49d14f080d4" eth1_data: deposit_root: "0x904cf102790d85df5521caba1f278f99ed62a6b72fc1aa7a9c9731014b4b08c7" deposit_count: "510" block_hash: "0x59ecebf2c2f7d2de32d3de30320e7b278ca84c9ab21fecb0bc129a56eab60ef0" block_height: 511 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" - "0x755680bc147f24f2b5988a005d2af577aaa2f9364a17d97436a7296698418aa3" - "0x1ae3fbc472814f00a5434bbc76e084c37564a55fee67c206c9977c152b12c38e" deposit_root: "0x904cf102790d85df5521caba1f278f99ed62a6b72fc1aa7a9c9731014b4b08c7" deposit_count: 510 execution_block_hash: "0x59ecebf2c2f7d2de32d3de30320e7b278ca84c9ab21fecb0bc129a56eab60ef0" execution_block_height: 511 - deposit_data: pubkey: "0xb02b650ec8c8a75cdb3c8cc64b612c5180aa31e0345ce16b1d9d8e5c7ce28d4feb8ed6bab0be68c13a5acd71f326fab8" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0x8eb8590912f2736f59f2fc221f167f9806159c922a041d94e1cb7dbd1703e84d7ea54623ffd01aeefab48ded3accac940610dacc940565a4bdadbd586bb7ea7e95cd8a6439363963618fb3332ae2eb1a33fdde5a20871550188a5a21657b141b" deposit_data_root: "0xaa58eeff0a6439e85c0062387253ed726b0dcb040f1ad6f9e2dd2ea9ef6b0d41" eth1_data: deposit_root: "0xdf4c6590595af97badd52a23a3d2da9e1171340d3e9d299ea462b482822e3680" deposit_count: "511" block_hash: "0xc5db6286114149aacff6eaae584d859fbbcbb914cb3f111447844e76e7623822" block_height: 512 snapshot: finalized: - "0x1be35e1ed8992a8d55a57ee0a215ffa733e7e66282acfd151ad96e813963f4a1" - "0xce176f39f29e8b5f6cbd3d107bf8a2e6162266aef4ee4aa784e6c899474ca670" - "0xbfa916399e17a4550bfb5997c9b20433cc80c876ad0cf18df57493bce4dc8d29" - "0x61f220b3f77327db30183075bd0e691acebd9aa729ace9b85d6381f40bbabd15" - "0xbe91342b23cac4f3b516349701aa3357b170da8ebd6769691d1c633f0391b2be" - "0xe129a1eb08eea7dc270c6d43e68441450375894e2bb046328e0ce35a68faca31" - "0x755680bc147f24f2b5988a005d2af577aaa2f9364a17d97436a7296698418aa3" - "0x1ae3fbc472814f00a5434bbc76e084c37564a55fee67c206c9977c152b12c38e" - "0xaa58eeff0a6439e85c0062387253ed726b0dcb040f1ad6f9e2dd2ea9ef6b0d41" deposit_root: "0xdf4c6590595af97badd52a23a3d2da9e1171340d3e9d299ea462b482822e3680" deposit_count: 511 execution_block_hash: "0xc5db6286114149aacff6eaae584d859fbbcbb914cb3f111447844e76e7623822" execution_block_height: 512 - deposit_data: pubkey: "0x890bbabc36dc93557dffada73af2e71bd15481fb5345d7b4755498ddb1bd8733f0140cc40007c76ccc8764ba42678d1e" withdrawal_credentials: "0x0000000000000000000000000000000000000000000000000000000000000000" amount: "32000000000" signature: "0xb2e4b4c3d177fbeacd0a4cfbb4eb8504e380b2354b5ffac72705ff61fbea065af6793ec133971dcc7da8cef0fe3ff61d06ea05be4f1e2b88c29be2d769008a9a1385c156861553587913c0a0fe74fc3a2efdc90111a0a1fbc96f7c16234c0909" deposit_data_root: "0xa26a328f61bac695e879575ad50b38d5e643ff8df03bfd1cd7f55da6e64e9228" eth1_data: deposit_root: "0x556a4bfa525440a9e36ac1758db883caf80a0226ea195e91445e01621a67f875" deposit_count: "512" block_hash: "0x5d025ae62b16de0ebfc98e502cc0aa0e583efa4537d6c68273634ebbcb648749" block_height: 513 snapshot: finalized: - "0xff99e90235f5818855c9114be9ce29d0f028bcab5032cfbcf634609b211268b1" deposit_root: "0x556a4bfa525440a9e36ac1758db883caf80a0226ea195e91445e01621a67f875" deposit_count: 512 execution_block_hash: "0x5d025ae62b16de0ebfc98e502cc0aa0e583efa4537d6c68273634ebbcb648749" execution_block_height: 513 https://eips.ethereum.org/assets/eip-4881/test_cases.yaml https://eips.ethereum.org/assets/eip-4881/test_cases.yaml / @import "minima"; https://eips.ethereum.org/assets/main.css https://eips.ethereum.org/assets/main.css / Creative Commons Legal Code CC0 1.0 Universal CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER. Statement of Purpose The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work"). Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others. For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights. 1. Copyright and Related Rights. A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following: i. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work; ii. moral rights retained by the original author(s) and/or performer(s); iii. publicity and privacy rights pertaining to a person's image or likeness depicted in a Work; iv. rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below; v. rights protecting the extraction, dissemination, use and reuse of data in a Work; vi. database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and vii. other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof. 2. Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose. 3. Public License Fallback. Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose. 4. Limitations and Disclaimers. a. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document. b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law. c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work. d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work. https://eips.ethereum.org/LICENSE https://eips.ethereum.org/LICENSE Test Vectors for EIP-1057 - ProgPow / # Test Vectors for EIP-1057 - ProgPow Many of these vectors are derived from [chfast/ethash](https://github.com/chfast/ethash) ## fnv1a | `h` | `d` | _result_ | | -----------: | -----------: | -----------: | | `0X811C9DC5` | `0XDDD0A47B` | `0XD37EE61A` | | `0XD37EE61A` | `0XEE304846` | `0XDEDC7AD4` | | `0XDEDC7AD4` | `0X00000000` | `0XA9155BBC` | ## kiss99 For `z`=`362436069`, `w`=`521288629`, `jsr`=`123456789`, and `jcong`=`380116160` the result of each iterative call to `kiss99` is as follows: | _iteration_ | _result_ |kernel | ----------: | -----------: | | `1` | `769445856` | | `2` | `742012328` | | `3` | `2121196314` | | `4` | `2805620942` | | `100000` | `941074834` | ## fill_mix For `hash_seed`=`0xEE304846DDD0A47B` and `lane_id`=`0` the values stored in the `mix` array will be > ``` > 0x10C02F0D, 0x99891C9E, 0xC59649A0, 0x43F0394D, > 0x24D2BAE4, 0xC4E89D4C, 0x398AD25C, 0xF5C0E467, > 0x7A3302D6, 0xE6245C6C, 0x760726D3, 0x1F322EE7, > 0x85405811, 0xC2F1E765, 0xA0EB7045, 0xDA39E821, > 0x79FC6A48, 0x089E401F, 0x8488779F, 0xD79E414F, > 0x041A826B, 0x313C0D79, 0x10125A3C, 0x3F4BDFAC, > 0xA7352F36, 0x7E70CB54, 0x3B0BB37D, 0x74A3E24A, > 0xCC37236A, 0xA442B311, 0x955AB27A, 0x6D175B7E > ``` For the same hash and `lane_id`=`13` the value in the `mix` array will be > ``` > 0x4E46D05D, 0x2E77E734, 0x2C479399, 0x70712177, > 0xA75D7FF5, 0xBEF18D17, 0x8D42252E, 0x35B4FA0E, > 0x462C850A, 0x2DD2B5D5, 0x5F32B5EC, 0xED5D9EED, > 0xF9E2685E, 0x1F29DC8E, 0xA78F098B, 0x86A8687B, > 0xEA7A10E7, 0xBE732B9D, 0x4EEBCB60, 0x94DD7D97, > 0x39A425E9, 0xC0E782BF, 0xBA7B870F, 0x4823FF60, > 0xF97A5A1C, 0xB00BCAF4, 0x02D0F8C4, 0x28399214, > 0xB4CCB32D, 0x83A09132, 0x27EA8279, 0x3837DDA3 > ``` ## keccak_f800_progpow Test case 1: | | | | -------- | ----------------------------------------------------------------------------------------------------------------- | | header | `0xCCDDEEFF`, `0x8899AABB`, `0x44556677`, `0x00112233`,<br>`0x33221100`, `0x77665544`, `0xBBAA9988`, `0xFFEEDDCC` | | seed | `0x123456789ABCDEF0` | | digest | `0x00000000`, `0x00000000`, `0x00000000`, `0x00000000`,<br>`0x00000000`, `0x00000000`, `0x00000000`, `0x00000000` | | _result_ | `0x464830EE`, `0x7BA4D0DD`, `0x969E1798`, `0xCEC50EB6`,<br>`0x7872E2EA`, `0x597E3634`, `0xE380E73D`, `0x2F89D1E6` | Test case 2: | | | | -------- | ----------------------------------------------------------------------------------------------------------------- | | header | `0xCCDDEEFF`, `0x8899AABB`, `0x44556677`, `0x00112233`,<br>`0x33221100`, `0x77665544`, `0xBBAA9988`, `0xFFEEDDCC` | | seed | `0xEE304846DDD0A47B` | | digest | `0x0598F111`, `0x66B48AC5`, `0x719CFF10`, `0x5F0ACF9D`,<br>`0x162FFA18`, `0xEF8E7905`, `0x21470C77`, `0x7D767492` | | _result_ | `0x47CD7C5B`, `0xD9FDBE2D`, `0xAC5C895B`, `0xFF67CE8E`,<br>`0x6B5AEB0D`, `0xE1C6ECD2`, `0x003D3862`, `0xCE8E72C3` | ## progPowInit For ProgPow period 600 (block 30,000) the configurations should be src array: > `0x1A`, `0x1E`, `0x01`, `0x13`, `0x0B`, `0x15`, `0x0F`, `0x12`, > `0x03`, `0x11`, `0x1F`, `0x10`, `0x1C`, `0x04`, `0x16`, `0x17`, > `0x02`, `0x0D`, `0x1D`, `0x18`, `0x0A`, `0x0C`, `0x05`, `0x14`, > `0x07`, `0x08`, `0x0E`, `0x1B`, `0x06`, `0x19`, `0x09`, `0x00` dst array > `0x00`, `0x04`, `0x1B`, `0x1A`, `0x0D`, `0x0F`, `0x11`, `0x07`, > `0x0E`, `0x08`, `0x09`, `0x0C`, `0x03`, `0x0A`, `0x01`, `0x0B`, > `0x06`, `0x10`, `0x1C`, `0x1F`, `0x02`, `0x13`, `0x1E`, `0x16`, > `0x1D`, `0x05`, `0x18`, `0x12`, `0x19`, `0x17`, `0x15`, `0x14` Kiss 99 state: `z`=`0x6535921C` `w`=`0x29345B16`, `jsr`=`0xC0DD7F78`, `jcong`=`0x1165D7EB` ## merge | `a` | `b` | `r` | _result_ | _path exercised_ | | ------------ | ------------ | ------------ | ------------ | ---------------- | | `0x3B0BB37D` | `0xA0212004` | `0x9BD26AB0` | `0x3CA34321` | mul/add | | `0x10C02F0D` | `0x870FA227` | `0xD4F45515` | `0x91C1326A` | xor/mul | | `0x24D2BAE4` | `0x0FFB4C9B` | `0x7FDBC2F2` | `0x2EDDD94C` | rotl/xor | | `0xDA39E821` | `0x089C4008` | `0x8B6CD8C3` | `0x8A81E396` | rotr/xor | ## math | `a` | `b` | `r` | _result_ | _operation exercised_ | | ------------ | ------------ | ------------ | ------------ | ----------------------- | | `0x8626BB1F` | `0xBBDFBC4E` | `0x883E5B49` | `0x4206776D` | add | | `0x3F4BDFAC` | `0xD79E414F` | `0x36B71236` | `0x4C5CB214` | mul | | `0x6D175B7E` | `0xC4E89D4C` | `0x944ECABB` | `0x53E9023F` | mul_hi32 | | `0x2EDDD94C` | `0x7E70CB54` | `0x3F472A85` | `0x2EDDD94C` | min | | `0x61AE0E62` | `0xe0596b32` | `0x3F472A85` | `0x61AE0E62` | min again (unsigned) | | `0x8A81E396` | `0x3F4BDFAC` | `0xCEC46E67` | `0x1E3968A8` | rotl32 | | `0x8A81E396` | `0x7E70CB54` | `0xDBE71FF7` | `0x1E3968A8` | rotr32 | | `0xA7352F36` | `0xA0EB7045` | `0x59E7B9D8` | `0xA0212004` | bitwise and | | `0xC89805AF` | `0x64291E2F` | `0x1BDC84A9` | `0xECB91FAF` | bitwise or | | `0x760726D3` | `0x79FC6A48` | `0xC675CAC5` | `0x0FFB4C9B` | bitwise xor | | `0x75551D43` | `0x3383BA34` | `0x2863AD31` | `0x00000003` | clz (leading zeros) | | `0xEA260841` | `0xE92C44B7` | `0xF83FFE7D` | `0x0000001B` | popcount (number of 1s) | ## progPowLoop For the first loop iteration of block 30,000 the seed to use for `fill_mix` would be `0xEE304846DDD0A47B`. A two dimensional `mix` array should be created passing the rows into `fill_mix` with the column number as the loop argument. The state of the mix array after the call to `progPowLoop` for block 30,000, loop 1 are as follows. `mix[0]` - > ``` > 0x40E09E9C, 0x967A7DF0, 0x8626BB1F, 0x12C2392F, > 0xA21D8305, 0x44C2702E, 0x94C93945, 0x6B66B158, > 0x0CF00FAA, 0x26F5E6B5, 0x36EC0134, 0xC89805AF, > 0x58118540, 0x8617DC4D, 0xC759F486, 0x8A81E396, > 0x22443D4D, 0x64291E2F, 0x1998AB7F, 0x11C0FBBB, > 0xBEA9C139, 0x82D1E47E, 0x7ED3E850, 0x2F81531A, > 0xBBDFBC4E, 0xF58AEE4D, 0x3CA34321, 0x357BD48A, > 0x2F9C8B5D, 0x2319B193, 0x2856BB38, 0x2E3C33E6 > ``` `mix[1]` - > ``` > 0x4EB8A8F9, 0xD978BF17, 0x7D5074D4, 0x7A092D5D, > 0x8682D1BE, 0xC3D2941C, 0xF1A1A38B, 0x54BB6D34, > 0x2F0FB257, 0xB5464B50, 0x40927B67, 0xBB92A7E1, > 0x1305A517, 0xE06C6765, 0xA75FD647, 0x9F232D6E, > 0x0D9213ED, 0x8884671D, 0x54352B96, 0x6772E58E, > 0x1B8120C9, 0x179F3CFB, 0x116FFC82, 0x6D019BCE, > 0x1C26A750, 0x89716638, 0x02BEB948, 0x2E0AD5CE, > 0x7FA915B2, 0x93024F2F, 0x2F58032E, 0xF02E550C > ``` `mix[2]` - > ``` > 0x008FF9BD, 0xC41F9802, 0x2E36FDC8, 0x9FBA2A91, > 0x0A921670, 0x231308E6, 0xEF09A56E, 0x9657A64A, > 0xF67723FE, 0x963DCD40, 0x354CBFDB, 0x57C07B9A, > 0x06AF5B40, 0xBA5DE5A6, 0xDA5AAE7B, 0x9F8A5E4B, > 0x7D6AFC9A, 0xE4783F78, 0x89B24946, 0x5EE94228, > 0xA209DAAA, 0xDCC27C64, 0x3366FBED, 0x0FEFB673, > 0x0FC205E3, 0xB61515B2, 0x70A45E9B, 0xBB225E5D, > 0xB8C38EA0, 0xE01DE9B4, 0x866FAA5B, 0x1A125220 > ``` `mix[3]` - > ``` > 0xE5F9C5CC, 0x6F75CFA2, 0xE0F50924, 0xE7B4F5EF, > 0x779B903D, 0x5F068253, 0x05FF68E5, 0x39348653, > 0x654B89E4, 0x0559769E, 0xA3D46B93, 0xD084454D, > 0xCFC5CF7D, 0x8C11D8E4, 0x795BDB59, 0xD9E03113, > 0xBAE8C355, 0x12B63814, 0x4046A018, 0xA269A32E, > 0x54A57C4B, 0x2ED1065B, 0xB69A2C76, 0x4AEF0950, > 0x6C2D187B, 0x8252FAE7, 0x3E9C0ED2, 0x26E47B15, > 0xFEFB48E3, 0xDA088C7F, 0xA82B0379, 0xA49C6D86 > ``` `mix[4]` - > ``` > 0xB926334C, 0x686A29AF, 0xD9E2EF15, 0x1C8A2D39, > 0x307ED4F4, 0x2ABB1DB6, 0xD6F95128, 0xDFCA05F8, > 0x904D9472, 0xEC09E200, 0x7143F47F, 0xEE488438, > 0xFCA48DA8, 0xA64C7DD4, 0xC4AE9A30, 0xEBA30BC9, > 0xB02630BF, 0xD1DF40CC, 0x4DFE8B7B, 0x205C97B3, > 0xE40376F8, 0x2491117E, 0x34984321, 0xA01546A7, > 0xB254F2F9, 0xC78A7C25, 0xFFC615E2, 0x5839FC88, > 0x2A04DF6C, 0xC02A9A8A, 0x39238EAD, 0x7139060C > ``` `mix[5]` - > ``` > 0xC416E54B, 0x64AD1C57, 0xBF7CBA55, 0x176F714E, > 0xBE733426, 0x995C4132, 0x5F50F779, 0x0F76FDF3, > 0x526F7870, 0xE56A1A8A, 0xDCEB677E, 0xD471CC19, > 0xA9ED60E4, 0x145E807F, 0x8D652E92, 0x80E8116F, > 0xFF1A37EB, 0x1E0C49A1, 0x59D756DA, 0x39A8E761, > 0x2F0F646F, 0x43F41278, 0x88CC48DA, 0x8FDFF7A4, > 0x9AEACA2E, 0x59E7808C, 0x7F72E46B, 0xCA572333, > 0xC6029C88, 0x7736E592, 0xF1338231, 0x262B2C7F > ``` `mix[6]` - > ``` > 0x3C554151, 0x70999423, 0x64BB49A8, 0xF9EBE9E9, > 0x7D9C28CF, 0x23EE7659, 0xD6504FCF, 0x1C58C2A1, > 0x62B9C627, 0x680AE248, 0xF196A153, 0x2A3C345A, > 0x860E6EB2, 0x266D2652, 0x3C9F2420, 0xF790A538, > 0x710A5523, 0xBEA2603A, 0x1C1CC272, 0xF91D482A, > 0x1CA19931, 0x7A80ED37, 0x9572513D, 0x376F1CFE, > 0xE57C1264, 0xE47BF931, 0xC7310E05, 0x7866CC9E, > 0xC676BBD5, 0x4C167FEB, 0x0FE03D2B, 0x46C6D26C > ``` `mix[7]` - > ``` > 0x3395F65A, 0x7142A5B1, 0x97780661, 0xE5EE45B8, > 0xCD9FDC42, 0x25BF044C, 0x0350F81B, 0x55D50703, > 0xA8CB893E, 0xEE795201, 0xC2D6E598, 0xC2AC2D7A, > 0xD2E81716, 0xAD876790, 0x0F3339C7, 0xEEC31E01, > 0xA293ABF6, 0x28AE317D, 0x44A7AC05, 0xBEBA1C5E, > 0x325ED29E, 0x4344131E, 0x921CD8DD, 0x08AB9E0B, > 0xC18E66A6, 0x87E6BCA3, 0x24CE82AE, 0xC910B4F1, > 0x9E513EC0, 0xA1B8CB76, 0xF0455815, 0x36BC0DCF > ``` `mix[8]` - > ``` > 0x0117C85F, 0xE018F2C6, 0x416C897D, 0x9D288A0F, > 0x2AA9EA93, 0x5A6D3CEA, 0xAA99B726, 0x0A42DAB7, > 0x72F6EA4A, 0x1DB074E6, 0x2E2A606C, 0xAC5D509B, > 0x53F13E85, 0x1D44B521, 0x24234C42, 0xAD5BAD70, > 0xAB2DA791, 0x6479546A, 0xD27B3771, 0xBB0A09DD, > 0x6D3C8056, 0x96572D4B, 0x52DB6535, 0x3D242BC1, > 0xF37D7C7A, 0xA60F7111, 0x59B59667, 0xF28635B0, > 0xC2A8F9F5, 0x7CFB9CCB, 0xDF8697AA, 0xA3260D94 > ``` `mix[9]` - > ``` > 0xA387FC4B, 0xC757D3A0, 0xA584E879, 0xB0A1EC29, > 0x82CB2EC3, 0x6BF33664, 0x41FECC42, 0xF60C2AC5, > 0xEA250BE5, 0x42BE9F33, 0x9227B0B3, 0x9080A6AB, > 0xAF193598, 0xC708BC8A, 0x020CDEDB, 0x7FA2F773, > 0x4338E670, 0x069E0242, 0x5AD87326, 0xD7A87124, > 0x220D5C46, 0x26D3400D, 0x4899D1EE, 0x90EAD2F6, > 0xFA3F1F74, 0x9C5A5D58, 0xAE20567C, 0x424B690D, > 0xC9A4057A, 0x9F2A5CD1, 0xAA33CD5F, 0x18F58C00 > ``` `mix[10]` - > ``` > 0xEAFE893C, 0x1ABB2971, 0x29803BB3, 0x5BC2F71F, > 0x619DAFAD, 0xD9CFEFB6, 0xB4FEFAB5, 0x5EB249EC, > 0x1A6E2B3A, 0xFB05DD28, 0xDCB33C2E, 0x630BB8AE, > 0x43463B39, 0x3BD2F552, 0xFB20C0A2, 0x3383BA34, > 0x2E9C1A99, 0x60A949B2, 0x861372AB, 0xC149D929, > 0xA77A0A93, 0xE0CEE0D9, 0x791E7E82, 0x66A8D75A, > 0x44D1845F, 0xE534DC4A, 0x2C7DD20C, 0xEEDAB329, > 0x3209FE2A, 0x0C0406BC, 0xD6D4BD2A, 0x5FDB13CC > ``` `mix[11]` - > ``` > 0x2520ABB3, 0xCD942485, 0x9A2929BC, 0x0E10F18C, > 0xDFB1815E, 0x8BEF05A3, 0x531A8837, 0x668838E4, > 0xBACCE200, 0x003F85C2, 0x56226F05, 0xC2233173, > 0x2F39A0D9, 0xF4466D0D, 0x0B9E686C, 0x82C69BDA, > 0x0C8A8CD6, 0xA93F3001, 0x36A65EC1, 0x40CCFD7A, > 0x84484E23, 0xF0896D45, 0x06D9F760, 0x6559142C, > 0x9FFE2E88, 0x9593DC89, 0x89C9E3B9, 0x33285F41, > 0x16F636C8, 0xA08169C7, 0xA5E1C956, 0xC22CCF52 > ``` `mix[12]` - > ``` > 0xDC3B8CAA, 0xC6941197, 0x9969D596, 0x46453D3E, > 0x568EAFEA, 0x5B823345, 0xDE606E8E, 0x7523C86D, > 0x0EDAF441, 0x00C3D848, 0xAE5BAB99, 0xD705B9EE, > 0x54B49E3D, 0xF364A6A4, 0x42C55975, 0xFE41EED5, > 0xAD46170F, 0xAABE4868, 0x270379F9, 0xD33D0D7C, > 0xF39C476C, 0xA449118E, 0x71BCC1E4, 0x5E300E77, > 0x1CACD489, 0x4D82FABD, 0x090F9F80, 0xB2DB9626, > 0xE12A973B, 0x1B77460C, 0xD25F89F5, 0x5753612E > ``` `mix[13]` - > ``` > 0x042D951C, 0x38833AA7, 0xBEA9894D, 0x7AE7F381, > 0x42DB6723, 0x1FB0294F, 0x41452A28, 0xA7A97B9C, > 0x228AA7EA, 0x781A7420, 0x4589736D, 0xB3C19349, > 0x685EF9E6, 0xB4987DF6, 0xC9C3B188, 0x2DCA6A03, > 0xE89A6D3D, 0x50EF7CF5, 0xF6274868, 0x8AA22824, > 0x980FFDE3, 0xD4A6CB4E, 0x06FF9E1A, 0xBADB6DF5, > 0xEDE3ADF3, 0xC9CF45F6, 0xFDFA194C, 0xAF076AA8, > 0x7B876CEA, 0xB0C89575, 0x35A72155, 0x6CFDFC06 > ``` `mix[14]` - > ``` > 0x0E3E28C8, 0xEC329DEC, 0x06D0A1D1, 0xF95ABEF8, > 0x168DCF28, 0xDD7714C1, 0x769C119E, 0xA5530A7D, > 0x1EEACB59, 0x30FD21BB, 0x082A3691, 0x1C4C9BCA, > 0x420F27DE, 0xA8FDA3AE, 0xE182142E, 0x5102F0FF, > 0x15B82277, 0x120C3217, 0x7BE714ED, 0xA251DCD5, > 0x6FB4F831, 0xB71D7B32, 0xD5F7A04A, 0x763E1A20, > 0x38E68B0C, 0xBB5A4121, 0x9340BF06, 0x948B03F8, > 0xE71BF17B, 0x1BB5F06B, 0x26F2A200, 0x5F28C415 > ``` `mix[15]` - > ``` > 0xC818CD64, 0xBC910343, 0xB18B7776, 0x7182DEBA, > 0x9DB319EE, 0x9AE7F32F, 0x3CA9F8B5, 0xC63F48ED, > 0x8321533A, 0x059C96B1, 0x8DCDA60A, 0x75B6C1D1, > 0xC3406B57, 0x3DFE9E9B, 0xC01E1FD7, 0xC4643218, > 0x6873F0BA, 0x8ABD36B9, 0xA74D0CBD, 0x8A637118, > 0x6916416C, 0xB6E3A8DD, 0xB68DD4FA, 0xFBD543EE, > 0x56F05592, 0x33D6DB82, 0x58D0A7DD, 0x18630C6E, > 0xB33749CA, 0x5D2E87F7, 0x0F3C39DB, 0x3CAE9895 > ``` ## progPowHash ### 0.9.2 [Machine-readable data](https://github.com/ethereum/EIPs/blob/ad4e73f239d53d72a21cfd8fdc89dc81eb9d2688/assets/eip-1057/test-vectors-0.9.3.json) Block 30000: - `prog_seed` - 600 - `nonce` - `123456789abcdef0` - `header` - `ffeeddccbbaa9988776655443322110000112233445566778899aabbccddeeff` - `mix_hash` - `11f19805c58ab46610ff9c719dcf0a5f18fa2f1605798eef770c47219274767d` - `final_hash` - `5b7ccd472dbefdd95b895cac8ece67ff0deb5a6bd2ecc6e162383d00c3728ece` Block 0: - `prog_seed` - 0 - `nonce` - `0000000000000000` - `header` - `0000000000000000000000000000000000000000000000000000000000000000` - `mix_hash` - `faeb1be51075b03a4ff44b335067951ead07a3b078539ace76fd56fc410557a3` - `final_hash` - `63155f732f2bf556967f906155b510c917e48e99685ead76ea83f4eca03ab12b` Block 49: - `prog_seed` - 0 - `nonce` - `0000000006ff2c47` - `header` - `63155f732f2bf556967f906155b510c917e48e99685ead76ea83f4eca03ab12b` - `mix_hash` - `c789c1180f890ec555ff42042913465481e8e6bc512cb981e1c1108dc3f2227d` - `final_hash` - `9e7248f20914913a73d80a70174c331b1d34f260535ac3631d770e656b5dd922` Block 50: - `prog_seed` - 1 - `nonce` - `00000000076e482e` - `header` - `9e7248f20914913a73d80a70174c331b1d34f260535ac3631d770e656b5dd922` - `mix_hash` - `c7340542c2a06b3a7dc7222635f7cd402abf8b528ae971ddac6bbe2b0c7cb518` - `final_hash` - `de37e1824c86d35d154cf65a88de6d9286aec4f7f10c3fc9f0fa1bcc2687188d` Block 99: - `prog_seed` - 1 - `nonce` - `000000003917afab` - `header` - `de37e1824c86d35d154cf65a88de6d9286aec4f7f10c3fc9f0fa1bcc2687188d` - `mix_hash` - `f5e60b2c5bfddd136167a30cbc3c8dbdbd15a512257dee7964e0bc6daa9f8ba7` - `final_hash` - `ac7b55e801511b77e11d52e9599206101550144525b5679f2dab19386f23dcce` Block 29,950: - `prog_seed` - 599 - `nonce` - `005d409dbc23a62a` - `header` - `ac7b55e801511b77e11d52e9599206101550144525b5679f2dab19386f23dcce` - `mix_hash` - `07393d15805eb08ee6fc6cb3ad4ad1010533bd0ff92d6006850246829f18fd6e` - `final_hash` - `e43d7e0bdc8a4a3f6e291a5ed790b9fa1a0948a2b9e33c844888690847de19f5` Block 29,999: - `prog_seed` - 599 - `nonce` - `005db5fa4c2a3d03` - `header` - `e43d7e0bdc8a4a3f6e291a5ed790b9fa1a0948a2b9e33c844888690847de19f5` - `mix_hash` - `7551bddf977491da2f6cfc1679299544b23483e8f8ee0931c4c16a796558a0b8` - `final_hash` - `d34519f72c97cae8892c277776259db3320820cb5279a299d0ef1e155e5c6454` Block 30,000: - `prog_seed` - 600 - `nonce` - `005db8607994ff30` - `header` - `d34519f72c97cae8892c277776259db3320820cb5279a299d0ef1e155e5c6454` - `mix_hash` - `f1c2c7c32266af9635462e6ce1c98ebe4e7e3ecab7a38aaabfbf2e731e0fbff4` - `final_hash` - `8b6ce5da0b06d18db7bd8492d9e5717f8b53e7e098d9fef7886d58a6e913ef64` Block 30,049: - `prog_seed` - 600 - `nonce` - `005e2e215a8ca2e7` - `header` - `8b6ce5da0b06d18db7bd8492d9e5717f8b53e7e098d9fef7886d58a6e913ef64` - `mix_hash` - `57fe6a9fbf920b4e91deeb66cb0efa971e08229d1a160330e08da54af0689add` - `final_hash` - `c2c46173481b9ced61123d2e293b42ede5a1b323210eb2a684df0874ffe09047` Block 30,050: - `prog_seed` - 601 - `nonce` - `005e30899481055e` - `header` - `c2c46173481b9ced61123d2e293b42ede5a1b323210eb2a684df0874ffe09047` - `mix_hash` - `ba30c61cc5a2c74a5ecaf505965140a08f24a296d687e78720f0b48baf712f2d` - `final_hash` - `ea42197eb2ba79c63cb5e655b8b1f612c5f08aae1a49ff236795a3516d87bc71` Block 30,099: - `prog_seed` - 601 - `nonce` - `005ea6aef136f88b` - `header` - `ea42197eb2ba79c63cb5e655b8b1f612c5f08aae1a49ff236795a3516d87bc71` - `mix_hash` - `cfd5e46048cd133d40f261fe8704e51d3f497fc14203ac6a9ef6a0841780b1cd` - `final_hash` - `49e15ba4bf501ce8fe8876101c808e24c69a859be15de554bf85dbc095491bd6` Block 59,950: - `prog_seed` - 1,199 - `nonce` - `02ebe0503bd7b1da` - `header` - `49e15ba4bf501ce8fe8876101c808e24c69a859be15de554bf85dbc095491bd6` - `mix_hash` - `21511fbaa31fb9f5fc4998a754e97b3083a866f4de86fa7500a633346f56d773` - `final_hash` - `f5c50ba5c0d6210ddb16250ec3efda178de857b2b1703d8d5403bd0f848e19cf` Block 59,999: - `prog_seed` - 1,199 - `nonce` - `02edb6275bd221e3` - `header` - `f5c50ba5c0d6210ddb16250ec3efda178de857b2b1703d8d5403bd0f848e19cf` - `mix_hash` - `653eda37d337e39d311d22be9bbd3458d3abee4e643bee4a7280a6d08106ef98` - `final_hash` - `341562d10d4afb706ec2c8d5537cb0c810de02b4ebb0a0eea5ae335af6fb2e88` Block 10,000,000: - `prog_seed` - 200,000 - `nonce` - `005e30899481055e` - `header` - `efda178de857b2b1703d8d5403bd0f848e19cff5c50ba5c0d6210ddb16250ec3` - `mix_hash` - `b2403f56c426177856eaf0eedd707c86ae78a432b9169c3689a67058fcf2a848` - `final_hash` - `206aee640c0fd21473d5cc3654d63c80442d9e2dfa676d2801d3ec1fbab38a6d` Block 100,000,000: - `prog_seed` - 2,000,000 - `nonce` - `02abe0589481055e` - `header` - `49e15ba4bf501ce8fe88765403bd0f848e19cff5c50ba5c0d6210ddb16250ec3` - `mix_hash` - `ac452084d6f4e6eacf4282ad58dbd4ce7ef2653fb5e6b5c877f56928c907432a` - `final_hash` - `b879f84923e71b812ef5a42ece0b5b9366c31cab218f40afe65f8a2cae448a6f` ### 0.9.3 [Machine-readable data](https://github.com/ethereum/EIPs/blob/ad4e73f239d53d72a21cfd8fdc89dc81eb9d2688/assets/eip-1057/test-vectors-0.9.3.json) https://eips.ethereum.org/assets/eip-1057/test-vectors https://eips.ethereum.org/assets/eip-1057/test-vectors Contributors / ## Contributors * Andrew Redden (@androolloyd) * Patrick Gallagher (@pi0neerpat) * Leo Alt (@leonardoalt) * Santiago Palladino (@spalladino) * William Entriken (@fulldecent) * Gonçalo Sá (@GNSPS) * Brian Burns (@Droopy78) * Ramesh Nair(@hiddentao) * Jules Goddard (@JulesGoddard) * Micah Zoltu (@MicahZoltu) * Sam Wilson (@SamWilsn) * William Morriss (@wjmelements) * Zachary (@Remscar) * Patrick Collins (@PatrickAlphaC) * Hadrien Croubois (@Amxx) * (@farreldarian) * Kelvin Schoofs (@SchoofsKelvin) * (@0xpApaSmURf) * Nathan Sala (@nataouze) * Anders Torbjornsen (@anders-torbjornsen) * (@Pandapip1) * Xavier Iturralde (@xibot) * Coder Dan (@cinnabarhorse) * GldnXross (@gldnxross) * Christian Reitwiessner (@chriseth) * Timidan (@Timidan) * cyotee doge (@cyotee) * Glory Praise Emmanuel (@emmaglorypraise) * Ed Zynda (@ezynda3) * Arthur Nesbitt (@nesbitta) * Cliff Hall (@cliffhall) * Tyler Scott Ward (@tylerscottward) * Troy Murray (@DannyDesert) * Dan Finlay (@danfinlay) * Theodore Georgas (@tgeorgas) * Aditya Palepu (@apalepu23) * Ronan Sandford (@wighawag) * Markus Waas (@gorgos) * Blessing Emah (@BlessingEmah) * Andrew Edwards * Ashwin Yardi (@ashwinYardi) * Marco Castignoli (@marcocastignoli) * Blaine Bublitz (@phated) * Bearded * Nick Barry (@ItsNickBarry) * (@Vectorized) * Rachit Srivastava (@rachit2501) * Neeraj Kashyap (@zomglings) * Zac Denham (@zdenham) * JA (@ubinatus) * Carter Carlson (@cartercarlson) * James Sayer (@jamessayer98) * Arpit Temani (@temaniarpit27) * Parv Garg (@parv3213) * Publius (@publiuss) * Guy Hance (@guyhance) * Payn (@Ayuilos) * Luis Schliesske (@gitpusha) * Hilmar Orth (@hilmarx) * Matthieu Marie Joseph (@Gauddel) * David Uzochukwu (@davidpius95) * TJ VanSlooten (@tjvsx) * 0xFluffyBeard (@0xFluffyBeard) * Florian Pfeiffer (@FlorianPfeifferKanaloaNetwork) * Mick de Graaf(@MickdeGraaf) * Alessio Delmonti (@Alexintosh) * Neirenoir (@Neirenoir) * Evert Kors (@Evert0x) * Patrick Kim (@pakim249CAL) * Ersan YAKIT (@ersanyakit) * Matias Arazi (@MatiArazi) * Lucas Grasso Ramos (@LucasGrasso) * Nikolay Angelov (@NikolayAngelov) * John Reynolds (@gweiworld) * Viraz Malhotra (@viraj124) * Kemal Emre Ballı (@emrbli) * Zack Peng (@zackpeng) https://eips.ethereum.org/assets/eip-2535/Contributors https://eips.ethereum.org/assets/eip-2535/Contributors Set of test vectors to perform benchmarking of EIP-2537 / # Set of test vectors to perform benchmarking of EIP-2537 ## Inlined vectors Here one can find inputs (encoded with ABI from the main spec spec) that can be considered "worst cases" for "double-and-add" multiplication algorithm, and also some cases for pairing call. Those are purely for convenience of initial benchmarking of the full ABI without manual test generation. ``` G1 addition example input = 0000000000000000000000000000000012196c5a43d69224d8713389285f26b98f86ee910ab3dd668e413738282003cc5b7357af9a7af54bb713d62255e80f560000000000000000000000000000000006ba8102bfbeea4416b710c73e8cce3032c31c6269c44906f8ac4f7874ce99fb17559992486528963884ce429a992fee000000000000000000000000000000000001101098f5c39893765766af4512a0c74e1bb89bc7e6fdf14e3e7337d257cc0f94658179d83320b99f31ff94cd2bac0000000000000000000000000000000003e1a9f9f44ca2cdab4f43a1a3ee3470fdf90b2fc228eb3b709fcd72f014838ac82a6d797aeefed9a0804b22ed1ce8f7 G2 addition example input = 0000000000000000000000000000000018c0ada6351b70661f053365deae56910798bd2ace6e2bf6ba4192d1a229967f6af6ca1c9a8a11ebc0a232344ee0f6d6000000000000000000000000000000000cc70a587f4652039d8117b6103858adcd9728f6aebe230578389a62da0042b7623b1c0436734f463cfdd187d20903240000000000000000000000000000000009f50bd7beedb23328818f9ffdafdb6da6a4dd80c5a9048ab8b154df3cad938ccede829f1156f769d9e149791e8e0cd900000000000000000000000000000000079ba50d2511631b20b6d6f3841e616e9d11b68ec3368cd60129d9d4787ab56c4e9145a38927e51c9cd6271d493d938800000000000000000000000000000000192fa5d8732ff9f38e0b1cf12eadfd2608f0c7a39aced7746837833ae253bb57ef9c0d98a4b69eeb2950901917e99d1e0000000000000000000000000000000009aeb10c372b5ef1010675c6a4762fda33636489c23b581c75220589afbc0cc46249f921eea02dd1b761e036ffdbae220000000000000000000000000000000002d225447600d49f932b9dd3ca1e6959697aa603e74d8666681a2dca8160c3857668ae074440366619eb8920256c4e4a00000000000000000000000000000000174882cdd3551e0ce6178861ff83e195fecbcffd53a67b6f10b4431e423e28a480327febe70276036f60bb9c99cf7633 G1 mul double and add worst case = 0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff G2 mul double and add worst case = 00000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79beffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff Pairing case for 2 pairs = 0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be Pairing case for 4 pairs = 0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be Pairing case for 6 pairs = 0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be ``` https://eips.ethereum.org/assets/eip-2537/bench_vectors https://eips.ethereum.org/assets/eip-2537/bench_vectors Fast subgroup checks used by EIP-2537 / # Fast subgroup checks used by EIP-2537 ### Fields and Groups Field Fp is defined as the finite field of size `p` with elements represented as integers between 0 and p-1 (both inclusive). Field Fp2 is defined as `Fp[X]/(X^2-nr2)` with elements `el = c0 + c1 * v`, where `v` is the formal square root of `nr2` represented as integer pairs `(c0,c1)`. Group G1 is defined as a set of Fp pairs (points) `(x,y)` such that either `(x,y)` is `(0,0)` or `x,y` satisfy the curve Fp equation. Group G2 is defined as a set of Fp2 pairs (points) `(x', y')` such that either `(x', y')` is `(0,0)` or `(x', y')` satisfy the curve Fp2 equation. ## Curve parameters The set of parameters used by fast subgroup checks: ``` |x| (seed) = 15132376222941642752 x is negative = true Cube root of unity modulo p - Beta = 793479390729215512621379701633421447060886740281060493010456487427281649075476305620758731620350 r = 4002409555221667392624310435006688643935503118305586438271171395842971157480381377015405980053539358417135540939437 * v s = 2973677408986561043442465346520108879172042883009249989176415018091420807192182638567116318576472649347015917690530 + 1028732146235106349975324479215795277384839936929757896155643118032610843298655225875571310552543014690878354869257 * v ``` ## Helper function to compute the conjugate over Fp2 - `conjugate` `conjugate(c0 + c1 * v) := c0 - c1 * v` ## G1 endomorphism - `phi` The endomorphism `phi` transform the point from `(x,y)` to `(Beta*x,y)` where `Beta` is a precomputed cube root of unity modulo `p` given above in parameters sections: `phi((x,y)) := (Beta*x,y)` ## G2 endomorphism - `psi` `psi((x,y)) := (conjugate(x)*r,conjugate(y)*s)` # The G1 case Before accepting a point `P` as input that purports to be a member of G1 subject the input to the following endomorphism test: `phi(P) + x^2*P = 0` # The G2 case Before accepting a point `P` as input that purports to be a member of G2 subject the input to the following endomorphism test: `psi(P) + x*P = 0` # Resources * https://eprint.iacr.org/2021/1130.pdf, sec.4 * https://eprint.iacr.org/2022/352.pdf, sec. 4.2 https://eips.ethereum.org/assets/eip-2537/fast_subgroup_checks https://eips.ethereum.org/assets/eip-2537/fast_subgroup_checks Field element to curve point mapping used by EIP 2537 / # Field element to curve point mapping used by EIP 2537 For a BLS12-381 implemented by EIP-2537 a short Weierstrass curve equation y^2 = x^3 + A * x + B has a property that a product AB = 0, so to implement a mapping function two step algorithms is performed: - Field element is mapped to a some other curve with AB != 0 - Isogeny is applied to one to one map a point of this other curve to a point on BLS12-381 - Cofactor is cleared for a point now on BLS12-381 Below we describe generic algorithms for mapping and isogeny application, and later on give concrete parameters for the algorithms ## Helper function to clear a cofactor Later on we use a helper function to clear a cofactor of the curve point. It's implemented as ~~~ clear_cofactor(P) := h_eff * P ~~~ where values of h_eff are given below in parameters sections ## Simplified SWU for AB != 0 The function map\_to\_curve\_simple\_swu(u) implements a simplification of the Shallue-van de Woestijne-Ulas mapping described by Brier et al., which they call the "simplified SWU" map. Wahby and Boneh generalize and optimize this mapping. Preconditions: A Weierstrass curve y^2 = g(x) x^3 + A * x + B where A != 0 and B != 0. Constants: - A and B, the parameters of the Weierstrass curve. - Z, an element of F meeting the below criteria. The criteria are: 1. Z is non-square in F, 2. Z != -1 in F, 3. the polynomial g(x) - Z is irreducible over F, and 4. g(B / (Z * A)) is square in F. Sign of y: Inputs u and -u give the same x-coordinate. Thus, we set sgn0(y) == sgn0(u). Exceptions: The exceptional cases are values of u such that Z^2 * u^4 + Z * u^2 == 0. This includes u == 0, and may include other values depending on Z. Implementations must detect this case and set x1 = B / (Z * A), which guarantees that g(x1) is square by the condition on Z given above. Operations: ~~~ 1. tv1 = inv0(Z^2 * u^4 + Z * u^2) 2. x1 = (-B / A) * (1 + tv1) 3. If tv1 == 0, set x1 = B / (Z * A) 4. gx1 = x1^3 + A * x1 + B 5. x2 = Z * u^2 * x1 6. gx2 = x2^3 + A * x2 + B 7. If is_square(gx1), set x = x1 and y = sqrt(gx1) 8. Else set x = x2 and y = sqrt(gx2) 9. If sgn0(u) != sgn0(y), set y = -y 10. return (x, y) ~~~ ## Simplified SWU for AB == 0 Wahby and Boneh show how to adapt the simplified SWU mapping to Weierstrass curves having A == 0 or B == 0, which the mapping of simple SWU does not support. This method requires finding another elliptic curve E' given by the equation ~~~ y'^2 = g'(x') = x'^3 + A' * x' + B' ~~~ that is isogenous to E and has A' != 0 and B' != 0. This isogeny defines a map iso\_map(x', y') given by a pair of rational functions. iso\_map takes as input a point on E' and produces as output a point on E. Once E' and iso\_map are identified, this mapping works as follows: on input u, first apply the simplified SWU mapping to get a point on E', then apply the isogeny map to that point to get a point on E. Note that iso\_map is a group homomorphism, meaning that point addition commutes with iso\_map. Thus, when using this mapping in the hash\_to\_curve construction of {{roadmap}}, one can effect a small optimization by first mapping u0 and u1 to E', adding the resulting points on E', and then applying iso\_map to the sum. This gives the same result while requiring only one evaluation of iso\_map. Preconditions: An elliptic curve E' with A' != 0 and B' != 0 that is isogenous to the target curve E with isogeny map iso\_map from E' to E. So the full mapping algorithm looks as: - map\_to\_curve\_simple\_swu is the simple SWU mapping to E' - iso\_map is the isogeny map from E' to E Sign of y: for this map, the sign is determined by map\_to\_curve\_simple\_swu. No further sign adjustments are necessary. Exceptions: map\_to\_curve\_simple\_swu handles its exceptional cases. Exceptional cases of iso\_map are inputs that cause the denominator of either rational function to evaluate to zero; such cases MUST return the identity point on E. ## Full algorithm restated ~~~ 1. (x', y') = map_to_curve_simple_swu(u) # (x', y') is on E' 2. (x, y) = iso_map(x', y') # (x, y) is on E 3. (x, y) = clear_cofactor((x, y)) # clears cofactor for point (x, y) on E 4. return (x, y) ~~~ ## Parameters for EIP-2537 ### Fp-to-G1 mapping - Z: 11 - E': y'^2 = x'^3 + A' * x' + B', where - A' = 0x144698a3b8e9433d693a02c96d4982b0ea985383ee66a8d8e8981aefd881ac98936f8da0e0f97f5cf428082d584c1d - B' = 0x12e2908d11688030018b12e8753eee3b2016c1f0f24f4070a0b9c14fcef35ef55a23215a316ceaa5d1cc48e98e172be0 - h\_eff: 0xd201000000010001 The 11-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions: - x = x\_num / x\_den, where - x\_num = k\_(1,11) * x'^11 + k\_(1,10) * x'^10 + k\_(1,9) * x'^9 + ... + k\_(1,0) - x\_den = x'^10 + k\_(2,9) * x'^9 + k\_(2,8) * x'^8 + ... + k\_(2,0) - y = y' * y\_num / y\_den, where - y\_num = k\_(3,15) * x'^15 + k\_(3,14) * x'^14 + k\_(3,13) * x'^13 + ... + k\_(3,0) - y\_den = x'^15 + k\_(4,14) * x'^14 + k\_(4,13) * x'^13 + ... + k\_(4,0) The constants used to compute x\_num are as follows: - k\_(1,0) = 0x11a05f2b1e833340b809101dd99815856b303e88a2d7005ff2627b56cdb4e2c85610c2d5f2e62d6eaeac1662734649b7 - k\_(1,1) = 0x17294ed3e943ab2f0588bab22147a81c7c17e75b2f6a8417f565e33c70d1e86b4838f2a6f318c356e834eef1b3cb83bb - k\_(1,2) = 0xd54005db97678ec1d1048c5d10a9a1bce032473295983e56878e501ec68e25c958c3e3d2a09729fe0179f9dac9edcb0 - k\_(1,3) = 0x1778e7166fcc6db74e0609d307e55412d7f5e4656a8dbf25f1b33289f1b330835336e25ce3107193c5b388641d9b6861 - k\_(1,4) = 0xe99726a3199f4436642b4b3e4118e5499db995a1257fb3f086eeb65982fac18985a286f301e77c451154ce9ac8895d9 - k\_(1,5) = 0x1630c3250d7313ff01d1201bf7a74ab5db3cb17dd952799b9ed3ab9097e68f90a0870d2dcae73d19cd13c1c66f652983 - k\_(1,6) = 0xd6ed6553fe44d296a3726c38ae652bfb11586264f0f8ce19008e218f9c86b2a8da25128c1052ecaddd7f225a139ed84 - k\_(1,7) = 0x17b81e7701abdbe2e8743884d1117e53356de5ab275b4db1a682c62ef0f2753339b7c8f8c8f475af9ccb5618e3f0c88e - k\_(1,8) = 0x80d3cf1f9a78fc47b90b33563be990dc43b756ce79f5574a2c596c928c5d1de4fa295f296b74e956d71986a8497e317 - k\_(1,9) = 0x169b1f8e1bcfa7c42e0c37515d138f22dd2ecb803a0c5c99676314baf4bb1b7fa3190b2edc0327797f241067be390c9e - k\_(1,10) = 0x10321da079ce07e272d8ec09d2565b0dfa7dccdde6787f96d50af36003b14866f69b771f8c285decca67df3f1605fb7b - k\_(1,11) = 0x6e08c248e260e70bd1e962381edee3d31d79d7e22c837bc23c0bf1bc24c6b68c24b1b80b64d391fa9c8ba2e8ba2d229 The constants used to compute x\_den are as follows: - k\_(2,0) = 0x8ca8d548cff19ae18b2e62f4bd3fa6f01d5ef4ba35b48ba9c9588617fc8ac62b558d681be343df8993cf9fa40d21b1c - k\_(2,1) = 0x12561a5deb559c4348b4711298e536367041e8ca0cf0800c0126c2588c48bf5713daa8846cb026e9e5c8276ec82b3bff - k\_(2,2) = 0xb2962fe57a3225e8137e629bff2991f6f89416f5a718cd1fca64e00b11aceacd6a3d0967c94fedcfcc239ba5cb83e19 - k\_(2,3) = 0x3425581a58ae2fec83aafef7c40eb545b08243f16b1655154cca8abc28d6fd04976d5243eecf5c4130de8938dc62cd8 - k\_(2,4) = 0x13a8e162022914a80a6f1d5f43e7a07dffdfc759a12062bb8d6b44e833b306da9bd29ba81f35781d539d395b3532a21e - k\_(2,5) = 0xe7355f8e4e667b955390f7f0506c6e9395735e9ce9cad4d0a43bcef24b8982f7400d24bc4228f11c02df9a29f6304a5 - k\_(2,6) = 0x772caacf16936190f3e0c63e0596721570f5799af53a1894e2e073062aede9cea73b3538f0de06cec2574496ee84a3a - k\_(2,7) = 0x14a7ac2a9d64a8b230b3f5b074cf01996e7f63c21bca68a81996e1cdf9822c580fa5b9489d11e2d311f7d99bbdcc5a5e - k\_(2,8) = 0xa10ecf6ada54f825e920b3dafc7a3cce07f8d1d7161366b74100da67f39883503826692abba43704776ec3a79a1d641 - k\_(2,9) = 0x95fc13ab9e92ad4476d6e3eb3a56680f682b4ee96f7d03776df533978f31c1593174e4b4b7865002d6384d168ecdd0a The constants used to compute y\_num are as follows: - k\_(3,0) = 0x90d97c81ba24ee0259d1f094980dcfa11ad138e48a869522b52af6c956543d3cd0c7aee9b3ba3c2be9845719707bb33 - k\_(3,1) = 0x134996a104ee5811d51036d776fb46831223e96c254f383d0f906343eb67ad34d6c56711962fa8bfe097e75a2e41c696 - k\_(3,2) = 0xcc786baa966e66f4a384c86a3b49942552e2d658a31ce2c344be4b91400da7d26d521628b00523b8dfe240c72de1f6 - k\_(3,3) = 0x1f86376e8981c217898751ad8746757d42aa7b90eeb791c09e4a3ec03251cf9de405aba9ec61deca6355c77b0e5f4cb - k\_(3,4) = 0x8cc03fdefe0ff135caf4fe2a21529c4195536fbe3ce50b879833fd221351adc2ee7f8dc099040a841b6daecf2e8fedb - k\_(3,5) = 0x16603fca40634b6a2211e11db8f0a6a074a7d0d4afadb7bd76505c3d3ad5544e203f6326c95a807299b23ab13633a5f0 - k\_(3,6) = 0x4ab0b9bcfac1bbcb2c977d027796b3ce75bb8ca2be184cb5231413c4d634f3747a87ac2460f415ec961f8855fe9d6f2 - k\_(3,7) = 0x987c8d5333ab86fde9926bd2ca6c674170a05bfe3bdd81ffd038da6c26c842642f64550fedfe935a15e4ca31870fb29 - k\_(3,8) = 0x9fc4018bd96684be88c9e221e4da1bb8f3abd16679dc26c1e8b6e6a1f20cabe69d65201c78607a360370e577bdba587 - k\_(3,9) = 0xe1bba7a1186bdb5223abde7ada14a23c42a0ca7915af6fe06985e7ed1e4d43b9b3f7055dd4eba6f2bafaaebca731c30 - k\_(3,10) = 0x19713e47937cd1be0dfd0b8f1d43fb93cd2fcbcb6caf493fd1183e416389e61031bf3a5cce3fbafce813711ad011c132 - k\_(3,11) = 0x18b46a908f36f6deb918c143fed2edcc523559b8aaf0c2462e6bfe7f911f643249d9cdf41b44d606ce07c8a4d0074d8e - k\_(3,12) = 0xb182cac101b9399d155096004f53f447aa7b12a3426b08ec02710e807b4633f06c851c1919211f20d4c04f00b971ef8 - k\_(3,13) = 0x245a394ad1eca9b72fc00ae7be315dc757b3b080d4c158013e6632d3c40659cc6cf90ad1c232a6442d9d3f5db980133 - k\_(3,14) = 0x5c129645e44cf1102a159f748c4a3fc5e673d81d7e86568d9ab0f5d396a7ce46ba1049b6579afb7866b1e715475224b - k\_(3,15) = 0x15e6be4e990f03ce4ea50b3b42df2eb5cb181d8f84965a3957add4fa95af01b2b665027efec01c7704b456be69c8b604 The constants used to compute y\_den are as follows: - k\_(4,0) = 0x16112c4c3a9c98b252181140fad0eae9601a6de578980be6eec3232b5be72e7a07f3688ef60c206d01479253b03663c1 - k\_(4,1) = 0x1962d75c2381201e1a0cbd6c43c348b885c84ff731c4d59ca4a10356f453e01f78a4260763529e3532f6102c2e49a03d - k\_(4,2) = 0x58df3306640da276faaae7d6e8eb15778c4855551ae7f310c35a5dd279cd2eca6757cd636f96f891e2538b53dbf67f2 - k\_(4,3) = 0x16b7d288798e5395f20d23bf89edb4d1d115c5dbddbcd30e123da489e726af41727364f2c28297ada8d26d98445f5416 - k\_(4,4) = 0xbe0e079545f43e4b00cc912f8228ddcc6d19c9f0f69bbb0542eda0fc9dec916a20b15dc0fd2ededda39142311a5001d - k\_(4,5) = 0x8d9e5297186db2d9fb266eaac783182b70152c65550d881c5ecd87b6f0f5a6449f38db9dfa9cce202c6477faaf9b7ac - k\_(4,6) = 0x166007c08a99db2fc3ba8734ace9824b5eecfdfa8d0cf8ef5dd365bc400a0051d5fa9c01a58b1fb93d1a1399126a775c - k\_(4,7) = 0x16a3ef08be3ea7ea03bcddfabba6ff6ee5a4375efa1f4fd7feb34fd206357132b920f5b00801dee460ee415a15812ed9 - k\_(4,8) = 0x1866c8ed336c61231a1be54fd1d74cc4f9fb0ce4c6af5920abc5750c4bf39b4852cfe2f7bb9248836b233d9d55535d4a - k\_(4,9) = 0x167a55cda70a6e1cea820597d94a84903216f763e13d87bb5308592e7ea7d4fbc7385ea3d529b35e346ef48bb8913f55 - k\_(4,10) = 0x4d2f259eea405bd48f010a01ad2911d9c6dd039bb61a6290e591b36e636a5c871a5c29f4f83060400f8b49cba8f6aa8 - k\_(4,11) = 0xaccbb67481d033ff5852c1e48c50c477f94ff8aefce42d28c0f9a88cea7913516f968986f7ebbea9684b529e2561092 - k\_(4,12) = 0xad6b9514c767fe3c3613144b45f1496543346d98adf02267d5ceef9a00d9b8693000763e3b90ac11e99b138573345cc - k\_(4,13) = 0x2660400eb2e4f3b628bdd0d53cd76f2bf565b94e72927c1cb748df27942480e420517bd8714cc80d1fadc1326ed06f7 - k\_(4,14) = 0xe0fa1d816ddc03e6b24255e0d7819c171c40f65e273b853324efcd6356caa205ca2f570f13497804415473a1d634b8f ### Fp2-to-G2 mapping Symbol `I` means a non-residue used to make an extension field Fp2 - Z: -(2 + I) - E': y'^2 = x'^3 + A' * x' + B', where - A' = 240 * I - B' = 1012 * (1 + I) - h\_eff: 0xbc69f08f2ee75b3584c6a0ea91b352888e2a8e9145ad7689986ff031508ffe1329c2f178731db956d82bf015d1212b02ec0ec69d7477c1ae954cbc06689f6a359894c0adebbf6b4e8020005aaa95551 The 3-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions: - x = x\_num / x\_den, where - x\_num = k\_(1,3) * x'^3 + k\_(1,2) * x'^2 + k\_(1,1) * x' + k\_(1,0) - x\_den = x'^2 + k\_(2,1) * x' + k\_(2,0) - y = y' * y\_num / y\_den, where - y\_num = k\_(3,3) * x'^3 + k\_(3,2) * x'^2 + k\_(3,1) * x' + k\_(3,0) - y\_den = x'^3 + k\_(4,2) * x'^2 + k\_(4,1) * x' + k\_(4,0) The constants used to compute x\_num are as follows: - k\_(1,0) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaaaaaaa97d6 + 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaaaaaaa97d6 * I - k\_(1,1) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71a * I - k\_(1,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71e + 0x8ab05f8bdd54cde190937e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ffffffffe38d * I - k\_(1,3) = 0x171d6541fa38ccfaed6dea691f5fb614cb14b4e7f4e810aa22d6108f142b85757098e38d0f671c7188e2aaaaaaaa5ed1 The constants used to compute x\_den are as follows: - k\_(2,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa63 * I - k\_(2,1) = 0xc + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa9f * I The constants used to compute y\_num are as follows: - k\_(3,0) = 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 + 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 * I - k\_(3,1) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaaaaaaa97be * I - k\_(3,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71c + 0x8ab05f8bdd54cde190937e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ffffffffe38f * I - k\_(3,3) = 0x124c9ad43b6cf79bfbf7043de3811ad0761b0f37a1e26286b0e977c69aa274524e79097a56dc4bd9e1b371c71c718b10 The constants used to compute y\_den are as follows: - k\_(4,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb * I - k\_(4,1) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa9d3 * I - k\_(4,2) = 0x12 + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa99 * I https://eips.ethereum.org/assets/eip-2537/field_to_curve https://eips.ethereum.org/assets/eip-2537/field_to_curve Test Vectors for EIP-2537 - Precompile for BLS12-381 curve operations / # Test Vectors for EIP-2537 - Precompile for BLS12-381 curve operations These test vectors are derived from [BLS 12-381 tests](https://github.com/ethereum/bls12-381-tests/tree/eip-2537) Note: `BLS12_G1MUL` is executed by the `BLS12_G1MULTIEXP` precompile and `BLS12_G2MUL` is executed by the `BLS12_G2MULTIEXP` precompile. - [`BLS12_G1ADD` Machine-readable data](/assets/eip-2537/add_G1_bls.json) - [`BLS12_G2ADD` Machine-readable data](/assets/eip-2537/add_G2_bls.json) - [`BLS12_G1MUL` Machine-readable data](/assets/eip-2537/mul_G1_bls.json) - [`BLS12_G2MUL` Machine-readable data](/assets/eip-2537/mul_G2_bls.json) - [`BLS12_G1MSM` Machine-readable data](/assets/eip-2537/msm_G1_bls.json) - [`BLS12_G2MSM` Machine-readable data](/assets/eip-2537/msm_G2_bls.json) - [`BLS12_PAIRING_CHECK` Machine-readable data](/assets/eip-2537/pairing_check_bls.json) - [`BLS12_MAP_FP_TO_G1` Machine-readable data](/assets/eip-2537/map_fp_to_G1_bls.json) - [`BLS12_MAP_FP2_TO_G2` Machine-readable data](/assets/eip-2537/map_fp2_to_G2_bls.json) - [Fail `BLS12_G1ADD` Machine-readable data](/assets/eip-2537/fail-add_G1_bls.json) - [Fail `BLS12_G2ADD` Machine-readable data](/assets/eip-2537/fail-add_G2_bls.json) - [Fail `BLS12_G1MUL` Machine-readable data](/assets/eip-2537/fail-mul_G1_bls.json) - [Fail `BLS12_G2MUL` Machine-readable data](/assets/eip-2537/fail-mul_G2_bls.json) - [Fail `BLS12_G1MSM` Machine-readable data](/assets/eip-2537/fail-msm_G1_bls.json) - [Fail `BLS12_G2MSM` Machine-readable data](/assets/eip-2537/fail-msm_G2_bls.json) - [Fail `BLS12_MAP_FP_TO_G1` Machine-readable data](/assets/eip-2537/fail-map_fp_to_G1_bls.json) - [Fail `BLS12_MAP_FP2_TO_G2` Machine-readable data](/assets/eip-2537/fail-map_fp2_to_G2_bls.json) - [Fail `BLS12_PAIRING_CHECK` Machine-readable data](/assets/eip-2537/fail-pairing_check_bls.json) https://eips.ethereum.org/assets/eip-2537/test-vectors https://eips.ethereum.org/assets/eip-2537/test-vectors Metadata standards / # Metadata standards This documentation consists of various JSON schemas (examples or standards) that can be referenced by the reader of this EIP for implementing EIP-3475 bonds storage. ## 1. Description metadata: ```json [ { "title": "defining the title information", "_type": "explaining the type of the title information added", "description": "little description about the information stored in the bond", } ] ``` Example: adding details in bonds describing the local jurisdiction of the bonds where it's issued: ```json { "title": "localisation", "_type": "string", "description": "jurisdiction law codes compatibility" "values": ["fr ", "de", "ch"] } ``` The 'values' field defined above can also be ISO codes or other hex standard representation. ## 2. Nonce metadata: - **Information defining the state of the bond** ```json [ { "title": "maturity", "_type": "uint", "description": "Lorem ipsum...", "values": [0, 0, 0] } ] ``` ## 3. Class metadata: ```json [ { "title": "symbol", "_type": "string", "description": "Lorem ipsum...", "values": ["Class symbol 1", "Class symbol 2", "Class symbol 3"], }, { "title": "issuer", "_type": "string", "description": "Lorem ipsum...", "values": ["Issuer name 1", "Issuer name 2", "Issuer name 3"], }, { "title": "issuer_address", "_type": "address", "description": "Lorem ipsum...", "values":["Address 1.", "Address 2", "Address 3"] }, { "title": "class_type", "_type": "string", "description": "Lorem ipsum...", "values": ["Class Type 1", "Class Type 2", "Class Type 3"] }, { "title": "token_address", "_type": "address", "description": "Lorem ipsum...", "values":["Address 1.", "Address 2", "Address 3"] }, { "title": "period", "_type": "uint", "description": "Lorem ipsum...", "values": [0, 0, 0] } ] ``` ## Examples of other standards: - ISO-20022 standard is the recently adopted standard by banks for communicating financial operators (Banks, trading intermediaries, underwriters) that also include bond operations. https://eips.ethereum.org/assets/eip-3475/Metadata https://eips.ethereum.org/assets/eip-3475/Metadata Bundler Full Sequence Diagram / # Bundler Full Sequence Diagram ```plantuml title UserOperations mempool flow actor Alice actor Bob participant "Bundler RPC" participant "Ethereum RPC" participant "UserOp Mempool" group Alice Submits UserOp note right of Alice: create UserOp Alice->"Bundler RPC": ""eth_sendUserOperation"" "Bundler RPC"->"Ethereum RPC": First Validation\ntrace view call to:\n""handleOps([userOpA]"") "Bundler RPC"->"UserOp Mempool": add ""UserOp"" to mempool end ||| group Bob Submits UserOp note right of Bob: create UserOp Bob->"Bundler RPC": ""eth_sendUserOperation"" "Bundler RPC"->"Ethereum RPC": First Validation\ntrace view call to\n""handleOps([userOpB]"") "Bundler RPC"->"UserOp Mempool": add ""UserOp"" to mempool end ||| group Build Bundle "Bundler RPC"->"UserOp Mempool": fetch pending ""UserOps"" return ""[UserOpA, UserOpB]"" ||| loop for each UserOp "Bundler RPC"->"Ethereum RPC": Second Validation\ntrace view call to:\n""handleOps([userOp])"" ||| end note right of "Bundler RPC": create bundle ""[UserOpA, UserOpB]"" "Bundler RPC"->"Ethereum RPC": Third Validation\ntrace view call to:\n""handleOps([UserOpA, UserOpB])"" ||| "Bundler RPC"->"Ethereum RPC": submit transaction\n""handleOps([UserOpA, UserOpB])"" ||| end ``` # Bundle Sequence Diagram (Without factory) ```plantuml @startuml autonumber participant "EntryPoint" as ep participant "Account A" as account participant "Account B" as account2 [->ep++ #gold: ""handleOps(userOps[])"": group Validations ||| ep->account++ #blue: <font color=blue> ""validateUserOp"" return ""deposit"" ||| ep->ep: deduct ""Account_A"" deposit ||| ep->account2++ #green: <font color=green> ""validateUserOp"" return ""deposit"" ||| ep->ep: deduct ""Account_B"" deposit ||| end group Executions ||| ep->account++ #blue: <font color=blue> ""executeUserOp"" deactivate account ep->ep: refund ""Account_A"" ||| ep->account2++ #green: <font color=green> ""executeUserOp"" deactivate account2 ep->ep: refund ""Account_B"" ||| end ep-->[: ""compensate(beneficiary)"" hide footbox ``` # Bundle Sequence Diagram (with Paymaster) ```plantuml @startuml autonumber participant "EntryPoint" as ep participant "Account" as account participant "Paymaster" as pm [->ep++ #gold: ""handleOps(userOps[])"": group Validation ||| ep->account++ #blue: <font color=blue> ""validateUserOp"" deactivate account ep->pm++ #gray: ""validatePaymasterUserOp"" deactivate pm ep->ep: deduct ""Paymaster"" deposit ||| end group Execution ||| ep->account++ #blue: <font color=blue> ""executeUserOp"" deactivate account ep->pm++ #gray: ""postOp"" deactivate pm ep->ep: refund paymaster ||| end ep-->[: ""compensate(beneficiary)"" hide footbox ``` # Bundle Sequence Diagram (with Factory) ```plantuml @startuml autonumber participant "EntryPoint" as ep participant "Factory" as fact participant "Account" as account participant "Account2" as account2 [->ep++ #gold: handleOps(userOps[]): group Validations ep->fact++ #gray: create (initCode) fact->o account: create return account ep->account++ #blue: <font color=blue> validateUserOp return deposit ep->ep: deduct account deposit ep->account2++ #green: <font color=green> validateUserOp return deposit ep->ep: deduct account2 deposit end group Executions ep->account++ #blue: <font color=blue> exec deactivate account ep->ep: refund account1 ep->account2++ #green: <font color=green> exec deactivate account2 ep->ep: refund account2 end ep-->[: compensate(beneficiary) hide footbox ``` https://eips.ethereum.org/assets/eip-4337/diagrams https://eips.ethereum.org/assets/eip-4337/diagrams SemVer Authors / SemVer Authors ============== The following people have modified the Semantic Versioning 2.0.0 specification: - Tom Preston-Werner - Phil Haack - Haacked - isaacs - Thijs Schreijer - jeffhandley - Alexandr Tovmach - Adam Ralph - Eddie Garmon - Jeff Handley - Krzysztof Piasecki - Doug Beck - Gert de Pagter - Guillermo Calvo - Iulian Onofrei - Ivan Bessarabov - Jo Liss - Johanan Liebermann - Joseph Donahue - Konstantin - Kristian Glass - Mark Amery - OGINO Masanori - Oguz Bilgic - Slipp Douglas - Thomas Schraitle - Tim Vergenz - Todd Reed - Tristram Oaten - Wincent Colaiuta - alexandrtovmach - wolf99 https://eips.ethereum.org/assets/eip-5139/AUTHORS https://eips.ethereum.org/assets/eip-5139/AUTHORS Semantic Versioning 2.0.0 / Semantic Versioning 2.0.0 ============================== Summary ------- Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 1. MINOR version when you add functionality in a backwards compatible manner, and 1. PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Introduction ------------ In the world of software management there exists a dreaded place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair. In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward. As a solution to this problem, we propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version. We call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next. Semantic Versioning Specification (SemVer) ------------------------------------------ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive. 1. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. 1. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version. 1. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. 1. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes. 1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior. 1. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 1. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented. 1. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--. 1. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD. 1. Precedence refers to how versions are compared to each other when ordered. 1. Precedence MUST be calculated by separating the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence). 1. Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. 1. When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version: Example: 1.0.0-alpha < 1.0.0. 1. Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: 1. Identifiers consisting of only digits are compared numerically. 1. Identifiers with letters or hyphens are compared lexically in ASCII sort order. 1. Numeric identifiers always have lower precedence than non-numeric identifiers. 1. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. Backus–Naur Form Grammar for Valid SemVer Versions -------------------------------------------------- ``` <valid semver> ::= <version core> | <version core> "-" <pre-release> | <version core> "+" <build> | <version core> "-" <pre-release> "+" <build> <version core> ::= <major> "." <minor> "." <patch> <major> ::= <numeric identifier> <minor> ::= <numeric identifier> <patch> ::= <numeric identifier> <pre-release> ::= <dot-separated pre-release identifiers> <dot-separated pre-release identifiers> ::= <pre-release identifier> | <pre-release identifier> "." <dot-separated pre-release identifiers> <build> ::= <dot-separated build identifiers> <dot-separated build identifiers> ::= <build identifier> | <build identifier> "." <dot-separated build identifiers> <pre-release identifier> ::= <alphanumeric identifier> | <numeric identifier> <build identifier> ::= <alphanumeric identifier> | <digits> <alphanumeric identifier> ::= <non-digit> | <non-digit> <identifier characters> | <identifier characters> <non-digit> | <identifier characters> <non-digit> <identifier characters> <numeric identifier> ::= "0" | <positive digit> | <positive digit> <digits> <identifier characters> ::= <identifier character> | <identifier character> <identifier characters> <identifier character> ::= <digit> | <non-digit> <non-digit> ::= <letter> | "-" <digits> ::= <digit> | <digit> <digits> <digit> ::= "0" | <positive digit> <positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" <letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ``` Why Use Semantic Versioning? ---------------------------- This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that "close" isn't good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made. A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past. Consider a library called "Firetruck." It requires a Semantically Versioned package named "Ladder." At the time that Firetruck is created, Ladder is at version 3.1.0. Since Firetruck uses some functionality that was first introduced in 3.1.0, you can safely specify the Ladder dependency as greater than or equal to 3.1.0 but less than 4.0.0. Now, when Ladder version 3.1.1 and 3.2.0 become available, you can release them to your package management system and know that they will be compatible with existing dependent software. As a responsible developer you will, of course, want to verify that any package upgrades function as advertised. The real world is a messy place; there's nothing we can do about that but be vigilant. What you can do is let Semantic Versioning provide you with a sane way to release and upgrade packages without having to roll new versions of dependent packages, saving you time and hassle. If all of this sounds desirable, all you need to do to start using Semantic Versioning is to declare that you are doing so and then follow the rules. Link to this website from your README so others know the rules and can benefit from them. FAQ --- ### How should I deal with revisions in the 0.y.z initial development phase? The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release. ### How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0. ### Doesn't this discourage rapid development and fast iteration? Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version. ### If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly? This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you'll think through the impact of your changes, and evaluate the cost/benefit ratio involved. ### Documenting the entire public API is too much work! It is your responsibility as a professional developer to properly document software that is intended for use by others. Managing software complexity is a hugely important part of keeping a project efficient, and that's hard to do if nobody knows how to use your software, or what methods are safe to call. In the long run, Semantic Versioning, and the insistence on a well defined public API can keep everyone and everything running smoothly. ### What do I do if I accidentally release a backwards incompatible change as a minor version? As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version. ### What should I do if I update my own dependencies without changing the public API? That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it's obviously a minor level increment. ### What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release)? Use your best judgment. If you have a huge audience that will be drastically impacted by changing the behavior back to what the public API intended, then it may be best to perform a major version release, even though the fix could strictly be considered a patch release. Remember, Semantic Versioning is all about conveying meaning by how the version number changes. If these changes are important to your users, use the version number to inform them. ### How should I handle deprecating functionality? Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API. ### Does SemVer have a size limit on the version string? No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string. ### Is "v1.2.3" a semantic version? No, "v1.2.3" is not a semantic version. However, prefixing a semantic version with a "v" is a common way (in English) to indicate it is a version number. Abbreviating "version" as "v" is often seen with version control. Example: `git tag v1.2.3 -m "Release version 1.2.3"`, in which case "v1.2.3" is a tag name and the semantic version is "1.2.3". ### Is there a suggested regular expression (RegEx) to check a SemVer string? There are two. One with named groups for those systems that support them (PCRE [Perl Compatible Regular Expressions, i.e. Perl, PHP and R], Python and Go). See: <https://regex101.com/r/Ly7O1x/3/> ``` ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ ``` And one with numbered capture groups instead (so cg1 = major, cg2 = minor, cg3 = patch, cg4 = prerelease and cg5 = buildmetadata) that is compatible with ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions, i.e. Perl, PHP and R), Python and Go. See: <https://regex101.com/r/vkijKf/1/> ``` ^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ ``` About ----- The Semantic Versioning specification was originally authored by [Tom Preston-Werner](https://tom.preston-werner.com), inventor of Gravatar and cofounder of GitHub. If you'd like to leave feedback, please [open an issue on GitHub](https://github.com/semver/semver/issues). License ------- [Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) https://eips.ethereum.org/assets/eip-5139/semver https://eips.ethereum.org/assets/eip-5139/semver / Here is a copy of the tl;dr section from an [extended analysis](https://hackmd.io/@adrninistrator1/SkHmz972n) of `pubkey2index` and `index2pubkey` cache usage provided by Navie Chan: tl;dr: `index2Pubkey` is used in a lot more scenarios than `pubkey2Index`. The use cases for `index2Pubkey` do not require unfinalized information. `process_deposit()` is the only place in consensus spec that needs unfinalized information and it utilizes `pubkey2Index`. In terms of the two-cache approach, `unfinalizedIndex2Pubkey` is not needed since there is not a place that utilizes it. `unfinalizedPubkey2Index`, however, is needed for `process_deposit()`. | | unfinalized pubkey2Index? | unfinalized index2Pubkey? | |-|-|-| | onBlock - state_transition - verify_block_signature | N/A | No | | onBlock - state_transition - process_block - process_randao | N/A | No | | onBlock - state_transition - process_block - process_operations - process_proposer_slashing | N/A | No | | onBlock - state_transition - process_block - process_operations - process_attester_slashing - is_valid_indexed_attestation | N/A | No | | onBlock - state_transition - process_block - process_operations - process_attestation - is_valid_indexed_attestation | N/A | No | | onBlock - state_transition - process_block - process_operations - process_deposit - apply_deposit | Yes | N/A | | onBlock - state_transition - process_block - process_operations - process_sync_aggregate - eth_fast_aggregate_verify | No | No | | onBlock - state_transition - process_block - process_bls_to_execution_change | N/A | N/A | | onBlock - state_transition - process_block - process_voluntary_exit | N/A | No | | p2p - beacon_block ---- onBlock | N/A | No | | p2p - beacon_aggregate_and_proof ---- onAttestation | N/A | No | | p2p - voluntary_exit - process_voluntary_exit | N/A | No | | p2p - proposer_slashing - process_proposer_slashing | N/A | No | | p2p - attester_slashing - process_attester_slashing | N/A | No | | p2p - beacon_attestation_{subnet_id} ---- onAttestation | N/A | No | | p2p - sync_committee_contribution_and_proof | N/A | No | | p2p - sync_committee_{subnet_id} | N/A | No | | p2p - bls_to_execution_change - process_bls_to_execution_change | N/A | N/A | | p2p - blob_sidecar_{subnet_id} - verify_blob_sidecar_signature | N/A | No | https://eips.ethereum.org/assets/eip-6110/pubkey_to_index_cache_analysis https://eips.ethereum.org/assets/eip-6110/pubkey_to_index_cache_analysis / [Modified version](/assets/eip-6110/eth2_ws_calc.py) of a [script](https://gist.github.com/adiasg/3aceab409b36aa9a9d9156c1baa3c248) shows the following changes in the WS period computations with increase of a number of deposits per epoch (deviations are highlighted): | Safety Decay | Avg. Val. Balance (ETH) | Val. Count | WS (Epochs), `16` deposits per slot | WS (Epochs), `1024` deposits per slot | | ---- | ---- | ---- | ---- | ---- | | 10 | 20 | 32768 | 272 | **256** | | 10 | 20 | 65536 | 288 | **256** | | 10 | 20 | 131072 | 320 | **257** | | 10 | 20 | 262144 | 384 | **258** | | 10 | 20 | 524288 | 512 | **260** | | 10 | 20 | 1048576 | 768 | **264** | | 10 | 24 | 32768 | 310 | 310 | | 10 | 24 | 65536 | 365 | 365 | | 10 | 24 | 131072 | 474 | 474 | | 10 | 24 | 262144 | 692 | 692 | | 10 | 24 | 524288 | 692 | 692 | | 10 | 24 | 1048576 | 1041 | **504** | | 10 | 28 | 32768 | 504 | 504 | | 10 | 28 | 65536 | 752 | 752 | | 10 | 28 | 131072 | 1248 | 1248 | | 10 | 28 | 262144 | 2241 | 2241 | | 10 | 28 | 524288 | 2241 | 2241 | | 10 | 28 | 1048576 | 2241 | 2241 | | 10 | 32 | 32768 | 665 | 665 | | 10 | 32 | 65536 | 1075 | 1075 | | 10 | 32 | 131072 | 1894 | 1894 | | 10 | 32 | 262144 | 3532 | 3532 | | 10 | 32 | 524288 | 3532 | 3532 | | 10 | 32 | 1048576 | 3532 | 3532 | https://eips.ethereum.org/assets/eip-6110/ws_period_analysis https://eips.ethereum.org/assets/eip-6110/ws_period_analysis / MIT License Copyright (c) 2023 Authentic Vision GmbH Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. https://eips.ethereum.org/assets/eip-6956/LICENSE https://eips.ethereum.org/assets/eip-6956/LICENSE Withdrawal requests fee analysis / # Withdrawal requests fee analysis Analysis of the following parameters of the Withdrawal request smart contract: * `MAX_WITHDRAWAL_REQUESTS_PER_BLOCK = 16` * `TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK = 2` **TL; DR:** These parameters have reasonable values. ## Consensus layer with TARGET=2, MAX=16 Full withdrawal requests doesn't create additional data complexity on the CL side as the changes are applied to the list of validators. Current exit churn size allows to initiate withdrawal for 256 ETH per epoch, if a number of request per epoch is at its level (`32 * MAX = 512` requests) then the average withdrawing amount should be no bigger than `0.5 ETH` to fit the churn. It is not unreasonable to assume that most of the time this limit will be satisfied. Partial withdrawals has a separate list which processing depends on the exit churn. If there is enough churn then pending partial withdrawal request will be processed at least `MIN_VALIDATOR_WITHDRAWABILITY_DELAY = 256` epochs after it was queued on the CL. This delay sets a lower boundary on the number of pending withdrawals in the queue in a situation when each block has `MAX=16` requests, it is `256 * 32 * 16 = 131,072`, which is `3 MB` of data. In an extreme case scenario when e.g. ~10% of validators are exiting this number can grow up to `192 MB`. With `TARGET=2` requests per each block the above numbers are reduced to `0.375 MB` and `24 MB` respectively. Average amount for a partial withdrawal increases up to `4.0 ETH`. ## Attack via prohibitive fee Full withdrawal requests are a security mechanism and an attacker can potentially benefit from block this functionality by keep the request fee at a prohibitive level. This section explores such attack with more details. The cost of attack includes two parts. First part is to raise the fee to a certain level (the base cost) and the second part is to keep the fee at that level (per block cost). The fee is updated at the end of the block processing, so it remains the same regardless of a number of requests submitted within one block. The lowest fee is `1 Wei` which makes the base cost of this attack near to `0`. The cost per block is computed as `prohibitive_fee * TARGET`. There are two ways to increase the cost: * Raise fee upon each request -- affects mostly the base cost, has a slight effect on the cost per block * Increase `TARGET` -- affects the cost per block The cost of attack with the status quo and above improvements are provided in the table below. The second cost is the cost per hour of such attack, i.e. cost per block times `300` (number of slots per hour). | Fee | TARGET=2 | TARGET=2 + fine-grained fee | TARGET=8 | |-|-|-|-| | 0.0001 ETH | 0.06 ETH | 0.07 ETH | 0.25 ETH | | 0.01 ETH | 6.25 ETH | 6.61 ETH | 25.00 ETH | | 0.1 ETH | 61.98 ETH | 65.56 ETH | 247.92 ETH | | 0.5 ETH | 303.39 ETH | 320.93 ETH | 1213.58 ETH | | 1 ETH | 614.59 ETH | 650.10 ETH | 2458.37 ETH | | 2 ETH | 1244.95 ETH | 1316.90 ETH | 4979.79 ETH | | 4 ETH | 2521.76 ETH | 2667.53 ETH | 10087.02 ETH | To summarize: * raising fee upon each requests increases the cost of an hour of attack by _~6%_, while `TARGET=8` makes the 4 times increase * with the status quo the attack is not sustainable long term ## UX Assuming `1 Gwei` to be a reasonable fee per request, it will take 2.75 hours for the fee to reach this level if someone submits 2,000 requests in one block (the max possible number to fit in 30M gas block). From the UX standpoint it might seem quite long, but `TARGET=2`, comparing to e.g. `TARGET=8`, reduces the strain on the protocol by more efficiently rate limiting the growth of the EL and CL queues. https://eips.ethereum.org/assets/eip-7002/fee_analysis https://eips.ethereum.org/assets/eip-7002/fee_analysis Appendix: Interoperability Analysis / ## Appendix: Interoperability Analysis We provide a cherrypicked list of possible points of contact between ERC-7208 and other tokenization standards and proposals. **ERC-1400 (Security Token Standard)**: This ERC provides a suite of standard interfaces for issuing/redeeming security tokens, managing their ownership and transfer restrictions, and providing transparency to token holders on how different subsets of their token balance behave with respect to transfer restrictions, rights and obligations. ERC-7208 can enhance ERC-1400 by offering a dynamic and flexible data management architecture. **Data Objects** enable the storage and modification of on-chain data for security tokens, such as compliance information or ownership details. Assets already issued under ERC-1400 can be wrapped into a **Vault Data Object** and exposed through any **Data Manager** interface (including **ERC-3643**). Additionally, ERC-7208 enablesthe fractionalization of ERC-1400 assets. If the asset is issued through an ERC-1400 **Data Manager** with native **Data Object** storage, the integration could lead to more versatile and transparent security token offerings, as a custom Identity Management logic can be embedded within the assets. **EIP-2981 (Royalties)**: ERC-7208 can complement EIP-2981 as a **Data Manager** by providing a flexible way to handle royalties. **Data Objects** can store and manage the low-level storage of royalty information dynamically, independently from the interface used by the end user. This enables a complex royalty structure that can change over time or respond to predefined conditions, like embedding compliance checks and simultaneously exposing multiple interfaces for fractional ownership of the underlying asset. For instance, by leveraging ERC-7208, an individual royalty-based NFT can be traded in a compliant manner, concurrently under both an ERC-721 interface as well as an ERC-20 through the use of **Data Managers** that delegate their internal storage onto the **Data Object**. **ERC-3643 (Security Tokens)**: ERC-3643 defines a *Security Token interface for Regulated Exchanges* based on ERC-20 token standard. The ERC-7208 can be used for wrapping many tokens (irrespective of their ERC) and adapting their logic to the ERC-3643. Additionally, a **Data Object** storing native ERC-3643 asset data can be used for improving the compliance logic and enabling the trading of underlying securities simultaneously through multiple interfaces that respond to different regulatory frameworks. Moreover, the separation of the storage enables the logic to implement functionalities that were not initially a part of the original ERC-3643, such as identity-based recovery of assets, role-based access control, the introduction of cross-chain support, etc. **ERC-4337 (Account Abstraction)**: ERC-7208 can provide a standardized method to store and manage the complex data structures required by abstracted accounts. This can include user preferences, access control lists, recovery options, and other customizable account features. The mutable states of abstracted accounts can be efficiently handled using **Data Objects**. This, in turn, improves the adaptability and security of abstracted accounts. Additionally, an ERC-7208 implementation supporting meta-transactions and **Data Points** separated by chain-id can be developed to fully abstract account management across blockchains. **EIP-4626 (Tokenized Vaults)**: Tokenized Vaults inherit from a single ERC-20 and ERC-2612 for approvals via EIP-712 secp256k1 signatures. ERC-7208 can enhance EIP-4626 by providing a more dynamic data layer for tokenized vaults. **Data Objects** store information about the assets in the vault, conditions for access, or other relevant data, enabling more nuanced interactions with tokenized vaults. Additionally, the **Data Point** can store more than a single ERC-20, greatly increasing the capabilities of Tokenized Vaults. **ERC-4907 (Shared Ownership)**: The integration of ERC-4907 as a **Data Manager** with ERC-7208 **Data Point** storage can enhance the rental experience by allowing for additional rental-related data directly on-chain, such as rental terms, user permissions, and other customizable settings which would be self-contained within **Data Points** and therefore automatically updated as metadata. ERC-4907's rental mechanism complements ERC-7208's ability to manage mutable on-chain data. By combining these two, NFTs can not only be rented out for specific periods but also have their traits or states dynamically managed and updated during the rental period. This combination enhances security and compliance in NFT transactions, particularly for *Real World Asset Tokenization*. Rental agreements, regulatory compliance, intellectual property, and user rights can be embedded within Data Objects to ensure that the NFT usage adheres to predefined rules. **ERC-7540 (Asynchronous ERC-4626 Tokenized Vaults)**: ERC-7540 vaults's are focused on asynchronous deposit and redemption. Integrating ERC-7540, either by Wrapping into a **Data Object** or by exposing an ERC-7208 **Data Manager**, will facilitate more complex financial products. DeFi products like undercollateralized loans, insurance products, or tokenized stocks often require operations to be handled in a non-instantaneous manner. However, the nature of these products requires adhering to regulatory compliance and identity management solutions. This can easily be achieved by implementing the use of on-chain adapters that enhance the logic while keeping the data secure. https://eips.ethereum.org/assets/eip-7208/erc-7208-compat https://eips.ethereum.org/assets/eip-7208/erc-7208-compat Complexity analysis / # Complexity analysis ## Network aggregates Data complexity of the network aggregates does not increase as the new validity condition for the `beacon_aggregate_and_proof` gossipsub topic ensures that every network aggregate comprises a single committee. ## On chain aggregates ![image](/assets/eip-7549/on_chain_aggregates.png) The above plot shows potential optimisation effect of the proposed change. Namely, it is roughly 18KB to 4KB reduction in the size of a 64-committee aggregate for a 1 million validator set. Note that these numbers assume perfect aggregation. ### `MAX_ATTESTATIONS` `MAX_ATTESTATIONS` parameter should be adjusted respectively to avoid increase of the block size. ![image](/assets/eip-7549/max_attestations.png) The above plot suggests `MAX_ATTESTATIONS = 8` as a reasonable limitation. Which means that assuming perfect aggregation the attestation capacity of the block increases from `128` committees to `8*64 = 512` committees, i.e. from `2` slots worth of attestations to `8`. ## Attester slashing The plot below shows different variations of attester slashing data complexity. Numbers e.g. 64 vs 64 mean a number of committees which validator indices are represented by the corresponding `IndexedAttestation` structure. For instance, today every on chain aggregate comprises a single committee thus the worst case attester slashing produced from on chain aggregates will have two indexed attestations with `1_000_000 / 32 / 64 = 488` validator indices each, which is roughly `8 KB` of uncompressed data. With the proposed change an attester slashing obtained in the same way could require `488 KB` of uncompressed data because it could contain indices from up to 64 committees instead of just 1. ![image](/assets/eip-7549/attester_slashing.png) Note that in the case of attack entailing mass slashing the overall complexity of attester slashing data with the proposed change remains the same as it is with the status quo. However, the proposed changed increases the size of the beacon block as each slashing will contain up to 64 times more indices than with the status quo. The positive outcome here is that all slashable attestations can be processed during roughly one epoch (EIP-7549 makes this already possible). The red line on the plot represents the case when one of the indexed attestations is obtained from an on chain aggregate and the other one from a network aggregate. Moreover, with the proposed change it is still possible to create a slashing from two network aggregates. Therefore, complexity of attester slashing data in case of a single slashing event depends on the _slasher database schema, i.e. whether or not a slasher has access to network aggregates_. `MAX_ATTESTER_SLASHINGS = 1` is suggested to alleviate the increase of the attester slashing complexity. ### Compressed validator indices Intuitively validator indices should compress well as there is just `20` bits of useful information per each validator index in the case of `1_000_000` validator set size. So `488 KB` of attester slashing data (the worst case) can be reduced to `153 KB` by employing a trivial compression algorithm. _AttesterSlashing with 64x64 committees (1_000_000 validators) takes 320KB if compressed by Snappy (checked with PySpec SSZ test suite)._ https://eips.ethereum.org/assets/eip-7549/complexity_analysis https://eips.ethereum.org/assets/eip-7549/complexity_analysis Semantic Versioning 2.0.0 / Semantic Versioning 2.0.0 ============================== Summary ------- Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 1. MINOR version when you add functionality in a backwards compatible manner, and 1. PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Introduction ------------ In the world of software management there exists a dreaded place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair. In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward. As a solution to this problem, we propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version. We call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next. Semantic Versioning Specification (SemVer) ------------------------------------------ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive. 1. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. 1. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version. 1. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. 1. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes. 1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior. 1. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 1. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented. 1. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--. 1. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD. 1. Precedence refers to how versions are compared to each other when ordered. 1. Precedence MUST be calculated by separating the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence). 1. Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. 1. When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version: Example: 1.0.0-alpha < 1.0.0. 1. Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: 1. Identifiers consisting of only digits are compared numerically. 1. Identifiers with letters or hyphens are compared lexically in ASCII sort order. 1. Numeric identifiers always have lower precedence than non-numeric identifiers. 1. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. Backus–Naur Form Grammar for Valid SemVer Versions -------------------------------------------------- ``` <valid semver> ::= <version core> | <version core> "-" <pre-release> | <version core> "+" <build> | <version core> "-" <pre-release> "+" <build> <version core> ::= <major> "." <minor> "." <patch> <major> ::= <numeric identifier> <minor> ::= <numeric identifier> <patch> ::= <numeric identifier> <pre-release> ::= <dot-separated pre-release identifiers> <dot-separated pre-release identifiers> ::= <pre-release identifier> | <pre-release identifier> "." <dot-separated pre-release identifiers> <build> ::= <dot-separated build identifiers> <dot-separated build identifiers> ::= <build identifier> | <build identifier> "." <dot-separated build identifiers> <pre-release identifier> ::= <alphanumeric identifier> | <numeric identifier> <build identifier> ::= <alphanumeric identifier> | <digits> <alphanumeric identifier> ::= <non-digit> | <non-digit> <identifier characters> | <identifier characters> <non-digit> | <identifier characters> <non-digit> <identifier characters> <numeric identifier> ::= "0" | <positive digit> | <positive digit> <digits> <identifier characters> ::= <identifier character> | <identifier character> <identifier characters> <identifier character> ::= <digit> | <non-digit> <non-digit> ::= <letter> | "-" <digits> ::= <digit> | <digit> <digits> <digit> ::= "0" | <positive digit> <positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" <letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ``` Why Use Semantic Versioning? ---------------------------- This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that "close" isn't good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made. A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past. Consider a library called "Firetruck." It requires a Semantically Versioned package named "Ladder." At the time that Firetruck is created, Ladder is at version 3.1.0. Since Firetruck uses some functionality that was first introduced in 3.1.0, you can safely specify the Ladder dependency as greater than or equal to 3.1.0 but less than 4.0.0. Now, when Ladder version 3.1.1 and 3.2.0 become available, you can release them to your package management system and know that they will be compatible with existing dependent software. As a responsible developer you will, of course, want to verify that any package upgrades function as advertised. The real world is a messy place; there's nothing we can do about that but be vigilant. What you can do is let Semantic Versioning provide you with a sane way to release and upgrade packages without having to roll new versions of dependent packages, saving you time and hassle. If all of this sounds desirable, all you need to do to start using Semantic Versioning is to declare that you are doing so and then follow the rules. Link to this website from your README so others know the rules and can benefit from them. FAQ --- ### How should I deal with revisions in the 0.y.z initial development phase? The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release. ### How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0. ### Doesn't this discourage rapid development and fast iteration? Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version. ### If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly? This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you'll think through the impact of your changes, and evaluate the cost/benefit ratio involved. ### Documenting the entire public API is too much work! It is your responsibility as a professional developer to properly document software that is intended for use by others. Managing software complexity is a hugely important part of keeping a project efficient, and that's hard to do if nobody knows how to use your software, or what methods are safe to call. In the long run, Semantic Versioning, and the insistence on a well defined public API can keep everyone and everything running smoothly. ### What do I do if I accidentally release a backwards incompatible change as a minor version? As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version. ### What should I do if I update my own dependencies without changing the public API? That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it's obviously a minor level increment. ### What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release)? Use your best judgment. If you have a huge audience that will be drastically impacted by changing the behavior back to what the public API intended, then it may be best to perform a major version release, even though the fix could strictly be considered a patch release. Remember, Semantic Versioning is all about conveying meaning by how the version number changes. If these changes are important to your users, use the version number to inform them. ### How should I handle deprecating functionality? Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API. ### Does SemVer have a size limit on the version string? No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string. ### Is "v1.2.3" a semantic version? No, "v1.2.3" is not a semantic version. However, prefixing a semantic version with a "v" is a common way (in English) to indicate it is a version number. Abbreviating "version" as "v" is often seen with version control. Example: `git tag v1.2.3 -m "Release version 1.2.3"`, in which case "v1.2.3" is a tag name and the semantic version is "1.2.3". ### Is there a suggested regular expression (RegEx) to check a SemVer string? There are two. One with named groups for those systems that support them (PCRE [Perl Compatible Regular Expressions, i.e. Perl, PHP and R], Python and Go). See: <https://regex101.com/r/Ly7O1x/3/> ``` ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ ``` And one with numbered capture groups instead (so cg1 = major, cg2 = minor, cg3 = patch, cg4 = prerelease and cg5 = buildmetadata) that is compatible with ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions, i.e. Perl, PHP and R), Python and Go. See: <https://regex101.com/r/vkijKf/1/> ``` ^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ ``` About ----- The Semantic Versioning specification was originally authored by [Tom Preston-Werner](https://tom.preston-werner.com), inventor of Gravatar and cofounder of GitHub. If you'd like to leave feedback, please [open an issue on GitHub](https://github.com/semver/semver/issues). License ------- [Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) https://eips.ethereum.org/assets/eip-7577/semver https://eips.ethereum.org/assets/eip-7577/semver Set of test vectors to perform benchmarking of EIP-7619 / # Set of test vectors to perform benchmarking of EIP-7619 ## Inlined vectors Here is the list of well formatted and valid signature vectors to perform benchmarking. These vectors were based on [original falcon test vectors](https://falcon-sign.info/). Original vectors were encoded using abiEcodeWithSignature taking the message, public key, and signature as inputs. The method signature is `verify(bytes,bytes,bytes)` ``` [{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002903933b3c07507e4201748494d832b6ee2a6c93bff9b0ee343b550d1f85a3d0de0d704c6d178429513090765843d1e460d17a527d2bca405bd55bbc7da09a8c620be0af4a767d9db96b80f55e466676751eaaba7b93b86d71132daa0eb376782b9eee37519ce10fdd33fe9f29312c31d8736206d165cf4c528aa3ddc017845e1f0dd5b0a44ff961c42d874a95533e5b438982f524ca954d87533bfbe42c63ff2abc77a34c79db55a99171bbcb72c842a6530af2f753f0c34ac632f9f1e7949f0bf6c67665b27722a8857d626b6ff1a136d923a39f4069b7477ff946e5247a6627791d49b59edc9e2525a860e6e9828d18f64a9f17222e8166a02453859bbda0b8186d8c9928bb571e4146401d7430e225904673ad21ccac54c146c248a1dd69ab6491e901d6d71b152155be97de057f3916a3f1b4273308c29b2f4d9697167b90681b1583ed930a71e990467dea368134beceebd597f9bec922e816f1b0570d728f4ae0464c1f797657f87a4e52dcdcaeb9272662ea66d7c6cd8781b31af555ad93f5f65e75816cb8dc306bb67e592b5261baca7c509629ea2af8abb80cba89ee535b76dfd9ccbbe3bf48f2bc8aa34b26e1103291053f5cb8de3a45afa5a76df8b2122ed2c82fbcf2259290d41a14f86b12f35f5d49762b34cff13ee7e42edec70201d7f37c33316288fa3078e36e58108865c3cfe263d563692043decc62f3426f86061285b7b1b336f56ff41bb65e9cd6d9b92fd90f864aa1c923cb8c755f5cde1770d862595427149d7721aaab5d194aea9acdeca15be43cba6a62b5a33909e9fc4da1c5814fbd7cd6a2fa572e318b42c6c319140b86e66392580a11a2b431f44c1f9270e4f7b2490f3b325a9977a71a575915636635b9969dbd6d220b24c3d99cebbbd834b88222bd08c3abe124e80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381096ba86cb658a8f445c9a5e4c28374bec879c8655f68526923240918074d0147c03162e4a49200648c652803c6fd7509ae9aa799d6310d0bd42724e0635920186207000767ca5a8546b1755308c304b84fc93b069e265985b398d6b834698287ff829aa820f17a7f4226ab21f601ebd7175226bab256d8888f009032566d6383d68457ea155a94301870d589c678ed304259e9d37b193bc2a7ccbcbec51d69158c44073aec9792630253318bc954dbf50d15028290dc2d309c7b7b02a6823744d463da17749595cb77e6d16d20d1b4c3aad89d320ebe5a672bb96d6cd5c1efec8b811200cbb062e473352540eddef8af9499f8cdd1dc7c6873f0c7a6bcb7097560271f946849b7f373640bb69ca9b518aa380a6eb0a7275ee84e9c221aed88f5bfbaf43a3ede8e6aa42558104faf800e018441930376c6f6e751569971f47adbca5ca00c801988f317a18722a29298925ea154dbc9024e120524a2d41dc0f18fd8d909f6c50977404e201767078ba9a1f9e40a8b2ba9c01b7da3a0b73a4c2a6b4f518bbee3455d0af2204ddc031c805c72ccb647940b1e6794d859aaebcea0deb581d61b9248bd9697b5cb974a8176e8f910469cae0ab4ed92d2aee9f7eb50296daf8057476305c1189d1d9840a0944f0447fb81e511420e67891b98fa6c257034d5a063437d379177ce8d3fa6eaf12e2dbb7eb8e498481612b1929617da5fb45e4cdf893927d8ba842aa861d9c50471c6d0c6df7e2bb26465a0eb6a3a709de792aafaaf922aa95dd5920b72b4b8856c6e632860b10f5cc08450003671af388961872b466400adb815ba81ea794945d19a100622a6ca0d41c4ea620c21dc125119e372418f04402d9fa7180f7bc89afa54f8082244a42f46e5b5abce87b50a7d6febe8d7bbbac92657cbda1db7c25572a4c1d0baea30447a865a2b1036b880037e2f4d26d453e9e913259779e9169b28a62eb809a5c744e04e260e1f2bbda874f1ac674839ddb47b3148c5946de0180148b7973d63c58193b17cd05d16e80cd7928c2a338363a23a81c0608c87505589b9da1c617e7b70786b6754fbb30a5816810b9e126cfcc5aa49326e9d842973874b6359b5db75610ba68a98c7b5e83f125a82522e13b83fb8f864e2a97b73b5d544a7415b6504a13939eab1595d64faf41fab25a864a574de524405e878339877886d2fc07fa0311508252413edfa1158466667aff78386daf7cb4c9b850992f96e20525330599ab601d454688e294c8c3e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021d81c4d8d734fcbfbeade3d3f8a039faa2a2c9957e835ad55b22e75bf57bb556ac800000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 0","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002913908e25538484cd7f1613248fe6c9f6b4ec14be684c6defdd1e41333b6e9052ac4340e314eea2c99f7e62b31023eb236b557957f7174885220923a7763217d9fe59b5ba53157ced51cd4d9ab93b38c666d2047c4fa21aee43c95ea373f6d62f0e044bdb0be988685154ef7682617c7367b30d934b1d9c89229d281734a3005124b8d7c70b78e1634a3a20ccf9ab952c816dfad3d173567c139bdc624512f23f2a0c2f78c2be16d8f9b119d64ba6dec5e50ad104d8ba25edc9e53996f75d848caa0e4421167dd4d42d07d39c3e35d10924c1a8a9e098aa4d6112c67dbbf08c7a0888aeb657456c19e2259621edc3af8978de9c429b8167e679687a86cbb66403fbc6ee69f3f1344d07e845a865f22e5e94d9748cc12065fe1926d83cb288918c82d19fd5416de27576df8e45de1bd74351d996514748ae9018d27f57edb1de46975feba5e6d9bb1491c2a327bf158d03d2fbe0882ee0adc9b8121876dd9ef5c37f58d325af59b94df324cce5bc1216c8f4ecd0b4bb5728f83beeab09bfe3966cebdf4657ec6cfd773f0d5dba5bf28481dcb21aa1984e9c6d2168e350b4d6491d81967be0e354c869a8487f0f939f537a58df88abf2e4fadb55250897a54a8475d160d697a77da36bbb1438245b35dee2ac791920c9fad8025adc8dfa88b168716c5a45075a3f9536bce6238e1ad4d41995d675d3cb71ad4ce33d0326ec2a9f5b9c1dc6750ecaa6aeaad4c0edcc4a5015eb3f7503ba2210b16665f889e4d1cf3a9e298d61b23846593fd4d772c646dd024823371d531094cbb17902db113796852161f5d2a12608b3c1bcece960aad07952671e4cd6186b7ecfbc7710258b8b26cfa3f1cecc61121a49dd276e4b124e3573ac8231b60c778e03b74926e2bfbecd42f352bc325cf2204b3c0b5730e6188cfc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109baccc8d6c916c9ad12e3e49881f732b84870ce5976921d197a00d226ab8825430da78f19b0e7a12129ecb739d4a05c5ebb0019f0c610e14556a0b4c7a48e2e4cc851d2e8a57417e48f918b56dc605d25113451c3b10520f81c016a63c6f2d8826b90b04d8b0a792272607e39829adf4b09c0cafb11cf2f893c56b26420f84901ff072f9100013536822d512792643df4ede4b64200ae0bf82b7d46792eeae3571f501a9a814e69f21e84dc263457b913957886af9da2598003e853ac23b4d682971507b85bfeb146010b4b0cdd3f00af806cbd56a32987e38532ae3c7794058215c5db042026ac7dfa58ea5b17b8ae91e06a07db253e21eff361ec063412b227fe2cf9592c6b4888589f0a3a7fb9a300b131fc4ae755ce16a1554be6ce0f4e8301bb814e2d1903a209f0744687024949876ac94187fce08655c2131f2a448864cd6c77783ea2de6c1042c68e389f6d068eec2199dc9b6e92edd4469a923a683ab1c49557c19d9cc9a3822b628862a9e5df2b152f898172f3c5fda506c2b21e10ed39cc1cebf50b889c493e1b6614a53c30ee7be94abe59d83c270350ad490e2f9205e5607ae9328322c60aacacea9af2a12114626964b68af104aa3b34c1a9e0ae1885314891710b3ace65f54f40451abe425fd7af4218ffd067a2f61e32d851831aab032c0fa95bcc5504fcf8c180a9ea6d14cb23e35df931c40766468487612a172575d0ba6f20c225ab82a562f0eef6d20ed239da08287dde67701d2c29368dbe52acbbe0f219200535add286e6eb88e4f1643e922b2accbe8a3b52737a60a4344544966e66b7da65657b5bde6343b5987111c6863446c04415e0d985ab534e1d7eac615dc08e8f3d2a73d6057418368ad1dfa7001e647876cd50d589765695cf9715739e5d42fa684c51c9077a95e7eb31b87ba1808882b0cd9fa0f5d4f26d596af17f22dd09c18836106f5979203b01d10707840c80249f9b963080fd5221c250ae405f5a5d0c312b6ea8971a998324c542323808cc9a81a42aa9df3c9080bcb4cf5bd73dfe5c080ceaaa66e0fae05d88f23b76732ba4094c2d30fd16d26ac4247291fa2543b7751eff202113588b76a1646ecc6aa17861db54d5adbbfd3ae11423f3a78e8342deee705e98bf8bda82731a520374c69c6593c5d755c498f7b454c0185758c94b580d4257d66f71ead38205e2cc717032f1865649642472c5f34e1854040c63369c8317c1fc37518b16637840a86627113e3809a700cc1b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042225d5ce2ceac61930a07503fb59f7c2f936a3e075481da3ca299a80f8c5df9223a073e7b90e02ebf98ca2227eba38c1ab2568209e46dba961869c6f83983b17dcd49000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 1","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002933987a6704b1dca3cda547250dbca1c94a4289c8d61e6a6caa946409782f9fc305cb1f5257f9bcc68036b80697cd9dd2cf98ac8da1cc94432e93180d313c447d023f3b657ab4cd49d1e5d776db772d8fa7479a24b121f818a110c92733d3bcf272f769059781c8f2a05f7e5297f96dd2aaf93371ce87b35571faf494ced71a1ba15c5001c29626ec399cd265ebcc5a8bb5279e7db529079e771918fd27964d5233636b435c2e6ea568cd90f6cbcbb9dd31c8912bf81c94eff353d44a11f9ee46191195136523ffde3947723660f0e73bbd56e5bb18c8430a9ef8f2997275eac4ce5554eea4b34718e5c68cf55838485415aaefa5d169dbdfa1c093a94a429f2838420eba43c80c592c63cd529dac89c8131c1c6518d49768322483c0153ea7962a74e4b33ff754c1f7e30b05d7567762c40d3e3c193330b6b958fdd941c4f9799f122c8f401e4de4d11745d1090263c2b29155191443545c736c6f0d13045560bc5b1fa0e635d18bbdaa34670d6766b29fe28e06a719c16b58cf5e9590770e5a7d67839d078a76e9b6905752b245688361aeada3e64106584892193fcf60ee4ef695d4f0eed0d4098c609726109dc125a591c67c5262256f749374490545bb71ca427d556ad0dbd5d3ed10abd68cbae5086ad505733a8360fd9f6539e62cd753d3a5829031832510ce8edd1dd1b3865e8d4430943449e3cbae7bd2fcd9c228ac428f871ab67bc836dde9cbf54cdec4b1069ee55c24faaafb0aff2229491152574d31e4dae9bfafba89f9abe28bc64fa7fdefb5c753a6c926c8084db42e834cb01a264322d2b85235aac65a60552f7c309db9bffb7a7327508a3c14c833f01674c761ac8a9f2a8bba7d974a23570b654edffdbfd06664290ce5adf35c560d0b986d3cb9df660ddffac20f2ba4c6773ccfe55918200000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a26849868d082c87bdca6bb1e88d36216c5bd3220d55a6072a77aec88d6874e3508cd65fd93cc5170ec237197c895386e4bf7d9002e09279a51ccf68aa41b52a7944f3400fa7100cfe774a6fc69f0682e984527661c03ad6c405927c4a3be5db077b2c8e97e834489a8f4823c51059d77dbef762a6ce0c9968ad1b1be6fa927cd20bd1cc5b8b2ec699fcd7f62bca7066934f8b6f8606f6bf0a88bf5a20dbfbc769ab1663805906139ed205869acaafbcee4d28f8a995a9f8f5b94941125d2a5e0a2adf4facf5f29ac98337802607a5fb28ba13ac18a8e74953a3d81535ad5a99624464f79aeeda4ef663d25f01df8739bf62d261574ec2f8f9f59f56954a9e880f820a0d806028b181bb5251c2b5e19bf25faa9e42399e3643ed9d38d5927d9571b993fda7e34628ba61c22a151d1ea7d65b4e8541ed9d020f0a7610e867109ac17990fed9d757a3495bc6f860a081c384f4b1aa0f2ac647e44160bce0263a58ab59170133a162db70eb692d52eede0306941046cc4b572adfb8b835ed618616ac596ec2fa2b946f82103cf7b6abbd273e22b860ce523f6cf7546a0d432a085f01231ab8ad041ab8bc53dbb7d435f35c85a5b108cc19a792e41f9a7187856a0cb4f434f2206b1e724d789925df8b3c9862d5e7e57a626accb6b4aad29a586dfa1c06bd906adc74e9df379f56695a7465ad6d5127276d1e5904299aea6c0de978d29655ad2ff249268d939728c11d2c892b89826e1a6d9041974e3d641d0a3112dd38601c7187d1904862a55f4943276019565248f184796bcab4517cc8402656e96924d779917ed2185128a88e989c13fd2bc24fea58d4ff857105ecf648bdccd3a910e9ab0a1902a4a0f0c01963453edeb8dad9de230c29fa055e953b32fc959129d4858e9060c559ef8859ccb80a41041e3922ac6a8bde78586cd98bb8efec567dd1a77e19f2b1246ec44f816b6c753c262b0cc66cdebe282609847d8299b47098a1a6a90e463598f82aa43d2b81cae88ff45d8ac7a4941a3a90515fece50d340148a4ebb167be7556366b632a0eeb95e683587015bc07c209d1691ac832574bfb655874bb8553250eec6fc7ad15f15d611d10152429b8580d4429d784922c2ec2309c1802bae24a01dc6b0a8959b6b0dcdf0be67bc534e8c3609e825adb62314e52ba18f0473a9892b894cdc2c253ee8186d26a538e466920be4f440dc2c052ca09af439c82bb44d7ce370006c18546ac670ae38bf3c2820ce479959dcd780000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000632b8c4b0f29363eaee469a7e33524538aa066ae98980eaa19d1f10593203da2143b9e9e1973f7ff0e6c6aaa3c0b900e50d003412efe96deece3046d8c46bc7709228789775abdf56aed6416c90033780cb7a4984815da1b14660dcf34aa34bf82cebbcf0000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 2","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e394678201b357b0d2dade863a0a0a04d0c021febb0393e020f02c1139b6fd32461b3d7c621c39183ac0fb9ed693b4a36aad585641375a778dc6ea6fbb8e9c5437c52547468ac8498f5b684c932be7b6cd053fe8eddaeee554ae77cec6e53fa1eec85338b8eff9e4a2b453938ccfc98bc81ae4f5b8851c3931cb3670e39108341b4699cf43db9ec5cbcf6189c6ca9ba95e27848c45ffe4cdd08df65a14183ac9442ff589609f2294835448ca778865ac9ac91ce5738d3d254f3d2cdea10d0a3110b1f7a1751f66b294fae21fe57389a98939115c36fe118160e37c1d2ed89226aff6332eea5b6f08b43676eea1a4ce1e5a21f4196240dc625034b372da6b67386cc49d3223d985b2c4ea607f12cfbd09154b79e9e572e3eca7eb45a6d7a15e78bb96f75ae6e6d9a4d77d7250ebbdd56be91fdb790f15362280e1630eb398a177e5d2fb6c27274cd3c8906b8bb13bd8d465e47dcd983d571e59c9b0586757062d547832443278da72e23ebc0cfe54e026b516c997ed9855e1ff50589c4461b9997b761305b237b9c0ce201284997daeff8c7be3a7cff65b9b449a858ccf5c3e12161a69107c1f7fbd1ccd781d01b25f9dedb1e1ce39eaba01f9e714173a0dc1f83868a108aeef3b69c401d33b3af2bcb4e24ea2f18e1ce4a3a70b57d2cca28a4539c922997a9c751ba36f1f46e95efa0cd71877ade3d92f9a7f7c1f68cc196b70677a2c165253a85fad1b15236d9daa375da638a6db923c84314063185f6d235f738bb18d7e6399449eb2b7a35c9736df9cebc71617b9ed19a945fc7df40a574064eeee9f590141d62f1992879ce8e0a69f5bb33e93a5ceec014815c2f9c3484dbef569739d29ce8e43528a693590f3427de964ab4673a3d0659dcbed32b2686d0dc9a7f272a91a231858b007aeb100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381095a4cd8dbb5e94c93fe67a111582d99659b90e15b8a8cdd282af74e7f9576063a01d00e8c0a1f96cc8d944450f2e13e6978854cf645baed424c060040214bf90892ef584110e282d572164e51dc7e7e29b0de8daa7be034521f2cd46890fda0a8c5970a69bf96666fea57e9982ac20b93a78dfecbdd9e8a54bcfcf040ae7679e533a13d527816917762d2a2779225ae0345ebf0245a98a4c493b610dd8126e30ef4265ea112016c325d5d1c08f9e8610b1af0441cd0bd729209a4d900906a11852327e9ac6e504ba0eb1e343b9828094f4648248a03e00c0e944ad9496568d8d03cfec9149645d359066960b8e7a2092c5eb4bc9ab24abd196442872b612eeba910abe9945a24e14451c58de91660152cc72596347993ef8f39c953f2e26057aa0c5404c1a28445b0b0e8681f5ca714b3c4b48eaa4920fe47d1a7b304b4e2c4f29c10968c454a2448a24eccafbb6494e1a400cb909b8d6a205cd085a5c444bce049c098603b9fa8c9b7bf4763338a9461a32885220cf6b85bd4597d0a63e6d92e677151e329d3eb75a200dd78cc419044da6b72799ed847f2c8650215db04a8fc7bd3a48b7108703483e4556c78e8078b2eed0e5abb3a44052e9ce07e96cd095dab3979f8e886bcb9ea69b5d4d8a8a3726aa0b849f315217c877ca56b42da44a1b884c5be6d3d46c16bd01df24478cedd8dbd61fc36651adc42aa41e51c8a8b5a5514c08beceb6f820ba023d9867ddd2d1131c03c55ddd70a4bc60b16aaa380089da07baa1ce9d7c218b3b298e868ec5a492645cb7f5e6229edcf394493725699994044c63ac000c6b18802880d5083d1cf928203646da23f8faa6f5eec49d181ad166983e5c147b172ca8d48d210ae9bcaa5c5845a0d44c0afe6c31c956fb0e0d77387d56150a37982da6b7f8ec279189f1f09086040935b2eb756c47789537ebbfcb1f197d57f6f49a6893328279ef9be2b76c8ea4ae2b06233e057bcfd34d5c22cdc61700a7a1d926381d035fa468cf396ecbb29614b0b7e2c4bbb6624ac6a40eb24320ef3548a2115dbcd2b571cf795c7da111f80434802cb1d6a5a8764c9df861a026ea34b698d25321907452046b3aa6d5154d902065a7d618e5ad102613551ef6ee684100b45564110a2ce86563fe4efb1753b44c8ae0999524a51ba4df49aee8e3780e0e027f4d6376206187b8e3c17868b1e810c38455983aa4335c4e243d5201125ad99cb1408a7ae9ef51deb6816fd418bddeb988f78bd091eec230000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000842f7af5b52a046471efcd720c9384919be05a61cde8e8b01251c5ab885e820fd36ed9ff6fdf45783ec81a86728cbb74b426adff96123c08fac2bc6c58a9c0dd71761292262c65f20df47751f0831770a6bb7b3760bb7f5efffb6e11ac35f353a6f24400b80b287834e92c9cf0d3c949d6dca31b0b94e0e3312e8bd02174b170c2ca9355fe00000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 3","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028b397b89ab5bf11f5209ae360448d66b086e87ca103a6b5b007a95bcc5bf32f31ffbdab61f31ae1296831276d57c01ef83ffa0b0131da5cf7c545ac3fd9917eeb6edd2d7be330ed080a3d8536ee3f67dad1df0ff5a687893d7feb6a0ada0a153e8f0c55914cfbc529facead19930fef98ff18a8ca6abde1771c052f25c5806511bd4b7300cb6106fb3d36bde165e81f386b1da7a55c6f391f13ad98483db61a12c8996cd0d39a6bdb2d8c99a2f2b8d0e7c156b375f251b8798dd07b3273b99cace32513d8662c88c42e0b3e5bee8640f2f6752f4c8bb0a782666e745bfbf60d0bb1fa31b08ca927b34620ca3ed535c9fb62da94d11464922213458f74228e9a573697d066745deacedaee6466a20b428832364ebd0bbac1fa2d97ad1e9161a7d817b762238ed3ac9be96e4e0e7bf0b13de6297fbaa628dc5a45b3d0918d147d562846a5f0a87c15bd8b167bfb663511e0f7abf9cc3b3f94b0dbd4b7c310fa5c209869f28497ecb14b830505e24cce453a222a887ccf20e8318a5dc733cf835325baf13698bd3538adb62ef896442b4f5a7ecd231133aad4303ecf330dbbcc39d272cd037922f9a4e8cf3b8a5e54f5e0b7efaba938e555698abee35e86c5d59f2cc17681ace9b34ac2f0d4171ea4e02e1cbef7af36e992949b5a2dda8c8d3dbec1f15a959e08f6b3b47402ed9513748e1386bfdde46cc23eab472e3c6cbfa68316543c2a5e410d1937bf50cd3530769ca740eaa0a732edae2daecbb75db8d73ba7fa9df0d868c5a1f54f92853f1a6b49af37d8e04cf21734cc5d733c0663ade1a0e36632820fe58323e7ca08f591779235c4d8f15e9846d4c44ea3f1fa6b0febd2885909b6d5252a598ba9d27e917a6b6129c01ecaee889c76a0f3f4125914d42a6c12564ba599de7483a0c74000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109ab4e1b27bb837071e86f45921a7cb6c2f0a95b65f86c5266ca4e91b2057efd23a1226f5c6e7ed0dfa5052411ee463a52129b6d3eeb31550d4e66abf8b05f4e774e37935204056f2d8a58005e0bb85deec4ec13ec280c577677949333bae642c04db049f8c20bdad79272e25208aa2c89847232927d134c6acde588cf68c66ed90549aa68f3a9b44177092d35533d21819b4d474c213b98a5295a91d29a78e70a45b8549af1750e52becd8c97f182c9afe8a9cb3ed67ca3c8210804cf566f687d1173461421c9d3507be3a6624e5444f3cc11232673babe5d8f7c71bc026b0a4e5b08c69705c9aa1ed2b214f295894c35d3f6d197b14f843768e12f8f1a258ff0361e84a959a67474ccdc3ac9ac5881c6c373e56e9749af6c5ac0a5a3b807a31bdd3e18ba0e2059a8f85547284e433c802351ded0b4411c0b3ce3e58191a450ef124c5b1ad0a06eebe50fd8309bd8c8398dadfec29360b6a6566096e3014bab2ab9c143881c5706703a9c62922f249c8af29f539389b59737a2ae69ac2be00605288e9ec311e14f932bf204fad695874cc9fc87b95cc6580652ea9da51cba61d317439c0ca6090d27ee6a7723b200420c27025132ae4923177fb3daa0a474dfb55a92d478f2e70ba14cd86a0d8c6bb865a71190e67386194261b1a61f19f6d8256e1c9782cdc412ba9b626f1d59c8b94dd347668d893cd074028ad9f7e06a3434b68de64028df5679b4e881949890b5ad4b7366072b39f0b63997b3a0b21570a8172fa852cb16965df4b73453d0f7dada09b59d288561c0110a19b710dacb94ba9b94125a42724037939221b14b220eb8cec3962e91da95038d38aa5573db97117e0cdc14d1eeea0da8c920fb59d5c09b4699545845112249206624195192c88a5a09060178a53831bf6fa43b269c783d509f1b4d377336965a6232a0b38798b262bc68eadc18be1b64cca2e9ab53478c8e823960948d6ee39a37ecff3929b7887e89a7936e3aa95a8c183a71d34bc39f176059cf659b1c6d79089474b501d02cb41ea2c78db533f8f2d4d3caf61aa04f1204829f7a589946f7d3acbeba6498bd2b9450b24d35c5125d8a6a065a8c4ee583fae7e6dc474322a9f1a1209ac38076c08020e9588791428662a0741776db03fb1b2242c64ec6534fd9864947eb3adb246a2029884e4cfc21844181d813289d4c4b6197d0938d6402967ec1cb4698d13784cd3d3aa03048754c321fd20f6af06d7e18bc7fd71d8a8c218e7fb0cf0e2e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a51cdf0ae1124780a8ff00318f779a3b86b3504d059ca7ab3fe4d6eae9fd46428d1dabb704c0735a8fe8708f409741017b723d9a304e54fdc5789a7b0748c2464b7308ac9665115644c569ae253d5205751342574c03346dddc1950a6273546616b96d0c5ece0a044af0edefbe445f9ae37da5afb8d22a56d9fd1801425a0a276f48431d7af039521e549551481391fe5f4ebfb7644d9f9782d83a95137e84ea3aeb3c2f8099000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 4","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d392128952d1a2c9c635584ff941bc2363b2592c7f88ff0436c86dc22c39f80b43272e03082fc47c96699c58abae3ce93dce4b93739b0329a1f3ea59d58040d42a157bad2c58fc1158ea995d1523b98331f0894fe0e89c8b3fe9485a33adac5b2764d1c62180b348882e5a0bb1faf697d6270eb292789cf5d1d8ee61dcf88f1a67eeebf37d1b79066bfd8bfe6ae81d3ac3238ca7c12647f244f6406486358320f3ed148e789d20cde6c2f02f516490a7f4de042e71afca4a94dccf1729b4e5705e649a31c06c6fe9ff817933d872e3fff9e520116ca795e3fb4ca3fa8e555baedfb5cad72fed22739afd5add33dc6fb4f3ec0c69f3d873bc0840c1d9e224e3fac2eb312e33813790403c4df64163a4eb3098830f8a40241bdc0c8231180cc6b2fc8adfb9cd7d9fc0d5297cd29a6355a74675e35bcd2a2adefa6f9a5c7921d8ed3f49325aec76b69b5f32cf529b358363e944d096d39edd2205aa7e887a9c69f5c9238672a3c85ce9e3adc06cbd7713ebd4cdea898b7085b835dd69d994b02a8c5faf183daae29cce7f62b059ef669c8efb930583cffd9e49625336832502f46d3a64a6e8be308dabf79b5aa8d687c8a5f91999c59f20784d1601b26769ba9467399a28e3da8c9b062a6d71445a1572b3aad597e442cfc3803cf4464678c158b756f37a4c4a1717a56f7e504f2b99c3df53f5f74bed16a2ebb1bb2647da8a985fe79ed9c638ac0b21bf7d2cb6e78121772bd622ece3c70f223e6a6736ff7ce6e4c94c23ac3bdf5a69eeebcfa9ef2608e562ceb43775d8712ee1b9431df6319be764ef27d319e35ca5bc0dbe7495263082988c3f1e06d5205a681068f6d2136f54e6ba31e54470a857aeffed83fed25464c4c131efef4f8f9d3874ef6e9a8091eb9727eac7d7617a5ac23416b32500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810917366093c4dde278681e494da28523a9dcb9c0a35537940baa6e272fb978586481520a4d78fc94e5d43b0bfdddd109c8889e9dc917b72725050923caf008d9a78972049b27251859df36694263880a8078c602c391a80241220b2b7c3084d2b48c035b3d1743b3e28866d970824d497e48c571902d6d1140ecc5e69908468a29933a51a0ca420e63ca16c8c220c51512c64405909a24920a8f2657808f6798ee050512a810869a0c92ec8f7122969a8585cda8f8413a7188fbc3b6c906043c74d962e9897cfeda160b047a595daf615b519792dd22999084991b6d4869f54d5db5d5d16a6fa7821728d16966479480fee91512c8a3023a05387a43a348e46b818f1367391e4c9225817c862dc90a014db8694cc550ce8da67274d992a69a436b7af4760d5947654ebccadb24477155681bc4df95b16029d4b51155bec4bb4771a18625796db2e115e575e6c177f09aae1ea6fb36e8cca5aa519f8576db037db6ff736f92cc3f3546973da73d50906336fd6b5b55615f0aa69e646f0a86c74e86329dd8eb4b6a5ded725d25698be16f9fb19d556512c3878c70935325fd954e8fa15c42425e1486688657e4a54000e6e86c8e94f5e4c40dc41e4d79d2a8262d8e84eeb7cb3756c4a32d2be8d15c567379631641010b93bc8792495c49095525222d8fb39b561622f0e123464cb294e09bb77f117136b499d43f8d7407856c6c31059a458ec6af8402e16bddaa911004f5716f0ee10a347129c9c6c55128a450119015b7081853410d647efdd5409892df41d5e199e4ca0693083f076c60449388dcf9874b8a136c64483be769b17468676a063c40944d5490824c0c3d4ca09cda50473ed9c98adae67996cb07ae220b2d842fc03a8d3556e0ebe7dea3d7b7a5161901e275be9a051bbd87890d8437e271231c35613bdb5414463a589e5bbc8b8988a0cf3bd1c82f536c677164480702ddbaebe4820400bae1872cd6e97f68b3c50369929f5ec072e7cafd188db57a80077e7eb8bae18fdcfea17c04d677a9b1383273a702c8669d58c5c1dbc1340f05d3e5de230b4274c1a9c9da89143d9e3492dc7d3aa177804626f8268d3bb91bc71038ca3dd2505db6711d8aa3b08facb594fdb01180ca7a95322335e0379826a16686de2964dd89f3cac461a0d692310380dc551572e3d8c1c392156c3476dd6d76fe3d61a89e9d5490eee3694cfe018859165ed4815416fea546220ba7cddcb39547cf5d0cfec0aaa23790dca6165ee1620000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c6dbe5b6c299b44f8d60fa972a336df789ef4534ec9ba90df92ad401d1907951eb6285eda8f134277ab0a1145001c34e392187122506aa2dbb8617d7943a129eb5c07df133d7ccde94a7cb7f1795c62493ed375353d1f044257da799f7d112c174fbc35687e2f87fefbe2d83d29d7314b30a749fe41b1b81095638f112bc4563420af235280e466ffbe7050c4937c60fc18d1a6025bcbd489f0c538e088e906abe8597e2c8ebb64f01d225c847aae4b77bae6eba9269962c4b94a9732ceaa2cb4093d442ffbcdd0000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 5","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028c39047bc8feae6a114b23bbc1cb16e0d84a736aba26d079dd6523288a3df2d54d26de658bb00675a301c5c5e95118eae78fa4f66b7c775da8a0c8b9668527a5d56a094e6d97b85ad286b4c5c46cc9ba10cc57156b7f6254f1d33549dd759750f28f8d37256db6f6ea5da9e2d110d87fcf63e5dbee2b9cea4a7ca050bc8cf63cd8e7156e06a26b3ae4a0ad9f4287794be0b60188ab8c8bf7dd471e98022ca4b81a4d4dce211ccad07733cc6e648de7519affa2c2a431ea17f6051441e3755ce0987433778fa76a0483a5dd87420098b3cccff706e0a8b00b027ee654e34be27ff9f154ca56155aed2b19dae696382ccc410431ebdd926fb53dcb4238d8ef3abe7996e998922eb9566e97b03ebafe7d2601be75139c9641219075584e16dcef326e69ec579102c382669016c9acbe501ba5f3a2b2d35dfeb218ecf9951dce39eeaea6d04bf9fa803ccdec574f9d974b0df2e792363abcd616849e4823f5554e02f9285e117369d48f0fda6690f44d775662da3d4c1e731d4640eefdbbae8590572f76382b42af3b1476bd0bacf75a34571793499b88ec11994e5f868a88d9eea615fc13592f473639b93ae5957b4c473f5da390137318aeb27736a58446eb52685612570e5212af2c54e449d9e3f9a58c5b5276cf0ef4e953df367a04d373f22b2144e46250a0dd3715746b0f3557e1e70b827d152e2997a4940e2082cc95f9f66e3135e061305bea4a813f7e2edf1f5c68ee5f10ec9a2679cf445525c13dd7bb4e0635e28fc039f47ae9ad6d2ef912238a1a1742f0c4a617beec11227c70eb3400ad3b7967309ca419a72296f5c665920ce4e0a6e502044190c4269b1d225ab423eb9ea3d0d3241fed1340c90a6f89c7228f08b332de29ae3ab29065517add313a8d3f1c7ae39e9c40a2ad4cde00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381090c7a20d053023e475436eb8ccd644bde15fa9ce32e1cc8e95759acb851681944f0169a4d02417ba066870eedfd755ae0b94cb417d3eb4d2d58cee397191bc02a45d311fae5cc363acf76790d3db99920f8025ffb02d6d779a44bc85728b138f42a05537a540ac8e0b513a56b79bf5915a098e16a6091868aa0b3f45241236be9be376e048e367d3ab2012e67b6a1d209e204466c5418393d15060611a5a35283342f1182a7d72537518c087176195865f09d23d752e65b6daf915adbcc270182017bc310163245a3f6db8593d18833d04d606298dea7f01cc704def489ed144f685939e7fb5351232585212860a8997656d3e31f4457d0bb1ab1593d890849642126234c316788c203c9b5eeb703e587273270fc12421e59ad28c3b596047862c63196a8aecc6fa4b444289f95b534cb344eacea69aad1d72b8195912ce99a9c565d42f03f7587dbde100aaaca0aad7e254a6f12795f6d79299223465b7937165e1082c72dbf4d137bdb54c9a42d8df343231270d4d648382b8e17407cfa65d5e8148280250fe2b5077c0a457d82481748a494c61287111a4cfbbf2b0f9301414269683169d21280b5026db72209e763c01e2fb6606088221c7eadaf9211a682938233c2666d9c56fa08f1dd56546a949054935b6aa0191d30b5949345f657a09e88cbb3086b47abe3be7df4547468c59e8fea7ae6eec725802cb71a5f2747be79dc26fa9ac442da84b784c606690605eafbd6fb4e8ab5979be6c6a2f99ee4de1fde7418eab252a9bc7db50c232d2c506571a7f0dc0c37bd5ae1291526161556eb1bb2457c0ddcbca15d03f75816dfa2139fb757cea982d1ac4399b6c75bf141643e6da8911e14c5bd021d3753163d81c67c553cc1d594712d6018804899b13a07e5202160e6fb3b9b8feb50954843abdec215b254312c2839b90af2f0ddc2083ab8cc31e956668d14e6f7336bdf191032385e8b4f7da086d7ad6aa558b46470ca03be81fe6e8b430372742eb7f1d9423b7dfaf5077f41589b0aab756685e33cba2f94e3d61a5e4a476b546b7f83ec07865bc22b01c20f14cc99faa40e0ba99b4c361529d3836752dc6f41c1f237e1cc7f34d8d1f3c69e193a7897d386365ad292c6c8e587b5a5aad3a30052bf78e3a65da96054a4a8c3af06be2dbe3343b8c4fda41d50e4852cd7b1ee7c94fd8cdb35d62172ac94c0b4822934c5ddaf794d96dacd65ebaad4e334394e29adb80745c6ea0d3246452191c9eb3bb52bcaec94090000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e70073bee97fc97c0fbc750d474aeb93189f061e1a5cf6600c04fb0464338ec7e85252f94fcbc7b2bd00e438480d9af3add92a92e3e2e8acb55077c3278fc7503988a76e9b6062996b20889aa55b343d5a003c8a8852d738f955799fa3426be5ccd3aa6b6eda04d4884941ffc0b69c5acf12b347a74d0580cc3335ba816200f87674a4c1d98097c70f2f27c74e94a661850610ecf4847ab5b58344f958c5719e06ba396225bbe21acb0fdc512b885d391e11b0c0ed5ce6b5dd8faff91f50025c69d43072f7706d80d9fd786e1104125d79a5f4b5fd838815d44fc8b1ab678078cc174dde970d448b00000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 6","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028a39203d65267bdcd045cc80ee0310080a6dba5b307b54fffc49b36ed2dbcd75e8823fdb888686e70feed4cac72f0b75e93b449f5364d068daf21da63e53d71507694cefa275fe88b474292103491682aef94c6134152fb117cb34884ebcbd5b30d0538f0410db94bb5ddca0a0cb1cdcd8da215386eff04d6b8fd29aa1592059cd8604f4ec9e09633f5f9b3979d77a05046eb41e0dc5c392c6dcbb485f9e99cdca601a8a9924a8a787a30504d35f1487018373ec1ec3f88bfafa066d4599a9f14936a1f7c16e2cbbd9b445e2c79b48f3e93ad62455a9740bcb21ff552b9c3b33a71018ad4117d3a81b3e5f37e5c3ac66783a3f946333e6c6fd7a66413524cdef9ebdd42068356e0090609aa74e153a5e1697c5b8bf248f745ecbe76162775d7977aa5cf2f9b487578edd4b63f558b4d2f71ddc313db4830d66a590cb34a9dbc7c86b74a40d5753e2f69a03f125c4b3790c57366889f35336372299266eeca7e9773d5f572e0d63c85366773ed2dc845da579192ee8e6552b6d1f1e2847779f4b2510f2468a2a0d5d4248110be5fa356d4c53366ecd5fa20cca2c7edfce04c09a780c7a20cffd313b7bad4d993437bd526ee9ad477ac5afd1364d7601b88a3078d981b0854f3189a9beb42f2640a33a2e93048dac3b47d5fee5d68a1af48679f54fcc49bce1223f5dd1314f11da9eaf3bbe4418c30ee077f08c936f9e9b40e191548ae37de1c494b84d1d6ce8435b3ee255464fdbd3a579abece298ace6652b494bb22dbf9d601e84cd37c8f1e74967672392a12ee6059e8c6145622f185a341eb9226734a45edb1e46be4a49dfab73c69e226c0922c83810e5b354a5ae5846e2f9549e5675b7e772498281bc84b853fdf7d82f776cfea51ea7c6a723d1456da7d996c9168b1d7fc09abfd00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810950167e03249f689c509512ae1741188e327986cd1b2df8f7d8c4eed217ceaa9440822c356256f4ae80dd91990c1281d55a54fec31b2fced6a2c08ca9a0051c403c1cc3afd366060929626e614813d05ea31a21ae5980a3c05461e99bd9e06afd0a63964a7c477f82e4586e21e760aa1732082af8aea89915062b2b3f070a5deeac5babc01b0b5c1be1c48ebe3f98f15b45c2d87c70166862e9db9cf191060718ec955c7f4b5dca457074be715725a77fc8c86300238548fa32206124e36549004a4699bd8521026a87286406f08de42c8131224d73e8cc5e573db4813ad6e721b2fc1564c55ce262b8b17b8bad225250c4796f0ff838408cb078aa5ea45dfe026e681054fe232b7cd32d97c51033c0932e4392a22464ee7868c8248b68a63ab16d92e745e2c01ad0a3326a5dbe788cd462c95be6b5f5bee1c199ca02bc34749454f07cadeb677cdccda6280f5aa11669250e8c107253062b74a8a1b86026a16afb09801b898a60c1b3fad69f184c240097aaf718e6ecfbf9a4589ce921279c209508019673b4a824120ad1fba22983b2f02d191847c20d5dc918238ea550c046f4456c963e882b6777027820cc5a1ac25e2663388a47c8d60b2fa406922c89274cfd9300f8e94ba812cd83a220de2629fc298ad2eb96d5e78b915325be1aa2f2e1036a74ad5540c24b2f60827839fa04bc56c05e104821bd8a0e0a217796491ca0a232352d5b9a551b2850a3e095500b043b0fed2d3c0c8b37512f67696b41434f139f0cd926df6eb042541fb934810e07aa7c90176b4b67cc51d1e1a96aab4e62d676253c065c31244e970044c4213af4aa4198c9f7a50616bf28d8d3b598564a1cba78e1e70492269944c878d8004ef1001bef09522d5d64980057e053c91b284666936b2893975680e3590da3c5724861527166d2826779a0314956d52dbb8a3ec553ac5c471ed0bd466fde3662810735f6e67c708009b91322d90c0a22a49c00c41f8112d249068750197c2b588a14352ebda05a4bd44a70d7f5d8a2544bf434fa2f43f677d54fa3572b718844cef0896b7380ce0374130f936df05ee53fce01047cc0c303154b834e4d38a6104e0429e0c2822e9b0320d2c395a79eb280c8d0858d412cc820c6b3ad78901ec12ad6562f886432bb3e0e7ea78100850852bfba018cf4680be5a46db7cb66156816554750a4ef5707c4b4257d68c905a94dd5e50dd4742d5583aadffd3de8d1e2d51f5d2bb5afa60c530a40f498320bcf82000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000108a1586245d81f96bd8ee81aa30f10c0adb343d74cf72c4dff71550c12873af89fa1874d4731c996243c3749af3f6188ffe9fa45430549045134eb29ef3cec37e72904aa082b1c6161e6b52361e49af4933a8d8c0734f21cafd7467b0c02876f43211d6122e3e735fe36064df7a0c91449237c2bc7c3a78ac7bb0f9567f2576f05802c872adf183a87aa3b8217188f2f3535f877724f35b29e545de4bcf258f13bbc7edd8c6587f733c9691f74b4151cf8c060c3ae9e8d49fe7c77bf477dc9f23fd0f0b67320275529034b84f94176730923c03aa50f9584d9c2d60b8dccf85a13f243f30a51abefbbf2cda602bf3d75e849eb92422b808416c7e56b046ce38e4677ad24d23d7237a9000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 7","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d3967cbdd8cc69648592a8b3f0dd86f65f3e6de3a35de7607c57227259c7e2add449e6a5a8e0e92bd7c8139b404577d28ea1a294756130da3a2773e6ce1a573874d31b135a5332fa5f578765c7a3410cb2c1ccc6299d377a21c43a713e26a3ccbb7da64e0fba02a9ab1776d1e761d2bede6e58fb5da46b656a9c4f1a625cdb38b0863bae5210c7638cb42b12eb6c524e6215c6821294a91052a1968f6fa8a6779dd8926d51d61d94dee42dcdac360188a229f0ca71968e91986dc56245f4908ef6e4dce3907a846c94ac3832837ffff96a642b5f3e809e854647bd6b309224b90560fb74270ba6c9cf191cb23de0d699fdc4bf5cb229a665cdd10b3d7e1d12ce6ae70af27ea3ca1344792666d21bbc0598e8e8d5dcd41156ef981567abf4fac177d60a1216efaa49e1895cdd45653e3efd3cdc01a3893c5a896b4fa28f3bb90b2ac72d27caccb7957442bac92e4541b7cad9a81da77d79ebc3e10fe4cd878fc66679dc1aeab772b0b62299404cb7b35c7a5df8f8e96bfef6dea5efcbe4b7693e57a1df82d5ab8ae11da2609fb3653abf96ebcca1ac4f727663b3c2c25abd925ab6c5d942492eefa9c130d67c64363d8eced993e97fee28383264ab02e91de85f72afdd9f6664fa7610b9fd7d79a7be38a16497aaa22ecd71a98cb2b78c44494ac7f8a5e4dda78ee4f171a54e1f6684de3af6b7950e91fe7088cbbe8c425944b8643386fe75132b276197c423095692a68df1547845eab9426dce099efdeaaf887721c373053a86d7e1531a1a811140915409df90d6eb7049b6f22fb0a033e66fe820538417b10a39aff3d530a795a474c76d71a6cc5a9dc63d2699f51dae1d35ed87e2bd8d6a9fcbbc9dddf9927b9023945df671e5ba530e48623adb9ef0ce335427bae068962676c90d67d0b80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381091a886ad077a3206049169713e9552bede0e5c9ceb03e9c53b0c3ec6b0c8d87986a16a2a7dcd2882daa6ba6428ca74c906c50f2fe300188d7894e02d76b2e52a152b7057967e414922723be2de869aecd45e309ce8d7e2834160eafbdb673a2f5ebf98976bd89325eef697afca4714a4228345cf4b192e55058bf60f281018f9a3cd629604a69b9be4aed9531298a5f336c4f5d43546221eb53688a20e64b0e1b843e4e309576634e8938bbc234d353baf2b24add2bd9387d2b3a052c3a3e5987d42c204d5a5919310bdf6d03f9c0ead456d91f5dd9d72ddc253fb925daa856eb59b2fe99cc43cb7d11bbc01596ce135a066710189f77f894227654e89be8daea84e3c033c41452971e9864be90070c0e8eab762689450cc00fa2d49b7d8ae9861c15ca8f623b1805d80899e14c89b53c9be703073430c4e55c4c5819dd863891ed39afb85299791277b0599635741b6d36a9696bf5e2c238c8e1503baaeb7b0968293bda041c714f6a02c793b1ce1df1bb8b516f2970f54e0c00a029cb1255481f6ae5fc745e1a0c73eeb1a374dbf9847da42003a57b15782f077b192b685474168690d396d8ca786197802185b925828095bab8154b23d33d4022a2f4de98445015a1fbf5442a565cb056fad6bda886b9562153536a5271c0008efab78eef581ad823aa99a6248f6f8d20d8a476d86d0b8cc10348e89d8c2712382b71170ba2f8113ac4cd068222cc656a85e437501c78109e1397f0705bb3af7967c000a579df9c82e91d9034d8d74abda3a7a65cef0410431269e98a7154aad70fdf3face9df2a2480d3148e8e36eae98480b591a61745b8a95537e936c57a78a631c41eafe04efa130ac85e73245e04777a2014a78dfdf4ac5bd1938c92058f409eb5c9f735a188b83b00aec9c4435178dd34a60ecda575e67422af16753c04460649ab486b580eb6a8a5f7a2f2d2c6e404945fbd7797ba46c66459b9b99feed2b2441a6a570b026e00fb948a494831408cf6b448e895d2dbd719641983960398358f169df49c45849bc2799523c631068329fd0c95ff4dad2648e280454f0334f8289891ed56563af4d620c0fd706ecf269d44fe34fa66a4414d104b98418b251e8d54b88c983fe006bda5a730aaabfe957db47a94845d320eecfb4c0f8c84481644c9dad6ae5299b80cd0701c19831b2754e151e52240f8012503b19dba639263bb7ee1e34c417c5c1d958079433d42c069b94503695cc4f6b2fea165b3714a04d445850000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001299366ed7b3b623c411448b634446f1a3faabdd163a6cc1e2bcae4a98703cd8cee441405892fba051be2a586a6950a5ef73a255e5f86b0d7212e0c51c3bc79be4b88e76ed6f043fef3204faf044bfb1ed722d61eb5d0b74c66a257e8ac3a2206273c80d2ec2123a4dbb715d60118d99ed7322e38f1562f82379138da3ddb8baa7ce61ab729afc3748c0134633cf45a9973c05c75d04e82f631845427626b5799dc07ddf830ba01e8bc6236bb6d03b37d949dbb29eec7dfe60fbc17ea590956d251539792016e2a8b01e70476961bc9ada43cda682d0caa4fcc58810bba1a673ef8f6bc90baee701e8e4f7c04a346ca56c7b2862ff57756ce6cd1ee22d677bcdaa896eae96f87870e032c18b6c6a0c1a191fae2ed487ce55296cc4b6339eac9e8a742bd0a44c3525cc7500000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 8","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000290396a86471110abfb6da027c5f87ab1f27f8bb6b49f3f2e91e6b46be32d8e130dc7a2e741628cb2bc03d29cea8d83e37f52595f5ab7849bdbcb64005c2c76fddd9efbba3a6bcce3f2d9efb8ccac355457519b6662b90d108406f52b7c5023c7081856a91f899b5459216c688974048ebf30bf7238a5fc60466206422885cfcaaee349b65fe73b62f3b1b539e339cc0203b5899c7cf100f7f320196923344cbcd5441f1c897b35ef942dd49d57ca027d522dc445fc629718a189f635768623193b63d9d24dad34f906886a9c4d440885b3dedf09b0e362782cf4a500fad121c9f6a9a276d6ed43acc6886b313aa025583c3e890fb268648fbf0365b1c962342b9a508eab6e3503bf932788a362903d331556447ed92765ec261de9932ab65a29cf03127a6849423ea75d9d6daf11d9ab6895fd763e0b975a0a8749ed6f630b3d012a9ac1eb372b9c40d764aa58d304aea5f2ea4a051bc7b4fa563b55fceb8f57d0abce264d3ae78c2c2901d5ef4c095f1f12300d44abb0b72a49a136cee377da3facd36dd3e4f4e1e8e5bf3af62e9054d054e919ceef35c04237f901da625f5dda45a996bcf9445d02d73aed3e327745417108c66eb59b3079c7a79b11dea22a6542116567b7781ae338b8f4fe12cd56a1e5f0ad1b8f55e3c63288db3b19e994a391fc686d9a40875f7fd78ee6953b83179b1a9d6cd5a232b38d062814492f79096471b7869c8874ebf754f19aa53607b232ab9aedae6d15f8dc58f94a810751605eff4f72f4b6fb932d8d37ff5fd446b728212bdee94b4e1a0498308a816a97c377f9e8e220b36349eb77014dfcfb9692206bb0ca0e2558d712680311f374d3f8a6f3ed945675540d841d368b306a4258abb75663362f76fc44520adb75234da1a4f2a7e62972f1cc31175ade1ebc964000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a9991eaa4ddb4e2504e9cb17d13033e85454c8d0cf4bf9b6995baa6c2e3dfac229555166ac0d0b4cc96ebb8ded61be1a9907d97cc8bb92f40c5467412069eb039682ebfcd9737bb970fb448428087c3ef26b95d496c60a09244c71b496ee98d9e30eb1c02d452ce16f78ad3566e7c0df62d0744a31611c61b48fd6570736212dbf67414b5e5ca80dc94a14887d846463126992b0598842fc58360ec4fe23e2d1131b42c413d48fb99efeffc35e82ab681020450a822551322eea3303f0bdb277a06662d8101dc15794a8e7274eb31539ebb551bcebc7a0a3248f4613193fa4863e601be1d4ef496c1676538a050ca951c3fab143b906ecd7882695f8648050c44087bda8104491594dc082b116594c9cc79f9ef4e313e62532dc9e730c9116aa1e319b7586aeae8afe2569c5bdbd05e9fbad14d901f9c8c1eb885b5a4524b70d0b7c015dcb79abe98656463811fe6852b74de215fb0e14374a23ca12e57cab4800645ba0f4008d05670a53762ffcd2c6cda47e6d3e665bf8438230915aba864cb35081d6d755c12f90647f6255951423ad9189e9e569ad58d9fa840bf10421abcbd2098867ac615bf1e0872e3a5b046e0142599e5753eb1dcb7a965e88ea675b64cce2e96d8d89592a12ab809930188c17d7ae8d9014c0ef26f0d1515882ca39f7aca326c174223d2b58bf1ad581a6588631a8a42900e90494fdebe4806b817eeadc78b6198a5e4c612581568b26dc24daa860d4406c83194d19a6a6b11dd433002f043a3aa0abcd42993958767e6008141042aaa92eb5ae521da36388bd79359ce02829c2b8245c57546f5d793d662749151207910a69982c11a67cf262e4ad5d251d5590a3da529cf6e071b74583050c5107588bf03f6022986bc25972b12eb602921b3e4a61659c2adebd0a3188cfed5fa6c914b416ce7598fe8d30cba81d29224478cec9c9759a82540060feb9a47c743c232bb4422958826f5c951885621f603974de96e07167b160d84092c3cdf349bda2e16167be0bf9dd39b447cf1e083f8663c4af2e3db210179b2926cc0dea0dd656b4bae4f8471e196950bb10b325f9116c43e6b392392b39f174c71c2819faa9b3f5eab7870d0838a940381876fb3247df1124d9e6016e0fc263ae6373381a198bc68afaadc18d9d9d89d0d201f655e4eba6f9870fbe950e36d710c8634d66d4e954361b56baa8d25e8f9d8240813007bca7c91278bcc837808a7d278e66ecbb014380a328081d58e420bb1cf900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014a0998114c84f84080e7eebb47d248980fac9d28f1abb6dbab3dd59a5cfd2c7cff7f308372874dd5447c7b02e30165501c0c673128e4c543a414222bdf47e7f4e8dca757b0f4a3281c0d10c4f02ab52aaf5b9a715e012607ba310947a60a5f62d6b8cfa96386d27cfa709189202421c078934aa2d955468e550ad4d0d4acdd98b168a9568e232192e92789830317fbc959087fffe353b6c168f3efbe7164444f1d6cba5246e31658c65440a841dba78257e78502843ec1a6e9710229c8eeb85d6cddc7d543285624aa1f756a5dd4f1a5d4fa52db8c5c34880ed448fbb6d254509fbeea0fa022f276b6a66bef7abfea6049ff74291babe781f718683397077b29fa9e2b46bc6b09251e587cc5b182195dd4060cc4a319bfbe251a5b660a739dfe5d0e5b93f3cb7e440194f1c8bda922cb1a3ee3d27edfd61c1d31a7f4534e84889ec83b51f164189276643400000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 9","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39279dbee6da8287c0d620ffada2de28eb0e9f41e2e79fdc92b43d4c6580e441d59a4129be0c21ddf0d74edd2ff767aeb8b182b7c252d9fb199db043b48b77fa53936b220cdcd8835a5904b65905d3129495d8f1c27858a462d140a0ef7f7de8b2350e82faba30dee6666f0d2cbb6f6c08d1cb0eb90a38af4b30ceceb2df459d1bed4ab5fa353fefc5b575e98bd326d9e9e718fade2913302833fd8798a2183fb452ea9233c35b01a59081b5fce34c6198460decfaadcda5b23e0c370359136aac704304f73b7bbd8c229851a011ec0a874e70e6f8badb8bca334e0d1ad49daa955a0c6dfad89935adba89d5a22f2287fe442275d6d0dc5e87a6e0d95c769003689026302761779850bfc488cec56129bf5e3876e1880cb76e58faee7d0d68e0a41bdd15030fde95c716369eb3eaa67832664a62486a990945a706a9609b8435e3636089052a0afbc2aab5457d2eabd7579a7121d6b3443d228a2258468e56a2c56d9cac228d05b613a994d1129eb21c8c0a131fd87b9338bcafdbd6bc7a557ea106621a5dc47abf2241dbccb896dda614c2c5c0c48d96bfee88779d3c2be69cb6a84432b6e0299a34551a5435697b6b118e5117ec0d6e739d79b531a63d3f840bcf3643119264bb7443bd974123954cbbc4ce5e5a75834750e173309dcc0d8d1945686ca3e9926d4889ddcd43e0391d98cb90078abedee3d1e218bc41e5d8b9daece41a3db4b5ce4f6c086bcf2174713e8c028700d3f8123d1d864b08ada0e9bfd6491942cda531b762f74c19a6a3a6ced10146997ba4444e1b1a8ff8b2ae8c7a925c12083fe605805c87e15188ff33999fc3aa380a5b83ae6b2f9a8d5d6fc9deaea7b2934b0ae2fda88f9e489a7b5b0ba230fb742eec340b7e87eed8a575b5cadfe7af2ead8b408cd49bc4800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810915cabcc9c2599f6b050af1f915f03e54213afd25fc1094041183e4dd483802f11d15a22dea54d61b4bc688d577b16fccb4350c20f8aa6f289bb51b7802de2b433646a85ca9fc1fb91bc4fc8f43354d7e50e2ca6e89de682b2be90879e05acb1844ed4a4d30245b2a9779c23365c01a92a3b4faa03d9ebbb94eafba28cb45be856f185317c84aa4a742139404a3ce7e570393d60c362d330c1b29234ed0ab5ea44c18e67e754fa4bf559c4fcaa86a758d8ae405ec0c9e4e757da1f349d302502812e7445b44444e57abaa2a69ba4789bf1fb96512e5812dedcd9b62635634539631146d603a1be880f1fdbb386407327633593f5d546fed4b0872a1700a5cb8a302d80625a698735cc4086bb09c38772fa083552b05f983402e01a874556a3c411293dbbcc95621a2d04023a24c7720e431c85d3b41f6da564b8c859b0502e14beb601aed0b0a7f5f315ad16ab5d240622fca43515a07707d1ca101872ce81f8caae565267f8d557ef4af8934434e7d8ab0eb85677c6622ebc08d261cb658e1d53d32483924ca03710d907a2067540e2fa6e07ba9d5e506e9324a1382c02b9c5d5947c7ab8211ad9b5e898c90099542e48fee8de131d1782d5c031c3ad75958e35aa86c964402168b7544a8460b3168eac09742a1cf56e227223c8a12136090f2f6dedd4c7468c5d9577467b5a284db5e6db70d8b476e4caa0d8ebce1e921e15378bcb5cf00767e4429d0a18c08268960074b6b7b219e45e41c6d3722d981395cd95162b15bb11ea5590118b4176fc4de525ac34403983695a22ae9fd63db9da24a40586806a80223d722dfbe64c55624b91c25545c1363a89195b29ecb9bb44c096ba5b5428acef3690a014717e5c17612ef69d9d3b815ee0ee91b2f5f06599c70ba879537b9c693364ebd837c7e82fc5fb5a13254b44b50bea7a1852552cb0350fc9d933627fd43711d21030514bc89c75b9d6b045094cc067012969d75d4d7a88854a6d276e78d990325391aa3c140771bb11bc99e9a533e818106425999a56ca8f35017694fb02974625de749965f2b4910da46c5ac2747695b44fcbbb8ae66c941f60ad60245df776012d2581ecab791f898bbc3b1a176ad55a0971353b212f6aa176234f5ac83eed78159c8c891f9d83a2ecac82085aab1b26c7119efcc7d10810961f946033489bae6c59cfd0e8e33891feffba1e0c47627118331854e39f866e40cf86c6747c144adc49cdbc745d34e9c52ab462006abcac558b7919000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000016b4cca95cb9f254c2eaa7dcffef662ee03320d5fc626a6484304bf62fc20f341fbe26e1537d7bd20e95440f7cc95ee84e1297c807a0bc9006dfcd5c22a5c1fc0865f5d70e5d63ad677fffdea52bf85d1a4f159f7ed16a745b4d971b620048b5f518eb2dc672ca35022578059e1adad7c07fe910a5d566b8321d9a12f34c250be35ce964dddea23c90ea77c9c1bbe3532feefda3637157786ec7d37775ae5cb0bb92eab45a0fb1e833e8a6f3d06b85946e31a79b64a02b31fa640ed514a85882c89f693a06354dfddb0b5e23e7792134c69c1d3908882df3a7694a05b241b87fb2dbd1a4d9f26943b69f3cdf730301663089d1ebfc23299da21300f735cedf7b109f3e0bbe273776e6aafa7054a6cd9682b967eb7903de549e9558e62dcf3ac444dd7042fea362efb555bb97fb464ad7faeaba3197c14a6740477db50ce3fb8b762f48f880381d510fcc836e5880b48f08bd6333202e838ab73f2e106cfbfb218aab802da8a00f13f78ffb70c000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 10","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000291398934eed6bf931b3192b123259d3b9c3046d22e9a9f58faadcaff020fdb52f1948b12ba0d622ddab15183efd4940aa2b9a41d74dee79daf2a3898ac762024e94b63eb8547691b5ea454dd68129a64161a5fde9c43728b7d7ad61f148d0be857b7c5ae10d621de2f52a4badf2081be895c1d94799a98b43e550fd79ae81166fd58ae285216a7b94a5c6da92b28cd2f99aa05cf333225cdc5f66187b76577b413bf605a2aca2f0b9b10a377b25b0b1f0162b159a0aca8f279fe970b3c2b2b5e8ffca4f0136909e0c3e92acb2d8986152f8752ce9da490d6f1a961a55bbc5d767cd121ef860a1562b7a93124a4bc28bc0b1243925bef0413465eb53b926886c31377170b81de3e923b1215a3de6d4e9604c63057feb6c9848246f0f0aa331c3a5003499b6e465d1782a06c18d9a9292540810563f08476e42cd2cfd83e9d09a6ad3c75d4ea3d439881c5dd8494a4c29dd8d759afdd193be7489732a18fd39093d3e8bb35cb8ddd984bbd7bc565b549faa55a668f3b182921a96b6acc1c0f848e50b248d7ae1448b15862f0cd98df6c89938db53d5ee991f4b214c8fc61eb5a62283b037247090c118d41a19138173f855cb419accc297bc2c68c4b373c5e8b7be490312647dcaa2872892d9580313c38aba3ef631cf9124b73d31a770298f97198f71aba6a91e284080a33bde274be9a11868922085b0ca2d8641e5266aefff92cc23af03868cab5c566190c461a490d2bba2ac1eaf3e7987a43be98ddf7a9fbe7ca55dc2c5a4a613b829f63cda88e691a98fa6dd1fe635aee1419cb551feb1166ff6aad2235ade1083294294c21ae435c9a2606466673fe8bd60ca76ddea6273d7adfb74a2114528826d28bbcf9fb21ef2c818f5b8c6291604ebda40e7a85a746298a57be8a049c8ab17fdb0d4285dcacc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381095852d077c210623c929f4522646f8195e329366c814d7a09007f13e509120192d4eadf981643461022e15541ffe164ca927359ac2203df68901042db76d55d215a54c50dd702b05963db06e1cabbe5cd9aefad072f35f4fa4518d390e5358751843da082e689772b7f50dd7ba41cc86881bd5dd4262a8e18d23ed19d8ac3675d4776f7e46466225ac29d07784624f811a9a4cf26f8cd87b18a824d3156c5deee7370a5dea2dfc31258f6d8ca35857ea249962ad71893b27971f5182be714a946a111982949dcc93425a25b1082d71552aeb97ca9aa6a018e868c1860c9b66bba88ce19a355828d8c1c3be088eee935fcb0583e5c2f8684009a3b51fc5f2d69d38a54f03e613f15f8570a183cd4c0e1581c491e3db508d339a76a10987a93f505cce5e537e29671316105681ede3b42ed44c207e07ea105e8c3226a272c50c03d653e496686334c983e9a4118d4c5a81f401445f71cdc7176ac9f1b6dac1f6cc5aa4b361d37bf4c2d12cf1644385cc3f04461173f008122c764430589014a65c2b819b4f6d7a3dbdf807d21c2db8d4281105c85a0cb37237c353551a5a23789bbca14a0d974b83f9540ece712b9d856fd40328ababae82b20a54204de57f34a71a820ccc42065980d35bfc1ca97106d019cc0926f85ac55fbba2306d89b3ca3d07e8f2c58f02d96ed599f5795eb24620e575c5deb141d25cc41324e15b29eccbfd23694cea67e65793a07a5c869b636e5a870cd5d70644b28dd924a4001155759d9517188a9709ee275687a1c954f4de9651a0389c3e66d69c5688bbadf159ff880454dc3f5610453e6bd663889f5d8d1b12cef1ad97c39c7116d35844813b1a0c451fc679bdbe7391b39ee0b60cfd77326e6521e1a4ab8a556b759936c56814955064d266750c38781592275e0bfb74e9232202c46164226c1357eba92a961903f41ca3731a6d8442a5b98ca8fbb11b11e40bfc6064b16315ab8ca7735e578392e5a316cbda0066a6f93a841dc28f3dacb7a887a748aae6bbdae6869a142a671150871d79eab1ce431c891e5d526eaf2c58a1e445569280023a9e0012afbd774e7b1b6b22106615fc89cbca938d65f558545b31b24d67474421706c463877cfa95bb0c285cafe9f0e34390ad6c560a3a1212778dfdc3c9ba695a60e0bba43948a3b6b1b0810a0a218c8cd4e68b4ce9629ea5eb8d967b5a91b568162a7f2b25edb67ca95a332d70a5a686466f46e8d23fa51d0d1a59a7d845fd13e54e6999e16800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000018c5c4b2e1a344da1418b0f4be3fd99505fc30f2a1e5b696e943bee2451d7b268f722e04f8e00fdd9e1a470f8c977a6d45a5f621b8815e352fa14f64977d1fa08082a48af495719ea6ac1c0b3d898603b4cf7ec88e68dd7190884382896d953d612cc21abecfb01a04a1bb1bbe8986d34625756396ccd84bd1a6b5454dda98824cd4844d98f356ab485eeb19f9196abb1c3088c0c3c5846c88760b696d91a232d6f4cffc85bff33de1a3433a27a209a461fcf37f2289f98bea7ccf183db1fc42a7edf958e7913f8711dc375e43f09be7c7a2c2b1318ae2a9cf5988fbc2ce0735a2cd9fb6c8496c34406c538c01bd494193240bff947fed47b7cce99a1747973f1faa5223ac564bba0ca8973d1310b5bfa1452cace9110bc22a8d4080a8baaa8adfa3cfb6685679b648484e3a43f9b1b2531949bbb8fae1846f6d45d9272fc2caa2913b5d9f8d322e9b18a685122d74634c60730c101578bef2480711feffe02123e76d6c846559e2ea99a98923ef095630102a5573ef027e0ab6e52555a9ede0d15a73c8b2fef87ca6fd9f903f00000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 11","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039a4dca0cc1dfeb7cbf5545b047972dbaa8660f41697ffed4141f67c1e542586a0b3e79852883a9eed24419accbd49d4b759e6780645fe8b3f6f2b839d2c30ebfeee18bdcb2c683687f0e68faa2348d26fd49ca9a8a5e4e2077ecb04b120eb0906672e9de392d0105ba628f3fab35eca4b8fff8bf29e6cb900561d98af1a3ea7685f2deebb64e292c395eadeb62ebb68e053fb6ab46d0a9ab20bc34fe4da60ec45655ae2426c5d94faa89d2ac73318c9621f9eb918a2b7127476faf7c2afbd0b3e092d267901c2df5b51e9a675ef6ed248fed3705af511691dd6fb08d7ab8877e5a379fee501ade965cf83c18ed3a28b5468cbba0ef5f3154f8c5d55b7999562d05eb48212fba201806826f83dbcd4ae8a6dde2331a5aa9c38b5f5217e36b60a7ada8417d8843d8a60e29d0dbf0d689afa9d1f5c2d95ece95706bb36f81d0b016899d524741d4a96c891642baf8a43f2146c85d1c82cabeb7d3f21488e13a0d35d6368cc5275d9875210c8a6228e73d6f5450b5a31b70d36d197439bbf43788574f78b49ef72e8f4b711eec715fcebc93e799fb9ca1e4bf031c604f6c190ce2411e146725ecf8aceb66d72ae5efa50ae275b48b3c5d7659c085336d316a3ded94be63f582733b554de9933852f31aeecf38b12aed7b34268e232162f0acbe7395847249eb148f133195925ee3daee1e22da91da652fbe71457a3c101756d11365d7b6c8d1d6a0edc72b0f56a6a7ad368513522dcdc4231fa299906d34a9934b57e44b80e4e8b63ef8f3349acaa3e2710672446b70e9aafdbee682b5dd6e56f12c4aa20250c5feb99256b1a618b22671949c1c45cc7cf86e0e4d95fd6f19d61c795ad6a57133c84c84e13dbae9e4324d39674a873a36c2f31298c73e4490cbc8092ef7b44429dd51f2d7cbc66ea5f15920000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810975c13f126fc162648c39d4cf8b3ab76e15e9c8abf032d15511ffd1afb82491964c56dc295d28d0e39a4e2188ead42dd503a2ddb211f1e3088010b4a6058d78722d2c65758a4721d68314c5980f13ba07a796599f640cfa9651c77d93e092c6e0085073e9f61b54072a66adcf822d489a4cc9b9713d5e79098e9e241eeae432aab3e80316652506faabca6ac7a6a874852d9754061a15e1e5a7830db9653527dc2fb0ba77c93dd3b80d55dbc2056e3175f62d55be49f8852eadc78a879b36cece26cb6fb470d2e5611ea845371eb3262107ef281a6f2af40a616460a9a04eec5f24a10b83ded2d968f902d2b892e8a0f2c6528cc0d28650b31a049a71ab020e39126b8f29191db32997766f8ca08b386eb1372ac457b45a3c326abe7addcc32a8f6114b956506a1b0e2f18407eb5ce44ae86ea6e769a177d7978afb4ec614b624d84f5664a6531a28e67c74d3443ae4ce4cc44794009453348122d2a79c950505e3cba752ab8992e9f5498d65456ca270c56b244f64af532bd4b51b84bdc1891bcf563a0a266d24b994506de2d3584f7730de67e95f449d0d7f831ed8dc37d93309c84f9287fac823d40bbc3800cae3021a4c287dab322a02411962c5a6dc6c5dad95c9e64b0ee781051e7977e398795e58d2bd6b61754e5e33a4a6cca73e3ca3f0a6269ade483a858bfdae4e122639c0c60da8224220193a6c219c35b5045c15ba35fa824d28284d2c19042ae15c582f2601cbbca7a0788b60039d55f5bcb86989a74af58ed09b80c6618dcaa5ba6c5862f9635a37145fb62d6d47db9c6322386fd39bcafe213193b4dc08e43ba07c9ab2d2585d29067bcf0b61636c37e96621800bad62170a44286ed6bf80a8e00129ec2845ae8cae2f60f46a5819875c05fde3e5113429a5e77af66e351105f0423a57db21ec0e8211843271044c3365630a6e4cc0a8d9e1b47b7ddf172323ebb354a3292ac4c0a1add510019bc3b6dea65a98ce4a14eece2409828f9f45808033ebc17b92869163e9cf39613454d868915e224b20d94bf5348a0e15b5444e73e6ee02f3a8524198edabc7dd565452c9f645c1f97461c003e6a179515591972cdab44f5af6e783df8b88788be3698bed7335eae9a7085d43d5ef659edc0b07be5837a8a99e99cec0332140557ac43f26a119a5306210366d0f27a3da4bd7dc119a49de28f483919da06c87a8074c4201096bd5662ad5601d43294cd1d633419257ee947f8256744aa06fc820f48a936e23e70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ad49755a7b1a7cdc5c9bdf5149968061d3c95ee67bfbaf02750c45094303a9d9cd23a08f19b9c768adc63ffd1527186d09ca4e0356bb882e263bf015cbe3716c05b31a69dddb790ba82c341ac9b6be68a81b8bef8d882304baf0020d761a0db04412033dc369961a5213b04e81736a580f1162780599cc029e262d67f31b2773afb457a1adaaa292163144f17de384234f3303111fcd89bcb30333c6c6486f775ed099043c34e6c86450b650f1a02d03781b1d20691b767d166dadf1dcc4d8604d976efdc9168373a7316dda9b9fb02a4a321218d9f54e287b7167a08bc0153843bd6355aea1310824dd5d5ec458be694af176119d9e588a29c650ff5500293659ea478b39a62149f819cdb7e7cb32e1d7b1284f159e2ab1b1ea41af4d0ac94ff3111fc1ccd818f9b2cc7a259701405fdf6a51d2d3ef62789297bd16a659f14968ef902c4a23da409bf13a4913467b5c991854b2ca6cc006d3f4197a6aa58bd5dd95c36928da9583332c3fb134fa3890fe7e299f1c17205366c4f4230724c43e4803912e72b816658bbb1b63780865a1f66a2a49b96e93711b1be97b827d12173402828b1a065b94310d5bd6098d00000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 12","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039376d2e3be492dd739ec253bf85b5ac7a211f093a3e5cb1008b84836455ad88dc1dbe5ab2ba9ea44ecb9e42734c023b16604c73e1c0eaf6167fadb1d394a404a17b18e6630e94b6c678eb75a7ecd95c84c89a44613aa1af55c6f9a4d5b21ba2c0c9620fd291f7a8be8fea2c4a6a1e557a9f57d2a13389221b6923ae8d0b2f224453786a1d3f873f7f6dfb91b1faa526fea5ac8bb4e6be254ff233898a2afd5f2291d849c2a2b14d9cdcd950ae6dcb93252de2d537e9cf6574429b57c1b6cdd3410bc350ba4883aec4404714acc9618ffa20b626debcdcd7668fad9449a9c080ba0dab25fb81390d8e12c15874e5530eeb58b35515dca43a9db4da2eea4cdd9247fbccc48d6a20c9fea9289df5d04524eac5fb484b3289fa79530de7be3ca1304430c3b21325429b2eb046b0aaf7b271016ef39b0c0098323e3623c89c3d397553869a59f6d2899472fbe7bee8e5db34145ff296ecb230b335840128a858da460cf6f02bd52d035f7340999575196c24bb7abbe9305967c4b90dc466a63e2348d116ede4b2dd43f85dc812678274b8ed0bb142b6f38e110e70db5687dede4093955962475b8438b9d5f9e8e3a6447a5013e131d9bd8ade1b9f4052e785a9a97d37f7692c4e55124c3ee55e2760f1d7d27a76bcd62b28da2688af53e19f86705e66966d3c80684a262166824559ed35693888bf9cccc4f4c6542eaaa3bea234294097ebcbebb93c86843f2a5e666ab6f317708871bd6eea0c96f27b4ce779bc5d604a7bb50c1cab95ae46cf57f94b54626b75eafbb989d562b2c77ad9f7da10cb6938945b1f9b05e6e3494848fc423a94feda4dbf408fd7c51e9359fba93a4c7bf4092ec217d93910170d4ac018f85751de8504573b5381139a53fd14406788b935786cb5c5de55f3b413cd7b0704ab20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381090d16c993154b7c1e11bf24f8a4b8915979a4909aa50eb06bf229df670536b3e49f816eaa4845fb948e03393466f51b08a48a4c6fc8ea25080f04af906f462a0ce10051f289056fc56da4d45c8d6d86da462e11c9b9e1c1b5bed4059c644afbc60e7f5ece2b2ba80febb64ae4b846078b72d4b756330cd1b078786304691019c0a5879619b91d12b68aa88a6085dd2312aa41561730df41ab057607ea28f89e894ca0997bd300c52a6a2c56b13322ae7c04191b8468966e568ab6216dd73d5a6da35652ee95d206532304fa75dcd323d3e6cc262c8228bf54883442d09bdc5309420c3246a9e2ba65914dc6a1127e36f2db199d0ca12eb4d495a1ee606841c896f656a9887decd02f6c763d1c260907ab6c94ecd39be2a4767ff87a0403acd71fd4d137f8cd9d3a02646aea8193aeb01ee4b15e824509018aa3ecf1305460cba55244ae9da0469f21219c96e212a85c492f4ef93b6cd92ba54d1d4537082d5b3ae92ab36d0762a827d37140b06e62ca126ee918a69c1ca3c2ece11134974b6543e90ff5767b674ec48d162313b0ed788da8983032e389b871b826674c4f21be10b7194d590e2828ebbbdcdc905cd36a5a16b63b9cb3f452a1483fb60d33b9d46b199843a1c6630ca0be7a4bf5e9f5059ed73a4f63ae06728fb871c843b3caafaa3f52cabe41e50ae193ae1c3577a349eee190a06df2fa9ff59d32bab6dd2c088621621a61c23788012d95076df6108966d6a8a01e8010c808bb5ae356711ba306c0be1a58cfea3a25c91bcee47013000368def448d8d054071a6dc6d7d098be4ecde55385fb40052ab968d0e615d946736f511c04f98fe4ae47c54ac8bbd8661cf7383948b86804610c9092b8271dcd81f8ae99ecdb475f7ee582d8132607d6420019e46f40b5c7eade5fc577cde51058ac237cae7b0b13534a89ea2b786dec6f4e9191f69ec82fa9b0d39a4eeffe570cb1b4ba66281202ab9a93604b7c36a0085c08767995a914a55cac59ddf0732c2db19619d4d9702d800831c3e12ae607200634375aa296bbed1e45b20575791615505809baa7290399275861affaabbbbc165093b43823ca09134f22c497e2db2704a1409814af2f048eb9612ccd6d4a3c30866289be6328d341c9aaa689889286fd5cda0e195b448d139a7775ba921b65fea01c7cc7e6d3234f44af163c48a812b687b59e58cc0816e0f552187054a693da6b05f4532291384ddf1f403875c8410d69305dc7724c81716c7905643b0a630000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ce439529df1864297e33956afee00a60099b658a67830a6a6abddc329e87831d9f9b647917fedf1ae182a40402143285516fcab83f447354c72fae81ac26e7005c2aa561763c152e66bd80f14565f47defa440dbb491e7994ab9fe35995d5fbb3800ca030b43df611141637a5246ab9d9cac02efe14af60736b6bdb2babb97cf21e831e5d04d41c00f090b154977900efadd3a9313389a3f84cb3ac38e8b57b70a43dd08a8243f8154013fd5cf29de5a8df0b197c12b17e0610fcfe3625cc94067e01e23d23a243ad1c1f805cc50e1447d1df93c25b8d76396bb7199e64129522462c5fc8b30c132d4ee9e0bf6f52961fce7ecf650647e7064aa5a6574649a323e144d7c5491de4c0a1a76d08f93f87a2fc7f6955fef86991e62e2cb42908e83b0c0a8bc180b7453ced293f1e20f300431ec1d395e8a537f0bc36a673d491f14381dea90d8f176d06031b0a7afb40ea8f76d37fa82e2572b9799a5fc7cf4c49bc20ad78efa8cd989a84d72ed680ac3c0f64155c56acbfd7c7d628b418a489f961357f77bd62204adb079dd3106485a37fee535c9cf82e832d8aadcbf686976b806b02ae733db46db0bf162e973931c3e338cc86db38c66262d1b2ebc7691b8281e0b20bf36305fba996d20ecfdc695000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 13","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e393352b8693a74f57ade97a2ff8084240e6031a4c80ece2c8ec24338d723a615ff3255414d9b0bdc068c3a7bb68cf39c7ff5d25d92506858927b149b50770e1f1ed516a672d9f32da625bddcdd1d8d2ae9bae0d0403b9c9d3921c7aeaac6e1488aed22f1b4d929649fbb1ff920e32b7806410014f2835e45e3ed3407d4fc34b89a8e7f9fa8a6aa707fd631ca57735195070feab8330866318d6d6952d751b2bfa3ed533fba2ba88d29012b523537fe9db58a135ba2becf89b201832a975e24d7652be21fa7995d7af631ab0be87eb94488a13678fbeba188c147913d8eb336b17e449feb0681ece0896f1d679df0751e971d9aef8d7fa9645a60a855cd17e7e588fe3536359134030cdc62344b26251ecd378a875289aea9e7ecc8ba40e5e0bb105aa79e17b0a28d3d31595fdda771e0e67dcc9ed690572253d22c93a9adbe9e8107eb5be47060441558547e2cf51ddced2d035f5be78685dcd0bc7daa27dfd92ae04619f2a145e7e7302d0ea224d415e876d1a8852a50d86ca1198e329887fb8ae0c0f33d45d48cf23a8a660c8bda38864ce3b4aa74ee8d5128ce964d9eca33e42d21141cba077a73374402cca4f308b340430c5c45a168e5cf7edfa05514a9bece6ffb7cb26cae1ce045ec8b7eb160627247131dd1c356254902d46215a406d78f60ca261e7be99cff1cfcfa8b95ce1ce33457a47484dfc2f8d77078967b1ef840f7ee67f2d69e1b5d7c917780c3dc56ade992639909fe29c44f5a337cb5197c21b05a138ca695aa215423bf5a3b132cf324caedb1098aff25449a65074ada2a7363b8826310f8a7163fb861ba5dc4766523a3731879ad766efe4af7f33cf403113d45bdf09e46e70de095a0548bd3c8aea710299b148f60a71d884b40ce51200fb79615360c27763a49947c0c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810951c93094c34b371a38ddf23a08d5094cebb9654ef04784fec75fce864bb98cbb3aead27eb64c58bf06611082a487ac9350b21c59657d8de96e9a97e24f17771c4aa7b56d628d77f8d133fa4f9b2deab3a4f21d2ca5308be23a8ded6de17996ae2b95ae3a01071e608bbae47a82ad1fe127455ab5f3d2f7a6cef3dacbdccc4deee247874831acb048cb6f4198ba9c3c48d4c1ea2db6e2d9a8c590a4546882050ed866b0b34bde86d003466005140f0a79d62417e3ac7a70156fd2e1c1842cc93b7af704a398e8a5f2cf8a7e6e2a0faab440798a7508e5536dfb40dd0211df62e392b18424b707d8577d47779325372b6e1183a60781645a2556eb55ec66aec335eaedc72d840c82830e1d1ea9c4424329284d44713a9ee91a3af6e1473814beb26a2b0ae9ebae38d2dccb0586c581c2aa518deb3b32d5c0049582d5380453e32f6a47b7eeb50450aa025c5ee9b3a0418b2b1122117f1d34b5ce25d6816ee4385dd577ff067b68255b43fa0c95421c3fe3112d9c461c4e137824b02648a8cb6383fc4f22dcfa03d4dba5da5c308da370b30a3d126c4ee430627274d100bab07c4b3200471692fa27d60a9926bcf112864104842c61ea45c2ab838d7d2c30e86bb43ed44531fb1a3004d25065b0961806f936f47e2dfa6e0eaa0228006222ad2a44776db37506d98ae3a365a1164a373f2eb76d901e9196596e1df1cbb6d60470848d7a144f57583da48628c29d1b2bb8ff87b905526a643af525db0f06f614c1106ba24165010b38204dadf86846d52406a306db06a5a39212faec23044d499b844349e0cf3b769dd016e8db42ab3ada291b80a56c1c27d902aa1c47bc20015ed478ad91dd0b2118ad698c77073286d53801ee95c7ef7d1c610082575a58a55e80065aa87c971169e096eb8c507907a5c0652207bc2a69fd0dfb38154475435b6fa1754bb6cbef7470c852d4decef5779d5b14b4955d87a8dfb23e8a4bab04d471cdc2b182d0f4b5e5828f9c697ddb445b628fad1842be2cf71cb24a90f4c01f45724a675d4dc13ea0f627468e7303c086065aa7a51f08f7e3d7208d541da44044a4f831364fb91b044132c0a12588a94f74509054821cee8125c112c94210167e30f6a517e507f04c0611638f2552b7944b80648c3429830ac26cae85b667b34ea305d48f7bac05158bce57401ce21b227842b88322c0256842498190b26b5961cb829690ba8cfca1aa61bd81cda008362b4944d5fe03e746c294866ae04c62c60000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ef8cb18850e27d8416b88a9a71f4a66bdf447814db6c82098c371b53f61600ef5dfd88e4fb34200207c3f6f55166af4878d38fca7e2dc18fe662e3ea491b58a86246cae16090fb7ada53b9a67b3d0e3787d3323ea921274c60cffb19a889bcf0300fe10e242aae025f374dd83fbe9d007c8b9d9d75574c74146331ddec6f0e49c10dbaf15654897e33e2b4780dba484224aa6fac79015d5792faa2d532bb7d239b11d91420b98690b1fbde9632223927e0804bfb284368a426c414c3db8ea82f0d246413861475ed2dca9e80fb4f3c34fef7528069ae1975afc52ac5ad2cdbca1459e140f655556093210d7905a1a1e6ceeaef0194a0b2eab2c1ee853484e715d2a1db551fdc620d5331164c74ca4848b61d408d2f2a943fa09efeb63d524691c99dcc0b22cc61b98e6fb8039e5e0b2d7de2caaa900a44184bd56c9f02141a3ae8afc661e3e898ecd3004fdb0704272ba780cd5de35153b6fe223843024273642dcf8e4b58be2ab1f61668680084aa0b75a32e766c8ae5eb30d4e02a12e6798dea40f80d8ddfad2041a52922701c689f46f49f84cfc05eca6d7d4c356d50b6a0ba61966245d45134d6a1f5197540a1c39c36bb0b78831af3f5156e669fd9213b64e0cf1c5a31e88ae79ad61757ec67b551b9f0a760f646bf81f6b92403a62840cc29fa4f3949b3a9f0a9a4286ee7808a0000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 14","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029439e0e18e05875803f1bc8344d6c6dbe9cc137cea265ba3bee061c86b468244d240a8dacc65104512d31771d7eb7cee332f4dc9431d33d548d15e6d5b16e11d6e12dfad966827c272fba0845db2d2124f239358555782f1851dfaa69c8ce011b09fc83b51ce3acd8bdbb4b08c32dc97efdad7a6602f9a6cf0930cc38b20deeabcf299c92563a7d8128d574306ca3f9b40e1a4caf8c3486913455344d79cf959b32e1ae76b7a8aa5d9dcac4b67b465cee26ca7cd22cbd99fd4cf072a764d999c4a1cb78b4250c11539ef6f89515135b4284a24af751f662d576a59a6d89c5a930b86f277085032a685f2cddb3e6c14aae190d54c77b4161226849cc465b875b16959cfd61be77fa48dcc2f89992a84ae0cdb00f3e1632dabdb679f9db3e246d165d50785365c32bf916098c55e77cc230a2401f7a9c1a36655f1dcee64d667654c5eaf9dc8ec21d8f36bfbd826af170e56554dbd64e0f9521332dda7738ae22ec9196437a4c4b9d637ce09a3ffa632b2930db4fd623bcdd9a8320ec0edd868ff187c25277928b9b7251fef9973b1a72a1a48cacd534e1a79cf34a2929c6e3d901ecc329479713553f5095251e49e8b93c1add51b2c3108395f453dc544a2b848918056918c5bd2e56c2deab8e0b5f0ab0bde66e62f6da342ab9247f7a29bd737285b127d5814511a667e8cc9c31dd9f20341ea73a479b91e42acdda0760de4e20efe745a2576496d637459d7636120ee5ee41e24ec4399eb52193b39efb717f13c7b18ad059b4c60b05027d36bb4625d543a843889f2af03bba3db7d367ad32025eb397e600d4fe27c788e34e068112664a0cd957522b6e3515d4d3359b8696387f60e8fb872ec11afdc3a70d8022cd0b316642134a425739956e770fdfb5e152f8f37e96bcbbc776ad0635e584e86c5306a947aa20000000000000000000000000000000000000000000000000000000000000000000000000000000000000381090668b7c31511f2b5a194415b57d459d43a7363d3a563165c849781f9be8a7c67ee415430edcdcad16ddc8dfc6048494a8b42ac0482f89052af16316000239c1c59c83b609bdc9a6191073362602dc0d3f7a49d9472c262713a87fe78682c1b155dc09786a4956006cc840a36e302962eabadee506ea417446ce07b0d203804e2ae5aa889072fe583068a63d9106e59cb9011a506b9330802c56cae015066296f89679c5d5488699303e282231e414203ca6552a5e7c6b5de5358770cbc741902f49bded7368a56c12defc6ae26ea722199bd54603bd88cccce0dee37322b2aad1c40acc9a1148223d87f6b7e80f17689289b2826092544a43791c5f99b60672beba1f24c3171070f0976698639d2fb9fe00bb07452431f92bb955c16fde3014694c3d05fe2ad49faa0364d052665028551fcc9d3a7d6f2d89e120656094ba4120a70a891fb5bb18ea55bde8231c898406c388a42245bb95d0486e9f908cb82a95d083e9f2c6626b35a51a5180c813f49ad11ff27f434bb4d2a42497afe333caab5400468d9f520c6a6447d7bed4432ab747605e5a79534125d25bbaf330a466355ae579318d2c1a77a94a8a98a21835210cfa9b0ef71f0df2327d9b0babc6e340e002ba42b8cab8df4b6aa35d42726ea5c11096a249f21ddea4904ad0a52a4d57c95495e14e65951517ea0a9b6d9c75935651823951d2bfc731e6cf32b49c03ce93ec69d2845979460f6bdea9296a1e445fb65f70be51b9b12156dba6dfe30351ebc5744b55a2c102427a0c5a88fd5473f4c77a552af471196f1d36922c4bfbc20478a20b05ca854629e294eb79098799505f6aa349907b310f0bb61ce2bc9e2a2864a3adaee15ad709409c75290cc0880a0a366df7f7566d0f3f6132212f47207bc45740cf20c25170aea74107495651b95414823a4c4cad7717560a8725018a49866347e83af90ac13d3322908050da28b118cc49fccd3d9494e58b6b6a7a7cc0e4f2da2ca96d304167c8532b0844b1b542132f8c988305d3a71136c06eb2e88cac01ac67d262a0b20886568ae5c1bf20d93507126b84685c781906283ca756d8b148ed8a688ab5821989e9838eb04215993500b83e785390a54979695819003709e607f68de2c30ee98f56a182ac42c9b0e3c2669b6d0e59d15a420560169956648f7cbd5d05e8b561fe5ced7185485ac16d2a745459d5f5812155b911d2ef76a190ebf049e3a75a41073604208aaeab1557853092429d39dce271a8165650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002109b64813c058f07a09a796fd764604eaf58ce144363702896df0ab5ff26d5de000d14bb8fd358ff5532d3b909ab62c18ac30f1900f84ebd3f4f18bd532d16c7b3470f0f8bdf72938c916db18bcf1429dc1635b1c152c5f89a9edb17116c11815a6c06273a889132923da908ff39f4940a840d3cb575dc4d637aafd37968ec61fc4ea04b4c320491a73ecfbdd8e10f1dfe902fccef93dd287ed872f67146bb8ca5a6adcf0350e8bba7f2f9762c4aa748fce19748eb17334146c152fd63fae3dfbb1a2c2b3c78960369551fdac5d54643beeaa59c1feb0c21dbbb19977d848cd82a7ae0005f45956e0fe4700f14fbaa0c12fb8c65a6aec95c5a5c8e79a6da9c4e446872575c06ae49a31b82245e1757c7ce84d6d5df3f642d3434b7e1a15a8b8a9db460826b6cdca69022dbf87595b582ddbb90a81e09a13c2ab1c125e4435ff30abc9c56a00edfa979f79d9c895e800d2dd6372fae5faacd83adf8a6d55279d52df547e9bab39d99076ad7d297371344d35bd584e0fb5932f92fd5183b9250cd180fc645bef6028c405b0ef35daf783428173f1f2482aa1363640f66af0fe8ecacc0dab84abd2a1fb53af44445698cf1ddf4c2ea214dd339be004e75bf76e95ca5c16981aba5540689c1c1f1daf4d0f89d62ccb3496340d61e7d5f5156fd3edd02edfec8fcdd0b231697b0e66f4a3aaf46117532f5ee2cb4d2b3b82b0beae0a45a482ce9a976cc99aa82beb0fe08cb68c400000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 15","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f3984d5eb9e7735978788025d7179a00d6bf62ccab7899e3cc3e8771b36836021b66814e3c0eb5beb35de99e4b06a4e9d83e92aac1f466ad1340805dfd4aff852e282d02cf0063f36eaec9b14115aec20cf469b0fedcbc0d61c1629d0da6abe787578c138e7877cc1228c0c475041dccf3c83e5eece1834033ab0957a822751e78cfabf2d74dfac44c38d59a0105872d173468e3a6fa2eca271dbe600c1bbfb0df4c11e856ebbfb6926eea8cf6cd352432b6e914873906b07172eb1f05ca4bfa661869b5b205ad84273c582a17d194f37056fd7a7106653f5979c3936fa64855fa7ef27d8453e1349623e635936596d4ffa1d0d70dc55c76f037c3bf07812851afafdde994bcb9247f108d4ad002002258d43331f7e551172f4557edd87129cbbe04b66d0d69a42025124c6454eab4a20adb5d7a5195ab1ac9632d997cbeb9c08cb6b5b916b18062cbfe2d9a785286d972fbe8debb03217d37f0f70b7e9fa146222240e7fdd7cf21faf16dd08286922367e985ed10735cf222e536b89b658b8610b118cdda8957ce28f56d6e189bd0521f6d097ba6cffb70967deb9fddb15c5d3e2ea31aa16c09f589e1f817df2fed2febc049fbbbce77a9bffd069f6cf76ea78e67a5424f11f90b64ef6bb9bc2c0917e0e3426bc049e597ea8f00fde3a78a8a8350e037f2758a4540ace0607a993d5a64f54014adcb4473b14e64417bca1add943f1e624f8ed531bc2b9854352b9de3318baaaa91b30e91278af163d8820a4074f2b841ab64df6fe57a885ce3a51d8ea6a8199a9eb9a848d5939d605c20edf2d8bf4a0c81d0391cea9e9934399666dd4148e3501c1a3bd14d10381987e2ecd1da87221798faddae4997bfd69d91999786bf4f3e3c741e2ce8af52028862ca9dd29636f6e7765f11b7eb30c3495147a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381096711ba90b854e52c55c3b74ad10d9e7c84c4dae6da3ca84a7aa98c519c64975a5e642885f6415a0b2761ab65b49423e5ac45aceb68394e2f1d7c75070c813d6694634b475d6640b5e81721d9d1467944b52c5bda1e704db1bf98d976480dda68c4c5bcd2f1a84994f6836cb2c3eb2f7218c9c5fb398302548e01d7551b7b9e7138e72328c85dac7bb2a18dec0e8c0321844883093d51fb91d4c769709842aed6a994c9f1184a0ddc330804492dcc2f3a82dad417d5d88924bcc1f9eda5891931d1bf8d8dbde544e4949da113c97759ed654073baae3162caa447f80470130dacabfe8923aaed0e1ef8a82231a7bd8322677a80d0f20f9debf1e40c01a50cc05b01933390b593d84ed4f6a0300747e6133114b981587fe3b089a1071074c4f873fdde8977923072b1b5d75152e725d981246349f9364a602236a94a1f20205488221269190585b663ac809254b6b150147642052a0586e2abfc26305b427b13360a58dfc912a510bfe04e60a89ebe82ebb2d5671565e2f3b582242221ac77c387c2bb2a3e13496cdd030a014037cba99806442369e0dd586e6fb4485c41aba5baf8cda30b1f21e0f84d6b7e8dd0fae7f3a1de2ab582d12f63bd351db74008e261890e5df49c17016b9eb424dccbeabd207da09d0c5f1352da381c5e88a94935035681bc3fb9e4ebd50b879c1c0891bb58b5bb9229aa4952bc9a01669429618e366c9a28d40f3f79288fe27825013c32aa41ba870098fc3ca97280e8225e96637e24a884cdb8ea2e6d137705f874b902486ed5c884aa05bea4b8c8f1048fc99962c9a95dd2d431d4469b26efac541272d649165853e8c259a6ed5db168c7c090448a9f0624535e669eb77567a7ad5a9669c4c7f10790e29321aa5110105daf26d990396d7a27cad3102d68355c724f33fb86f41e1dd3d275a983511220b0cf0bdd301177ea12e79e12ce7153c16ed293924cb01065887b6893499418e748f1fce2f7879f1f489414d32d68471d8961b2564cbddd99bad1622c1922c28be4d6726a2c30e8599a0c7ece9d06419736bd3d07f99c63bdae5dd122be57199e109034ca15711d5daf5835150e428ecc537806c341f8896b4f65dc4b88fca66b68fcbbc170f6cecc038fc6c661be848b180665c448442f13c12690e72dad98a6fd2a24d4101375699296524811c67f31fbc2e7747925722dc27d11c24802d4ab4eb7d4af3433ac966e902892a1af040adaf810b6ef305688bcd909ad9aa23ab1d64d5139000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000231922320f7439e492f13c272a5738ff7122dd7a6b2832632e1f7a653fef3b8639bcb9e84f482f22a948ea17dde6958489593d2cb268bb52df8ed612f2317bd6847d1622cf0532cb499adc432233b93b6f7b1866b38975ac87859ac49f91e8d235846775f9e6e6d052339c741ef6178016edb3d0b1e3f3536667b3ea2d489f88d254b8582421a31461374f465d7ad62e896be0857134707a70477fabc09fe0a5cc3b3f32911f5ff3806b878205525af69007f50535df05c33af3b0d00e297ac7eaa012e1d863dd5dd5fa47fb09467dbad8bc42edbab42a9625bfdb9fe578343297506a3b71cdc8d5919955af4605fcb0c7164d96a187aff65d0f6210fef2d11ba08d90c4458542be72e084577be9e451b8b6f4909884bcc5d25316adccd0925664d4d91c2e56433c1b68c632b0ca56d856df1edd5e113d1f026b30dac4fd648a504f8f6809c701c97bcac2b99286cef5c1c923200b1bf6141ee1cfc51c5e14554bc02d7e058970254d2c02948360abc4dfb439e66946a8ad615147bd8a6cb0886211e8b15dff3c72b6f8908ce56bbc1b40e838103202e9f188d98e07555db61778f895f76fbd838b6d14209d28eb393668924ac0e61072cbd9f93b864904ff4302dcea131b2ca16bb04959acee096b1963ce07f59ab505fcc8d89fe08fc58751965f2f5ca753d76d58705652d3b1505e0f720ede3142de9776ffe4aa0c8a25e76c7a04843377c59f1002844e89189e22f621467b813a98bf07540a1649264f14a6844d65692617f7a4d93fa9a23829e256626000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 16","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000290390fa3bdb5ab3936b09d5fa7064fa73f30c04f03ade50f7d05abb06897bed29934392b4efdbb991b2f833835e58f6502654c5626b108f692a45cf3d4b30418c3b10b4e49f98be511e834ca557b4974644e41702edaada94aba338f7b06b3e731126f2ac7319a5b5b1db4ae3799bccd37106f467f4b3909e71e7d876e540e43b2a7f41e9b7215b5e442f6fdeae706c7c165a5f0570cd54beb3dfcb9ed53952810f127e88a978a204f8b9fce6cde4ddd5f53acf7f316881aab3d5550856ac848f05dd6218b4d5b09d2c73245ab7bae553d2040939a322df7e6c8d999266197666df4d8fafac20ded857940da19f7c5f19fb16b9d1ab716e7c5384457150a49a1b8f5cd816435a88a3e75d0959e544f08f7b23c191e4a5e538c0c19e886757a36089a485f253bd25ffde76fd612210ce3355abff95b83f97c7ae241099b8a2773cebac311922b36fd57e6b5e5e67dd73688d97cc9cfa8bd3b756a8bce891071d7338a7b185cf3066af991b911cdd3cb007b7388ac6770cdd861abf30ed9a66f8b3f95cb551b4294cfd627ddf7d3c485bb2eddbfed07205ae58c8c3ef51f9b8b63f64dfbfd7c4d92828bbf5a5547b1598460b6707e063d14867955090139f5205406709fb03a755636bad4ac2b21c1318c84f612e1336b86e3d2bbe378ec11de667ac946492a85f0ecd384db34e6c5624fd555b9e4e7218c8381adca4e12e3737dd8a92a9e7213f84895324030099bc31b6157d88ee9e0f62227ba42e07711754dd4f3b12d2f19c2c333f41cfbfb567fc9562537d3910b94250e58eb063515c61856913743f52c8b7e512811a52a08917b22282c64f66e5a9c55af739a60cbaf32a5a9ca34700bf6ca452521b15dd2d2c510dc5210a137b72976791d5352758cceee4316c6d43d73324cf9b53cfe3de9ab2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109814a8d123c2b1c797e1e03385037b41eeb476cd4f598b2779664e6097141e226a8215744799ea7c1e2cc1e82eb532c17838e68a33a2c80e212047ac5c78e916abdd57032d71571c43a8b772bba770ed61b6128d046bac0049b22259a9a2761a783e72668c4e0fed8d83284da499e5d5b06e16df91f66279d7efb35470cdb5d5065b397a9fd4b1e6df9388582ae0cfe11d5c27d4a4c0253fb5e9698955d993e4aa5a7647ee3c081067a90e8c9a4a1e3195115f57805d74dada882f8c5ff41201c901b2630855479b1811e1269c622f42468985992eea3538fd67bf8cab3e9cc6a4f16f7d7a52872bda46a56cf6a823d462521b5ed3c0bfd8ad08e251a77251ecaf240496355c087b64f198076b224f259ac1c6d2d788e975987ed9bdbda1a87672c4303a25c514c543f7182df111401fe8b6752083df179b7af611f8771b43936527d9996b058fcc16cb800a7159f47959d2a04d98545df3d209d763f189d38183d16a520bc793e00e51c565056e635c033ebb51e9149b7f25e9a4cd6d47534e55f4a617e5bd6c4b960d6a673590c6751b82f50759ea620c1d7b02da0d1b87ce8c4b55aeab4d4af69ad2afeac01fc68214e0686a51cc978c38f4dec5c52a9a925b598942a03a52b31d95c795de2ec550c56e042a37f613682a9652d5819ea41c1b81a83b232a9c34821ff22667634975ac04935623731950d389ce6243fab9879e44b82809759516dbf3bd5dedd52a4fada0e6291012e20d1abcc535bc88ff1212d3876f6d76b0d92a7af6163b39ed62c912a3fc76b9fd00c0a0db65c4d07b7d60f082496954cd8fefb7396e1b09049f1cb4c04906da422c7eb3733a2934162655a71328f215b4203bc10574bc9e3e133d2b5b3ef527b60f09839be40f00ea0fd2ad3282a52602bd092d1ba2c64b01181dc5221895794cfc4483ed1d9842964f39bba8e3285cc1202ade551061216a158be9501e184880cbef9bfc5aa91755cb2b72a27bcaed79a469fa41a1d52d5996d77a465d4935cc1981f0aa8a9875e4b458a2164615a9157a1e21a45d3a5439e35b41fe811649df5c2af99397076db1ac4c18f34822390d368199b9679f16922e3b67840189e5471bb5a67185529bda998c72b1769a14ef58bbadee644458968dbdc02fda2a9baaa3946f5a2e0303ab09316aa4abf51b64def04d81f4183287962f57ba578e0bba3d98a5333d6f3b1e061e2f79808162288d95e05c7a30acf2bd4e997770a0d97f116d687b87e61002bc7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000252576289d10ab03d5699eac322d349f55c547101e4424bfa43bbba3747b79f075ae1153a7a0ac8bb51d24fc46b7604e42efe4343fa34aa4eb16d918f25e8a4d67c860cca3f7480e1221ed3ae13a138f079fc252c6d7bebc55cb81b86e74f339614bebcf7e8f4440df8678b01a4a41b3afb1d112fe1c4c8d8c6bfe9d3ee2a335d477c60fbf43b2e5fffe1546f5172ef51cffb2a772e1575eac79b24d49fd77f0be351233e57ee6dcc7e2e29994873abd434d34ace83400c026e27e27888ea0bdd1bde5a3e55aa8b5f2feb57b8b0a96cd831906297c8169d04f15843a3249c50523cf56a4e19492ea16927dba8759b88a99e0d20820e51fc9b6a6863115cf05c5bc3f4c869eb5a87124df5db102d737f3899cfaa5fea4dd62dc4fedb1aaff67906adaf8968020efa5b10190f70e5f2c0f0457e4341bd449201d3a80aeb791254ec1c46ddcebc3896c6df702509ba62cd446d275806438eb4c03132b2e6bd01bd2f832d1d3c053c48c5a9db1c4a22b130c4c9e96a2bf4c2a8f7de0217a52d9aa5aeee5e6a49708237eab60b4019a51390c3ef10572a73d436875bb8d7d78543f96376e4bf3bcaabb92f89215e8d1093f3b287945708b5514bd7e62654d3bdf34b29009c64829a0cbf33c54d7ab0e81b81bdda93028b341ab1dff3d752dc4a1e5f9636a5c46e137ea35919d99e6571c5370c6e804bd2e2abf566f035d65cf8f97e3e8f2ecafa153bc6d8ec2831667a37fc96d1c2da40ba84d0fb041def32aadaef3f98cafa957f6552f79d28a36b8ba20a9452671de1be8af5d66714232507edb9ff657f3d7e5fa7320fc0359a5f99280d446283bc0000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 17","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e3952eb4ec03f9f07230efbf1151a4b08fd1d81a28a474747aa04d61faafe7628f41e439b50eb7666cf9ea1e1ceb5fd66787455fa6ea614a8eeb53007e4822193835160c6f8391a0bfe7a2f3ac57f8d0179996e9ab8c14d93b2f81af5413188a7f173a1a0653613f56320eec9052af32f22fd5bde8e31794150bb5bbdcb7ef3644a71e89dd3186351d654f9532aff0a2bccc0a838e61e3cc41a17d13292e81167bf60e5344f3a1f4e641e3d56d90fe117b9db44c6f5920c547b9ae44a14cc02e26d625a0d4ff5ad76a7ff2a7dc7f768f3668b630fa9aa351bded638ebc7d009644b3ed661e0cca77b21ea831926613c64dbf60cefc126ce83362f290114d2b0ec7567650780e9cf751ba4a367f39484709335344b1c15e0d7af1418460add35fe6befeba2032f96a028aa33ea7d4c0312c7534f041ec0d5ee39977c4a728c312a0c04bb38e417d2dfb2aeab7f2027f9f711002ca9316e8a09696a99b7986a554b03a55bb23129c4737bb0f9ab971c39543c5b46b9006c68f95571232e6c894d86389dbabe567c5135cb6789e542becfd2df15d56b3048bedd23262cb333b34b3dfc2424ff57316d5f8684493e397597877c9332728820e06b19aaf771e6bc605f29c4bf5acba899c60d5a62b88c31452a1db397cee8ead93fa42ad986cfd99cd3bd20eb3abe6acb29876a1224ef437c563c0c7b9f3e6d9842fe99e634f2082ae55ae3b1d61c4bbec9a8510523b35b6010bc8a107a37f91472d93a87ff389a9a9e23f127fca118ba11fff6f2712102b3b79ce2a6c6edea70b43e59cd92c231841101226d4bedb0d3b9d8754e3dd7d7149c24e18112bce13ae5295d8cf18830f3e43f62e817641a6ac9e71e866e6eada26d326198e8d0864329067e8ce30935216618c74ddc8c92db316a12acd5fabb0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381093c9c868a72e6545a12800b8c42cdbb344e18ef95da494a2e443c8c775946c5e0d11de95506b33019c5834611d093fda85980be3a7ad1e58b57c509d9fe0ff885b99b241ca8cf9bdd6e86ee6e9c123c3f55624d915e50c7e3a69b046542dad46a40b67bceb57b6ad86208be87072a2bca2614f8d45fd2e3252986d8f09ccf83649b95bd57f9141db3ba780ac89550a1b62b684a95b01410f0545d5ee17152b3870e9e415944b053d538204e170b15a03a058524574591bbed2084e01b1556d118e4d4411e08cdb5e22a86869002bd21b9114429340889f269e62084c472b655ba4802e744295e3908c45e29fd9b4a2e3a6be538438ea97ce7c85082de4ee9c2db3ae8551bee70c25d6bc59a50a4802c0dd46c4e1465cc5b9b4412116093973c593dfe93c654ce8d52c373edd8e52b5408f46205fc4dacd7582e483f7f5003668990a7829cdb39e72b6d86666d30fbe512aa628853cc688c4d49e8068590fd69f8bca49e95b8b2ce48c14e06b452d4c9125a1652322457a253df7079bc517700e5ec05e643f726527cad7642f9e25a670de67168b351094bd1cb4a92c7a97a4af9e41c1b0a7ea065227e2b11543a6166d995b028608d8aab09d8b449abf1eec62d52168bc3d54a6d18d6c6e4c8c4444c0282687dc32f49c6dccbfa820da145fda69c565366410ed6b7e96c747ed66a5a056f0ae07013a9ee1675a96d7a6a5a04adda38f8841fb578b1a7170b1d119012fa1b60636248ae6d2a066afebe6c17a237eced5dc85513a8d5a7a95dabb0b24daa47ee6e21bda17a7a460bcae0cdf7854a13792f9cde2ea27ae6412372495cf8a41de03d70cad168a88332696164c423d9b74095bcf2cc08518fb9f8c8a4490a8a8122908a4e0e12b5531ba18ec59c86cfda441b912f0a9a436b1a3c017219c8fdd60c89d5a68b0c4bfbb2edee56380ddc5aedefeb8da98e5e16d0027b63ab827826b0e9e2d61adc315b50280518a4f02524dbf0a4b08586ca137f665ed2eb3fddb2001c3556d5965921fc61b20d626a9b5a26aab2a866b27825b7ba45f60e96b8816fd228810dcb502f591b69dd93184dd0c91cc5205aae9db437d852c81e487047690792e303c2bb9a85b2829ae720c8f5263597167d64db2139c74c5948f8574a136b6bb0244007941e8a79b740ed17450af2b396324146a16a2e99471655049d14876958a6b8e52672440e675d0a9c7b6d42f56b8d79d7e1c7514c292e4a52db5084b6c4cb90e6b01cc60170da8ecc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000273021e9c06a2e4ef63d1a61958620c40016783879080d44311e04f2a446bcaee5a486d17ff0f356ba70ff1c2b55bf957a59202903ae349878cb822e04275e0afaabc0803bb6cde3741e0bf9fce0c5d5c814977474533dc63f9ed4f32ac3477a3ec9893ef55186728c85b03f4c2e61ca7733e1706766aeb8fea80e233e8761b57fd5a3cef700196674b34a3a55f68b3368b688fb1ddc976ff48ba6a98e2d66023f291a3c617a56ccbdb8732b8c34369ed11f4ccea8fc8f673ad9fa0fd8990bef70af44c617fdfa096695d0c94ea8e17554f4461dc776db2f416448b17680fe4d29b09e57603d8ebf55771af84d8d4b9097302901c25cb6d73932e67c323d12c8acb0e74cb89755f7eb3999d4eab5e1b775e6b5c29d9733697030a26f3b93b3f286db0f2dbda71e1f103878063e77919d8892eb6a34f821b603ed4a898a9f30d00feef20985fef1a7b7af70dd29c269e88687f005d551ef05eb0603fd38745aed4f5bf4c2fc09f0604c98ae3a89e46bbfe907b87a1672de547d651f035f392a8d4db5e7260f43953028e312b95b9f25fff2c0c579218390411d13d9a25f22de4c7aa05fd11781db08977160d48e02372c7d826f5cac37d1a9b4230be99a2d13cc2e9b2b17f0a1044eb9e0a2fba376d35cdd2bc05f57dce4bbc3bf07a09bcde369929e6250efdc61689466b040aea376b09453a2c16813bbb685b54a225c49008ba6811e8bb5b3627f8c281244fdf5533216d126ed0e64fdabec533424bff77fe722cc438ca7587c19d965f0bf085d8692c27c5c84a9dee53256d978948d89abdf9842e0b765be6a507d8630cbc5ca7fa0fbca1cecc78d2e536aa7b2b902c4379777ac0920d69c57cc4e6032252bde99e1a555e80d400000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 18","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f3947542a164b1f13aa9c31864f6f58da0e3049167c445de882811ff4fc2348a200bc1474ea8c1d61c0d6ed109a01c0c83a3956b6d0b426051d31846370482673308e2cf1a2a475d13f754f2263c671a4d3359ca29d93472e2d49ab852e5253f5f764a0c51ad923f1a5f46b1c9883c0a408e33f17ec2dd7660ebd847f5ec56d763ffb48a26d854588132f87c2a2341df3b0b2109845d7070249363cae3ca192624fa1a175f7476da9dedb10e66960c560a773b4490ada76bb28742e78aafe564300ef43a55cf2c3072099ffc45682eee01f5f0e1f1ce4116c72d50973dab7d99cde54d4140fa3bbd29fc88703df11d223916b95b908d9ab78c70ac1f768e0c89f3ff19b6b3e2dbf5aacdb7d53eefa606411b9189f4167947804db84e76733acdb5506f976d21ce55bebadafe4f88b6a258f8968237b06ad004c7b2e9275379d4b2f930a1e17e3b88cad8cc0cde6a7f0c3f51162d0e6f31050f6c846d1bf841d9647ac5c7ba100dd7e34ef1f99abb6f99c1a759f711ac43fdced3a00fdcdc95ecabd52703c33635c217e634748e7e64dba87f7958b9c7f47c1ee779ed6d152d713e52379fe850f1145d708f7d69f37de501744836b8a2095c4a9b2e4d66cebe6453dc10821389b28eb4f95fbe612edd47513807173086282a9b4bfa65462308b16cd6fc2f1101b6ed4a10c58d42695f539d3c8275dec967a4fbd77107bfd636906b976202843c5f99fe732ba1c427a894d714b9c5a56648546211ddc291ee0d57ca52f21806f347a1f67d52a571cfcf1226469936b4eb6e7b876ab1c16ec8f2fdd364d81d52fb2d4ecebd0ec5707d3b32e658eb55691965cdcd8850dc9799ad6d2b3048545ed68252e24fcab353dbb750f419d79e67daa4ff22c6a848b6652b8a5aaca7a1ae53b5bc063f92572bdc180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810981e2d7709526d89bcddf707282e486092244ce95246cf446964b115d7a0819e828d98886001e98ffe0b646f518851dda8a5ef5ed498b599b3fc83c780c8f34696d2f0215ae0f751dd808b8c2852b9cbe976887bb6d442e64f7e6186612123261e3ad0d0150e9e4245982d9b0553bc8c68d38dbf3789b3a08822bd009d6e46a4db0d2bd24b6584c551748d8aba19052474591b90289db6760cf9f050d71851a92923b60bdf9d91cf98bc1623928577a8a990881a4474b285a26b2bd6a5a81391557a69ce2bbc4fb7658cdc84551a6c24764ec076017a4549dd789ad3a633498b79abc56a4502680731290f774830ebaf297b2e22e3272aa1953e5014bb88d78c38d2fe140eeb1c47765d580f1d89b28eb6c9ad5e66b7069ac3299dd967d60368fbef603d9053a6b203244ae0e9f2199e74a58d0854f2048f8694c1f5a6cb39a5b67760ef5dcdb3ad6260748cd54d71dd45a30d9dac7411f11a46f633f4e8319faa9070ae68901e11b2aca28c35c4e5640ce2c31b27a2ac7272c092a2a54e4d7645f3e5d1873f01a97549c0fd1f2aae11c008490dde9c2a6b13ab2ad4c5e23ddb507d4e9063122395406cfb9b71a11b113e236517634f9c25c65a06462e559dc04a88475230fd5999f54f8f924812895caa5c7f50cf603e164c609ad1a9e118f1b5bc7bf33e95c4808dcbd99de1ca8586907336699081565676f5c9924752e08274482723d06ceab0dfb3b996d086838af402588799f7191d5614013bb5613d663e2ebb2329294c846d07b78e2832d4889a08c9a63bb2023b4f572f0eba79c6f266236c3c7e647b81885e74e547990f47bae2845628aebaaf8d76e32e1d4b1c8e907ba4d8da1f643819146681ac394c532e819ea5f13f3085d859993cbc473c9ba16108db600a24176061f217e0174c0f89f131628b0b8db287a600c870a555d8aa91adf33f9e3031c19e2a95f2ab77a2a79613ddfe32342f64a9fdc935382c8523b9df854a67b572ccb8e26607e842545b816e060f78e97310e5a4409ee942302fedb17b8006cb01e72f33aa3925db28f1000220ab53d892bea6d4f71d8a5abf7d80837629f8a6f4204af362184a52c52a2787a1488a7ba510aa6cb56024612a84553ad9570b34517375da02c1e5c14d8ead2d9aa29d2418cc73b5ea95c146b80661bfdd329268bf9a042de33a6e37d7c4c8ed5d998268c601c2b960f22a9542e898b14198291d3136a4a5631fd34d4bbc4fb14a51b560de19ca25e74b952ef960000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002947bedafebabbbfb863ce496475f54e69a905afa45899c3d7c16cfc73e31597d2404ae7014612e4cbfa238efaf5b396b0b7435ada5de817e013188c280423c68924e1fa2a33ca56e6b85b7cca7f00d3a6151f0629c1b92a13573320e0025863bba7f3eeb987ee1b1a6230b10765dfc1feea498ae4b83521188e7503b506259103cefb370e3651b06dd4f08013ff3ab9e2430626b0bd584232948462d85c0f82da07b96fc65f62a43cd2f132d1a1d691c085980dad8796cce2fa0b268395eac3da2cc400f30f75be87316216980ce213b48651ddb9e294f8cdb2ca05d3f2a507e4a03e2849aa8062918afb5bce9e4c3abf2ffd4751dddcf08ab09e36a29b830f3bac6feebea084575472e6f4b239af89965a72954769a83e391de467934237b07d8884a6b14cad034fbf9bd7531d50d742e234e227e1a2daf77a2ffacc579525134b15186d81ae6e5538871024bd2897475d6ee5b11bc51edbb928d98475073785a75b331bf3d2297165ae6cf95c3a05f06df747498462054f58a5ac736f96014b1a8cdb319d030d06dad9cab2b913f35fc392e1fc4b027cdbe775d64b04f1076a7c8f44c360745f98e87b84c18ab76f84f373f635af4c8a87df08dd4507899bad892ff8cc1ee534d3277b5b82095628b84a7d5582149cf46c50aa963b56b4b91966b106b4b2eaa45d83a10993e8f933370ab29c6606b7ccfc41b21c6b99f2b9ac643e24300b350fa199ec10e64e4af19181f78e8c43b2fa796241dc42cc8992bdfcdc39e7bc41be68cdce4fbc47c996db42e8249eedc146c216b514430c705fc939b9eef677ad87f9cee3398551fa0daf774302324a410f4a4f4fc035cfbe960b38c390441e92d9e5624a8745976bc88fa538e398712361b77ad4ca5ff038d9f6ce157eb8a6137420d4e57018275dceebc4e480a5d000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 19","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039827d8071976add2d5b97da1ff39bbf92922198bfb2b0132277a92cd4a1fb04c581322ac40d803f9dd3dc7a4cb3832976ea9b96ad56c24230700193f3a2b985737cb970cd218519fd3296a360f1a52712c4f7b2fda90cc22df3eee9d242b91e68d34bbb3fdfa6cf32aebe419775765366c2888ee88d95533aeb6dcf3a6bab78a0f1194ba238c88bafb89fb714f0db5df3f10e353160a1f955b50a99c4343255fd3ee07f9b8737e1f9ef37a59191e5979712645f6e4fbf77e2a3697dea0271a61a87f9a6571972824c19d91e6de8d2b1e250bb65e5530bf6aa7313c54e293157b76f687ce3ccf35fc9369cee33883504d61ab8f8fae863f5939fb06eeffb70c6f16fcf6ac0d67da71f29d35fe5b22c3acafe8ffbf940cd54163c8c2649eb2cca35f06d5d257a42cc1387556558c5cda5fb69a877a98394f457ae0c6d1ad7e68356bcac8dc1dc67c7bfff7f6ed5be5629976757ad0b67da92706099ead1d8e97ab1693c0b5d8032145dfe6e9acbb111de7eb9af86445325eb2df0127fc55aaa778dc7555a8d2fa36eac66a1979a3d4f36979798bb4c765099e54d2a811ef946f2278b7b5468ae9735d2db6b459d29283bc2958039c4e6216f5498be44dcc432c54bcca325a60b3a25c469d5e290958743d0acef9579aaa59eb2c8203af8b991d4a8c9247a3eb7e934e84b9df7891f8fe3430f4a99b425d042e72a9bddfc2e52e8729503bc28734be651dd2126b3576e31999c5ea55acba1fe392f40a83ead26598962146c4a6ee5605abd151b54b8cbd6fbe599da4a896acaa2968366de611324092d9ab7682b368d67aa13c5a140ebc437acb208d170bce8ee7492f9afd02dc147caa74c8e89345cc64f2971a3a118af29adcf3433b907f14a591299ae0d59d24c88d98e58221e8f4c111260d9eb7ff600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109453a03fb02ec072875e542075b71863cfc95ad04719d6ddcd9b7c830b48485068515d40b41b191e2a613527ce6a5c0e6822aee7d925a1f5862dab5634b89fa74fd1eb582c7d1903d1bc00d8100393a18d33ac6c23acc60679d5743abee6c38ed629b0c75d3407fc6e9741a6ee87c924c2109863772ede806a15d60ff5d923181785befeadfbb1c2a1687db7272dad1b594456ba55637b1e095d4358c04901d4c9aa8a24b1251eafb0384c51ba4c30708fab323eddad026ad5ad668c332b6dedca32fd7573e8654925fdc8851ceb6976765340fa0d5b044285a4618d570d189cc1ac573497359db737dafd5ee447b8a9074e94ddaf016cc28a7dbd4faa0196cb76f08f743b0848b6588475da6b89861590a1bc2b449144e05443eb0da5a86ae587556f2cd0a5a3f3839d2718de39fd602125b69e241293bc9505668840e3c9372a53c4416b9559bd53e17a69e36968aec2a584ae5ee112739c0741a1b5d5a6cb47e67ab683e82dd6319bda37ab7baa60398a0bc5389cc49f41dd29b01e87812cd637f6ab34508e03eb8a20bea4d9b58a59801528da52871a165f726ad245c0e7a99e04e63696104db1859cb3a781dd58def272cb2c4da5cdc1514c85bf816024d1abeed462891d32b71ca6b5caaa5318c17b3e62cf84bdd0d17249a52acc8d4a84d451a72809ad62bc52703f0c4cb5667e67de898e6ae5028786955f9f4571f159e0d24ee235f9cd21622ed87c10c0af080278c575ca9d1d49401ad7b403fd1d264da8e64bf3b4cc4cb5ccec834c3e2e81db80867d1e6acb3b0521a160a7da17a62f54c8d152e153b35bd4c515d7af6f21ae02f955d4998fd24e2a755070a04a6321656cd3bd267cfa5049cd8e5c3ad84691b606255691c8d90f13c2ffa7a084cca39483967a0631307c4bf76848d86619151705c5452f549b43770eb744dc9055de40f61ad11f9730caed38bd6fe4e40391427178b53cdca51768541845519b854eef804ae30d31dab96add4ed2aaf2393a30efc8532877c75bd72b21c481d8ea2a70609949d02a511756143dd2958bbf0795b99539ed21b86964d2ba0d350c527f0a8f9c158c5196d513cb6b3619cad8ae21c182268cd7e1ab1e020619b0e6500f15ca23d19d1dd1b045fc939e908a9096e464ee41f4806eed53418b094a25a3f55fd8b2b4c288b3709585be693da5825312b662775058ef8daaaac14187d80ea3642b465d9e2c0e5a9c3aa7ee74ad900418e8a9062e815d78b4d1975196a5b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002b5a86ee95388df139f9c5a84108d1e63f7a7842909b818e9a0425c257649abf125386fb5286031e7e6d0eeb85c452e254da39bbda51f0d2167ec0a51992753ddfa76874aa80804e705cf8bbadf3b82b6d7fba3d1cad130abcc0b44d6d893356f3e94bf8e82ac532ef8c5e5f4200207bcf6b754f14e57a889ffb753f516ef8de2a647fad8e449264f0bbb4cf48bd01501736da49509c3426a3d4108b98e6a4aa6c4430e8ee76540051fbd1dfbfc01750e26547f8718ef7d897a0342bb000fb99aa63b781c9a4b831da798c014e58725e03d2f8b1a029c3337f4099239244aa320965b2cb5075052d901b6077a18c1ecfa5f272850a475b5f6bbc83f3c09a27072f80743b23ec6a9870913ee2805b4d296b2f81a9d733e5c8d5c0b477e51f9328af3af8abed960408afecd27fbdd08fef50f4b07959646e0a02104a69674294a79de0b25b65f4dbfa797e5fa56d66e8bc07d5e2e7c7d2e845699acea3bfac60b2c0b988cbab949a5b598d8e2f1aec66196e115ad7f237a1c7fcfb95a1bbd6939a250e7bb0f4a02c23cb1bd81090cb770e3a70cb081d121bd0bd5ed1dc06d61282b98bf2dd7b13d2c6cf833891c67951d7d0f429ebde3f1da943adb8ad285e6f13f798d6cd9a0a06bcd6125ebaa48f8f3bd5100a122f617817e3c42ebc3c3b154258fa26b9fd886ebfad42dedc6a2c4f9986bad88a2a79d7ee603554e9cfc5fe33a3a171cf7ba94fd43228019b2f6ff96a8abbc58d2098ad95a95442f6858eb69e131d7bcadad81b9bb69d7682a978279b631e22927decffbefbe8fb2e51d46a3fca66225d30451cef9953ef94f30b99f2b26ea75b84935ea4fb257dbe5734454b8087b3a4e115c6d31e72709303e9f0bb8c86fc6b11b93b53f9781bb92851a5cb5dc00d0b4e15683dbe4edbe986966fe1f711f24de9a0e1beaea8e835c70cddc589773d31191b74af780eb69867829abed6d3ffa94d5770000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 20","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028c393e5f8cf00dff51cd4f6deb3b7a65d7b1a3f3b59c9f3223168918f20b466011d71fa59d4e41514e2508cf50fa7ad579176974732dbb778a1c28ae5a472a39c71dc73b889fb289c9adb4592855972841c8e2b19d9c68e95f5f63559a716694096bddafa316fe6adac1b310b43f6986b1654fbd71ba420dd22c93dcac09cc0d21e0a4be9c3c23f6fffdf139564bbb2422cfa306c39bdf14270f8e77f1b7163cd9d1994fae59ee2d13ab3f7ff7b1262574e722af092a37bc0d66236e33674f80739958da090bc4b50269c0d16574d1254e5b9eb0e7a68795f6d5fba4462b1705404d63b882aa3c360990ca6d641478ffb250cd4b0c6c8c90638af31b5a5eb8f30a2f0fc9117b1d3b67f24e96129889d9216b074e933cd94911b22b8e4eb05414c2b7abe05e7ce4446fd11ea32ec4bd93ada657e4e241df58cdca11862ab334a9aca9fc1c4ffe2f7a8b45a0ee11088c9a1ec71f3900b36a8c2b90bbdb94d408aee9b1115f0eca50697431948d50d7c7f4d0c4ffe4b841582605b450a518595a51d6b2c860d3a5c7ded411ea46c8d2e8257a5c429accb7d19c6ed6295ed2c6c547b94c4ff1ae027e94c09bef55e397919c2c6c3f9e9787e6b1dd0bfe45624d537ba77ee5ede835ba3dc53d3ab548bfd45e6234ce181607b0f6cd89324e99ce20b0a2bd2560b2ef62f12ef9c15c23fdb9e440087ec7f58d8ca4faa989349e6a18db56fa47313309aef394c377f8b93733e2c7f7e80c3fecd8c562aeb654e3fa6a94f76534c21cab53bfae52d21f02a19bc0e8b87bb81ee203936ba0700793697fbcbf17940ff321cfc7606f23efd02e1e4573329041aff8f75630cce51a46918ae86fa5ed5d45acfa3d993c108620c44d8c7272844519c96e36ac14af1c956ad8b350b58c1e5a1a459247d3e5cf800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109805ddd41cbc874a784e9a38866287d09abe5a40014a8b184dbd8226269b8efb97c80be5efed2d18d2aeb5e848b0893d8c9abb6f6d4d994248db5d4d49386a3584c405a1020c9ab61a5e549241480c66f660bed4b700d424349c89d860da467e05cbe6a264a2756cd1932ad6ed812ea760ac980d75ed6590f1d8656291d7f1739be0538d7fb897690b0d0d28f09c4e80623a831519c8529eb229d1e51c5e7b74c8b24f68ac909e7152f394ff3a8d0c80421fad6d8e57c240d44339f2c695b118c3121a2272c268280e289a80ec43d561457b78b46df0582e41862f46c23ab02c737987348e44a8e99d50a31f05983892df3a7eb882714a1ff34d7e5ae62c291d070cb9b45bdba9480548c244284e357688319c69392b143b86200e7b6fcc0e6183da8d8b3df1e1c9000f49d964f6431b170f920170c9673c3468f3e03a88e5a64a9c46bf5c3e26c8e4b3eca9d8969c9a916feee001c95c21714bc72efcf978bed6607894403a32d571a6802b45a9e08b6201c876aca97714fdce56c02cfb37a4e2931de72a84a9165480486a966e9b27626dd81d68ece851e8b16458a8f43d0e99b3c2956966595376a210a6255e7a2831f66887a723a6dae749ec4a38b165d668811c082345b74093e1bd52aa91759781df4d223f6984ee572731ea1a1b6e138c025b709c2465aee176216d4a722e8934d16a973cb19cc1a83a994d070649c3a21a48a54d3985b6c3f2abe453565c5a8297dece0228d272412637880163e930f46942a1db5c09006e2836a1f90428ed0937ce011e4406e722ed8a1c55d169c54a3a3119adf511482f92c80001615bbcb200d6835cddaebfa1e7940886420c4202019b1adab78653188665253e362d0154822941d83cc66d8381187022a4e18b77b3ed0d05d0406c8bc2ec3b8d43c9895ad908dbebc290517e379c45f04bcd24e874a4b4168c73a2c66c2d616cb7ba184de461adf282e3ca3268c11dd993c8423fd0aa94acea536fc14dc243a24c8ff0dadb53526ebe34a157a51b455cdd4249a365fd8f156ca67f5c534ec06055709224a9b19a18edd395271c55faa96e9b82c41041d160985624f5d67ad9b0a18a492753a33335409671688f3da58c8c3aff9008a360826064617e2769ba3657ef2fb6d8b6fbe6e3ee1cfef591e6d2aeb2e9f3f2822f1d5dc26c6ac79cd0546a0760fa269557be9cc529d11e25e208d09da469a2f8b090f71fdf8f209fd19a2c6d39b5576543e5f2b2e6a3897e2c012d651a10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002d6f5abe373ce1f6fb14f2014f5bc0071b17ab2c84e8845fcbf4b15c79fbf2e5e06cffe6cad9a283014a975f81c9216b261cbc79edcd58d0e20c586d7c641e0ee97221befe54dbcc56a594df103ec24b52ddbb6052d1644972640f39deb98997fee7a252a65070798b7e46707fa440375b1ba705b3ecc7eac56d9c45297e585299c7d747b430f0d01e82081c70b4a87846f90267d5163181ded63e089a00afd33b0e2b3ace91182d8cc899223ce65a5d84b86bb3e8b34b13949bc800f2145468ba5411eacd6a6c331c340d4442d28efa0da959a2797c7181bd4bbe6e6dffd134cef373ecb0ec08590f06be0ce292d3718e2c0efc7cb40f1db26f5f38fdc82a72f81afbbc16591ee02dc818d63cae69ff0a28f942f7e07f6b0a741f3f0ebe3d0ea5859024aa408462d3d268c23f95d717c0a685a4ca73ad90ee923db57cd6cdd828b7ab0d4afa6a9ad7e32d407a44d7515c0a6af52a66ad72119ba1daec6514de3f8b462ec473072226aad61135b0f5ec646ba9a127c9894e51fdd1b2d38011a2a6d7497a55283133695d0af9b3ff7c5a8fd667231f9e511e3b8c4c3adc44d02de08c47b2382de67b32826754c6be5231ce0fc657341e20247cc6ce574f3d1a9376ac8237b49e5030e877a4e33cde25d838ead659eb1678706c759707fc66ce84cc968a8334c18f1632348824a6985a0331a93b59497b70c1a03a6848f18f5992972bc79f07f4222d2612797f495463836ae6cd3858d5b9bdf744a1cf361b5d454d41ac899a4fa61081b937cbabbf0ffec1b31c162224ea36ca2cd7fce54ec1a504932acc5bd0b17a156da7488f7017e4916a687fde7fcebb2901813b07964084ab0447a94dac3a0d3fda05b9f497cc1555a8c74838e29cb8ce89d304debe419d26ba7f3dc6e9526bd895495a5ff1d7ec83f70d045e306e7c2487a52cd7553f062d31888ef7fd27f667fcffa984afe0b9a4c4e85ca943812cdc157c5486b0b5ea6da05e4bb8697113190321a976d1806da129101e60a28b700000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 21","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039bc4207624a4d8110b9fcb7abe376d7e28aec5ea016f3e78bd146a337fe43f1fca1254b4d80de52d4fbd55966f8c33cb5d22affec72fbab4d56c7c230b068f4f457e5ebc7ea73398b734a7b3aeb1c90cef74ede174fac5c8a9c2fe928188745d1dbd73fedbe411764a7db72031479190317b94d184236e533a69be092eda15ec79e418a399b969971dabe5ab9cd0d74259595afc8bad15861ece82b1636c88af392832db3a7cc88e2465969db1635938464ec58189b9272f308cbe14fe2d239cc1f059e54d1f4398d43b48b94b521ace8c9238d1016c4cd1270298b43038a65a33c2ac6e2bc723a38b6eb05af57e4909aea70eea1e62497897d9f3edf2553f85956b2db520758dd2d7b28829a8e6ebd29568e54c56972ca6bb3b5c4ea2667f7c69b78f5cf9d7281de64c919d49bdfab39869ca94d21b4bf5e7706e950a8a91f2309db56d34e235bf0472c64e7cd9b6064b41f5c6a496feb363f7cce44a44bda7258d4d7481bb39f9b2e98168f6a2319f90e6a8aa7c9d729f9fd58e95b0d2e7780fb15a2dad2bfedfb19b0fbfaea9e748140f6c133659befb6401df677bb83d333f8ae6e82a70e26d50544e4a475973ea8cfd56cb23d1fd6b96babb1aab39cb1db70bf09fef36dae8c4e7e591499b45220ccb2fbbb747f512be314bf283ebb778252e23a664546c329b8d535958bf7be7b18a99fc5a57c267e28946e6eafc2ebd059fe37bc35bda020e69fef28f1c86b7399076cebfb976b89da44369eab3e559271dba93d5fa15c708c4368c09f91b1da3e4872a9c981eed5386162dc62f9c9f7c8c57de2eb4db13f2d58a4e8c86f179c99ae22fcca2160ca12c832cf8e58bcc346a375726522ab6edb40c892691157d506fd9b4459e9837129a4974cee84670f45873f6f2faf2e0bc336278da7c880000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381099ebe7ef99dd75826b4e814e411fa8c8975952885f7817df068a40a08b3411c715a89637cad2936ab868588c4c7fbeac85c58c52374ca984908e52248db94504faddcb2024898960a8144d36df88215efd3c3996254512fab51cea17ac921432ca103be81e0d750065986b12744174124a79e73d7ebec8441340a12ffaaf3b1081f9a910b837912b8e848e9ef6e4db2d6462335b83a55143b515e2f7c5331b2e75a2afc7731d892012d52e99864cc7a9508b2741a637fb5cc3dc4a252e13fea97b5ade4cd3826ab5be3e4330705db85066e2ea4f54d971d0e7488209689758aff78810af5506fe7475ee5776cd7d50afe9d5b10833a4108ac91bbcc89ab7521f7ca15ec9630aaa613dc9d134007487d9163b17e277b0c2a6251c560b44eef2ebe7509903aad11991e31686e18b1673665901206ff838449e6386fe29d50d8f67e44b8a9ecbed8e25454a91d668173e04eb5a206d65e2fe4b216de507ea06fa7fd305bc24dd90c114b15cc6b639168e2b7422b02bcc56a046555f9abbe4390e12ac2543d6294a6190461c5d7d40d1cbe11b460b488450db04113caac6ef80bd9a41a0edc42331ca045a946bb46de4d19cc1a53b36c10c2dd95bd1df12f3876c742575c27a6108dd41109cb454f6b60b028f1c2a443ff24b0bb91ea591d2781f3cab7aeb5454e7db463ac7a1a1efc85bce87a81eecb9abb0ecd7edcc768a8021d5a5d7e33d0696693761f247994911ae16632466f88a9dea4c25da6a4a7886a79934cc15bfc5516ec1067326af8b8086e78a35d982afd935c28a19128f58459464e29f4ea8cb6b0a21184b353c723f16517a64d049c78db8b2d57cc68a14e6312e690b31ae6b1a82511437c520a021792894a23604de2ef8ee13d3424418b6b80ebd521a2ba3a4077f026655c7fe435b6a8080b1850b9b7eba4371400812985675587f8661838ed7b6d728b052b9c4f6e71f64a8e83c94e82f54b751546a9663702cc538b509ad8146b55e4be50908a961f3d041aaaf32d04cc38f29f92d284cf44901675d749dc5418af11f74241abbec827baeb48238965a5964f31019693f826047f2886da03cb62150cc03df3f6855c8f054a22de8f118ef45a80a720024fc06e8a3600a05f581fd1ca11bc70f12910436897b11a55e51b2f1b14cc207473402e89ac7c8ac99bff0db0414b3c97604bd903a505577503d541cb22afe09f755e0a9c5b2247c5a274ad4e44ad8097b7e08a290cf9d22b54d17abd8c8061a74bfc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002f74c4697a7d8195bc7d4b8f2fcf3a7e9419e8fc9ac6bafc5d658260511c697286bfe44e2ce98c21c98be42e5af0fceef8aa54c5770af287a81c7481fe3391a6111ae6243d545b2a651599b45931d7640579f8659a8bd6f77260f235f71476ed64714fddb70c549cbe089322130f7b0a21f530508970d55cba55baeacbedf684c7979078102ecffc2c3f182f710280cabc2decd3d3b5d3ce908cb2307b00fcc0c5412a12aecd041b5f70cc0149390312b9c81592bb0e2ece83d4495944e29aa798de67fd69e2bd0695dc573f78d8bb48e6b8679e1c50d1e6e58e218b77ee51597eb43ecf7301d86f457353d60e98cedc95b4a76844e889bf7e9d03503757569e40d55ab43d63293eddbb579fe981ffd4dab056f85006ffb5e759b9c16f5f6b235d7dd78458a73ef37118edf599aa504e9db9ab5dbc90b8e478f3dc1f35a7c4604a383bbbb410cfb2c5f746f83ef94bdb2f244d421818c26827d5b7d665b8a802181eb7a9ce95b6633e24d914feca7e969f64038acc3009b15168426edb67af2ccf4e859f5c616891d355f7910acfa599c396bbb2d2782cbf1432e6259faa77730b6b86fe0d67730152cd2ae0f9b0314048ccd25772c01fc9773ebf06618a8ce1e940f48663427775990cdc41c4dd3e9ac6eda1ea50e04f1d329e64c8532a7ae32238c131753d60a25810a5ffbeaa9007a6984ef69eed92b777e079ce0ff48c2aee9c18d1db9f49b5419ec6c0e2212ddd2e2fdeaf0fe9f2b84d9c50dde86a70fc28bbf8918a973cc67a36e97ce3027d73891e7aeb24baf4b12a9dc8aab5d6afa380bfac3703d2d32f1e40fbb532fd6d7d710dc0741dfc7eabfe55ba5c311a00e3be55c2ee74155e3a06685071a962d7532ac76d59fc187eff01f8d339f74323732168fa5d14f4b2a72c9164a04a6ef14bf5deb1833e4baa19a55ae590f542d4448e0eaff0e0afd2fb30fd671631b9325f4a0bac9a43dcd2840185a2f601117a625b0dad5503578537be2a535d2f556f371536bcf68c0e01c96301f08e1567dbf9d8504096a8fd89c086db695da191099fd1e8ea94035276d1d000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 22","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039f882dbf595cc444f0c636a526cbbe257530416afcc0c9943e964cc509c823bbdf4052f5a60aa07b94546d98eda4778f3360699fd372d8af0f3b268ae2247122928c74fdb1034c726d55dbd45d05ffd327ec32f4befbb050fcb25f1bbd6a880675fb787e90f4136a50ee370e1e1cc943b08877426a86a58e9a10a714923bbb5c6c881b1f8754569807a300e97bd68b3cc15632f4bcb333a8ababe6661589208a0c3d07708ef3670fe198a7a62496325ac9aa44fca604b10f8c25b17cd760d2daa0cc56273f7bace2350abc976d942578e291e0d8fed2e411b1ced6de7418e5ae7aa233c0b8eab476b963f7b146283134249812d3d555ee77130b16824f1e47568e37c27f0c25c9ce8f558543df64df4d1060dd6cb252aee1535fa48a759cac9e54996b9ba1cb9c76df5481575d91168b25021bbf7c57bb790ec2f0d5c57247a72959b2e85544a53e23d6e667670eff25c5fb28a137aa33046b0b83e85374766a026422f122778b5b1c39a5ba07a55658f1f940af67d5aeba5baa57d88a6a59b2ab0d064bd74aa6d851429e3aff8ed6139e80f6158f35f10869a590c4d2445952d7818468d126ebc97b68730550c6e2af1a2684e597088a0bb8decd88aafb8e4de7aa258127651003f7f8261e64beec53797074bfe1aaa3bb98260e4763b0501c175241c5cba5d5065af59f67e9fce94b51346e936d5e585c5694d28bd6dcbdddee2274437d31444c4650375ed9c9b3e3f57a37a67edd2188c691886be8febefc5b08ce7766b8824dc49ee452e993ad33c8322bbf673758fc6dcd6cb3c3a5b039d1dc262b334d628bd54b227c5dc409fa7321eb8758db792971d90e459432bf1c02bd4d58c86a9b175515330574c54c713dadb3a35ad92c903beadd55a5e6a30ac23a8665f81e5410a8cb1c1bb3a300400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a9b5f0093eed754c40d5f7bb6b815d454a6ae292cf1c65a3a9506a2596d845717a489d41fdf4e229ad1647062ca385ec0c076d61bbd518429a5432f5ac994398f55aa1e550f5b468675320e6c3a54436cb5bc5c1180892ea8c1006b78d8339649f0121011b31884fa4869aafa51cd1da6d2a393988c5022b144f84d7c07290993b1a181e128d100380f3e6c56fd8f85006a5d72584c502fbc8f71a8903d2dee4fc3026caa0972c711c8226458b1c4a0cba4b16d1d13894718330a4680c42cc5f253aa2f25d58805b9cce0536a0abe98cdd2429ae8a0a1c0ef08822cd72740ab07a6621a5bc6e22606eafe3dccf3e853051900bda1eb3ad2f55782a8420d13a5401ecda6f4a0eea50a9979f16bfa57f0b0142e55d352585904ab0c511bed7e37255c9000e19498d5cef9182519c4e51847824572b9acdd558658df02dfa7677e72a635fa5ad60294fa872e9b9bbd7a67d64c580459d6cbda3d4df5a1fdb0e8ab89789b300ce25261a374d1a9b012a78ba26c1553e9ab7ea4fadbc75a4946936a58f785d4c34d808b821b1d056ce1a5a5a920345d068f795e975d2f79a7d9595b21360042148d60dd65b2e447cce4cc29e57448adab7973486a8b6acd0639cd77933c2c1545e0da4a34e06172b666f7879996a039c4865f1abb72623b444a9f9b3cf03cc160c379686d7ef8cb87b2017276e04a59475df821448f915f2e65b219162eefa6b188482f52c89cfecb1b51a0be44e6905a2245194fe0efc69962903621477be0223d25ddf883325b7aa0212ae7bf5f0928ed1aab98031b26ca92aa1e45482ee229b55515285bc955765e8ffa767c60e9e79dad386c29f205626641c09165a6e33552c15944e7d92fa9a289e5a02a346634b06a1707b866147db077191890a671729a1c16b8656e2557174e8729cc44a1c5a70356b3898c955d8a1a7359d8801184c556b857840338e830184e59153958d3254e046608f87a90970b4c3222c24b6e999461388a15d9ef64487639d26489532bb1d736d34ba3bd42c41a5dc2686cb15169d791d44ed81448e78f2569e10f2526e65bb21a2b9b77a2d30e28bde18d8ea84f36235338ee381806dc588f960eb57d2336fe9b00518c44943ec2769339d2b678ebc6b9b6a3c91b50981d7451604f2b7674484a16086dbb37fe17d974a15c44bc2cf693dbeaaf09a0191351fc28c5ea6060959245f45b64f725cc8784f5c942a3373dec77502996aa904e5af619e7e226c0e9fbabc42682fdb0600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000031872713ea55f1e5ccd5787f172657c6f6c74081de2d70816e8531497965df02dac04d91c4d09dcf8904cb152e2138f829386f4351015da253a5b5eb92d96e537dae3ce809443ea90332d9c754eb11f4de586a83b5dee7b1b9bd547ee7107530249b14279baa04683d74b69d7bfc8bbcd447fe7706593c01188fe6ad8d0e2572d49f83e93986b380d4169bdd94e3311941dd2b041dfabc5aea1297c65bb5c8352c99ff838d46b93b3e5f79e3cc5be5408fe5e59a10d488dd65a997b086fdd96cefb0247b2baf7b490317e34330a879d04e374c92ada33ee243d84da015fddec243b00bd7488aefe373e8ab1890273a7a2285988e9daf9c4e7c5a17f54ad6195ede2c79657e1bcced0641e20f7ee26eaf53dd8c82827f2d2783d44fb030c95791f41653e628062267a5cf534df00116c1ed1de9f360b97555c65cdd80724104fb1bd4da5785b5d9c24438557e48aee58d57a03e06d553b05b67e1c8d10085c2f153647f174f7922fb8d2210454f7014bddbc627756eb7cdef99b6e3a2779f82088e3f2da14c2dcb5b185aeb5d6acbfad43e286aae8f84a58e8df6abc64e4a8efd69fea18dbfa6808f25fd418de8ba923500b74e34dda3ca6ad8dc208102dc4a876d8b8cd2926aea4b3ae11a546f6235abea152dbdf43e0bcdfcdc83299207f294a707c8b4d1f56aa64a205c718aca69b862afe7489f11b324e7af6be68380d2ca6e0af0e2e20f890f2cf98907a9d43135c03e85e86c9ee417140efee9054b46c110a84f1841ae3cfafe5b4a95d6b2b606d8d0a70baea85c9412bc2d54146e9f866800e8e8615a0d64d1d595677e8c88699e3ca6097d47e9fe64050fb55033fad4d5f226da8eb5ddf99369acc7552927ed3ac7368b9efea2443926df26d1c172858fd8a5d4e1d7d39e7f7df047385d39131184087cdc45b299bd1f7048e918223da3f960608e853ee49ea667465dbbd889cbda20ffbb540c9ebba5c2cd16a22a57b561e01331d6ea6bdadbd6a5d2bd1441ef4e1d9dd11cc62a0fa5bbffcbed0d27b6acaf0889eaa5863dd9bb35920707b71a0805630d1769fea320516e71cb2b125ac274f16f7a6876f4b922c7c006f38ae1f7183ca768715d2af0000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 23","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029139b0f6ae60978dc6f9af5e36443b544920c5729e68c4935b233adbdfae279752520c5a941b4a5a53788b429d746f12a9e06b99961cdaecca3d7a0b0ec937788c0840ba1685c9a63cbad9f4d4b167f2027d202c14e85c05b34567f126521969a2b4160ebf75036e4acab3c7c3841ba9317351f8aade47bfdda8364cfbd9ba10aebbc89947f4eb666922711d8c2a12f4934f668cd5befc1dbefcdab5ae06fad774829f6bab4b24b840e76a11cea8f8cc4b08ee9f18c8aff692efa3f4e0a35bedfddb7ee275ec4ab79ed54fb0cb22ce9e510fd631c4ef938a330241525658fc7f8eb91f360792653582b8ef1fa15183a498d7b325c5f953c9596df7c94df266d9172a545910b5a7d58e593f20059f5d1b52952732079b4b22d228231b342730b707368b2eeba43f2d72a8443fb1a4c51d38cb38e1265857bf87c33a2d910cc519575c84ebb1f9855e2908a0c297644141e3dedb140d5f474d1486310943b893368cfcb43086977fc2263316e67dd94d5509e3ba8bd134bae3ebac6cd0d4f9ba5172f14d5520b5a45c16b3f9348bb52ca1145a2a9fe9a3229ae31b8b4439b692f0df43ac91f299cba5699244f13a267571b7edd165327fa66c76d56726ebab44b63bb848d830792dd57230f7e9fc65b69cd5e06b7ec753efc2fab933140bad873b8a324747f4a5b0ec3dd78154acabb48c9bcede14464fa9099d3a93c50591da70126e2ec57d20e544e523d35aec9d11dd18ae9c1135d3ac4bf5ea459638d255c9bcf544b702c2b918eefd38dbb473c9d684e0f4731ca64084c14b4d71a862b4c54ec6f5c4a1688415ba99d49da3eff7e6d76fb8d4964a6fe01a4ab77d23d6a64ace07c542618de380e4eb96c66307c7c990f184a479cd8d160363e18ba52d1d64e62888780ab3cbd142fb743c1b315ac3be64000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a630202b0e68891d4998ebec6b9fbabdd0c83803874aa0bb070c13106c321f74bcab20b5feb669cbdae69d22bd569c238e34ea5576b8d4b346e291b9a06e287a1a3175e1ce730fb11693fae3ae433226b3392a1c2810d55a5141ce31e092066b2b07172c84973cdd2a8108d94810a5f68189f2e040edf445610795d1102d66fcf9c9c7563b64ce6988b81f9013d244a59d8d8994657598c228f821951db5b0c55f32013715fe23dab7b29c82b9977f41be61468364dd3c84238b97c49e36fd305bd61b9a6705bdd19b2594ba6efbc41d91cf10e1edc97d52703c90ab1a1e903c4dc07603720d8a11a13a67319b0d7f9a93c8e0ea3eb545a865260fe06eb65154c0c53e84bdc7e7ae642025a8c812d246bc383899847017f65b9e7d81c14afe7a2cc5571706d154aea7a4b827ecbb8dbb527e5e3a9a690e646a657b35fc0061146eeaa3ad1f31fc95c2bc967101a1d8205bfc311050eb1d9ef45ff88c2ebfb7613568b00bf26065c9696e2d6b43ba1a44b1e90a689e460a31209f24699d234260e15aaa5bf2ff59b53bdebde3cb171862c6f8a43c272da55434a2399329571900405cd479ae32b9f47c0a4c2e5c36386f6b8a8b615085f2d4d0176085f9d88c5b3de027e3e2d067095e97f5e98ca8be9eb73784905c6a954a36e865827ef235f9de6b479dce36d7061afc23a55fd63d558f94ae5e067ece9633c26b0801242a77e0b9574025f5607969f6d1e953b07e6439c4ca725e1560122641a94b4cf4c08322810dc0ca2b589b253fa95ca148e315125a665819417c602540a4688f8f86a1e84b90a61e90e6dc4a2723aa7ad6f8803c9b98b8eef446a61777bf5d3dc49bddba64e96a77af81d89fa86c487e8af6173c96d39b658c0a2d42db08c0bb1260ba7a84d0756846528a97069388298bda1e6d840d9532f2ce84425cf525dabf4442b1bc8fca9da3a862a99369af147b6f41d9e85306a275b10935cedfb9576862536e19cb006219a1b595f305a1b0a1a74676304d91e1e5a0d45678cf1705dcf00179d8b849624923707915b60c663a3ae81901ca8f7492e377dba10687baf41bccaf19810d44d41fd2ab7ee5ef20b7d24c8998be5a59942039c112032f812a157d60827daa8f79b168f30a58e046e5ce3025e2239c149ae7ae2bccbeaea1c37f1268a2dc1642862010a674953782e79fb7ba25b360071d5d5d62c2a0aeb873689751eda1c13c79e30692ab4c53f9b3a9c414b70c69201637169d3e045a05cdd7f8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000339209658cd1d801079ffe8e950bafd70a028cfcc35b9fb00d232c5603a1d51ba13e5de59e0277962c4474e9f3f60fcd99c9b79665b3839d5c037b921a4de8e144fa1d38182fbdeecda6934e814d9186591f01c5e23349b34f4439b4d402c4072cb4d702966ab473d2c39443f41fbdd0c48e566d33e076422ee72fb47b2ffd661f367e9efddc988bca02382ef93590d4fe3ece8b1d9d8b3a653219c7d131b43e2fde2851541f467c31129e6f9b9d124221cd52610b9f138eac1d01f193148fa0415b29f5c86d15067eb1e26c9d51f05655e8545f734f8f244854ad76c6b04c230898bea33efdceef100d79f8e3b894ba583466749b82007067806e3a7b3ba954f6fc5abff0e099a24d14d865f6f4538736124acc5ead4169ddf2144ad558da3c74cdabec147d2afa113edfd1e2280766b18792310fb6b4fe5d0d9f65906b1cc43655bb3d6178ef9093ac9c8f1a91bf49008179394eee79e1d8e3228f567770c1ba1e30ba4bce2465ab68f53ce21c0d8ab2f6e535828f211d4db957dc3af8b7e00dabd8f1f74c959b2aff45121c5b5abd3136c6f55d5f5ffdbcebc3cd7a430ff3813d23bcdc1254fe6949da4e7694028b7fcb876099e91b92c65d85c39d4be9325afe81703e5b18cbd7bd9eb59a9bb9408abd966ade9a60303807ad1b2c14c04cdf8fae6950a55b21c9ebb5e94713bf8c2890215c5da94b59cb31edc671093b15ff5014db4cd3ea8060260dc1612e9fd6e5ab40f0656121f689c8e94212269a7b24305c83bf0583418755ce690913cb081f2893fb42bc4750f2c053c48c1552430793cdde1a49ac9e21913210d727c4beb5640ab9b7505ea4e59af417a085394181784bf1bb0bc32bd71cc57ce77541581f14b8ba4b758500694796262b561a38c72893c77b548d779a3833eeb064cddba5471cbffbc769e139946155bf376a56415ab743de568cd21895ed6951b5bfe1b1629dd6510dcd4483f206954964e0517546dd96900a2540a51835818d1730b0c9123e7fd8b28e6843bffb659945a273cea944ff6e83c234b3e43db4630614e0b67778ea760ee341fe68c525e90475a1560821ae6b2a85015292c36eaa2e041ac04fb55922c48204525187c7e0476a9fed04efbba96f369d8ae709506620127fd399613a9796c4ff96d7e00000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 24","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028b39e9e77e97b2f3f36ebead3a05903d741b8cc201d39ef7edee1a5358c87b39e318d086c5bfe45096e3a06cc843288b4edc357dc2c1a88eef8fd16bc9a26846e12ff9f3e94db2f1e29ffaa083cedd2f7f7291a0f34bf43c9d134f47890b2227f9cc318e055ecd816b916787fb005ba659c85ba5302f70391c78d4b1b2e69b957da731daac9636294040f67206db17934551148dad55b378e74d933c089c6d4c93d22b5adc44c2c4cceb2e1d3f935b97da183291ad58a5ea93679eb93399a71dc3e1eff229f2833eb1e8a4a9b5a21df869dc5cd2dac11f7bbee7cdbc79256b327c82a3cc6bb3dcbcf2d299ed130c7b3579778ee92f457dc8459e4d27c91a47734f7b8a45db4c9c1e26d66ad76f7b73eb9ab293e62d87c9ba7ffd17baa8c0b1ef071dac7f5122db17c6b60441156bbab79c66135700d3d208a1fb18e562a9596117fe0a2da34fd2949b89832302b294eb9ad997710ba8d53cfed5361b28ddd18bc6cd4d2dd10ced70eb6061467d26a4a8d334d255e6c5475964d729d76c691452496d7f71298d4974fc7e4e6c1317dec8a02d9421f1e2ebba19de03973d92250884e5029a4ac53bc1ae5995adacb744d0e43bedb685f743eb3cce27bd0f08fb3d9a7433448e4360aad82350235ad9b059e54e454ed82d0923ef6b2adafddafbe97af8d98eae2a35f04b22d50d5c9b20b7cf1989a125dfb6bb24b1cae25b1438562ea36d65139d450b3989a2e7a8af2786199a9fbb3ffc1dede85c31c45d09680aba6fd06927904f340b2e676a713f9f156afd6d97db0181c1a7f87a744f3c44d0b803b2fdc524c23dc896c196dc2f8abeff3a91ba4208d124a35caba9a8bc9d52cbf2facc47a7d10d545997f1baac96e8e669b06b12422ccdb85d24a2b50bf0b2f8f901978369fe1933476780000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109257ca5894b5db45fd113984600c56195e331a2dec209ec1c10e3084c068ece17a013a8b0d66348991e9ebca922ab0590124d95c20b72e2a645ba61826227283a7622b8bd264f1d211e88c32c39b731d1477bc6403d4208e0809ad87cc1e4e6e1a2631a547af8a0a7872d74bd99575b6316da568bf316e785a5771a3e047a9331c01500dfbc1428b3fb875ec6737adedb884d9f96c13756fe53af6d000f149827ee354d8e60212e3a6a156fe6ff1f8f261cb3c3e81e205fc66653d5c78e63ad637badd0a359b1e7f84e0239bd760ba5e4aabb73f2e8d3e996368940ab2ac8140d4aa2d6a979a71b34dea2f2d78badac1de8e3b261a30f0d2d511b028e3de0a0a5ee69a166d80b25eb814c929a722271e7f1176e22a7bd8d1495657975ccc378a4e0f6e2738e7cb11cf81ba2a0d7ab96ddd13cacb88d7a637730cd68a1e51d6527692c10284cba6b5acd1fa54efa3491733c2081e5e250ae1e186e6092daf39094c7c54e47cdb34a23823e04af99c8ee52a2853b8786d96319986f04fc80f4ec5ac97ca85e3531623a27863c1be7919142ac094234af4e30446d81096293534dc8637a44c22f5078244e48203656d07b59156763ccaed571a3ed54d2c22181a2be23516ac025a640204d13b602e5d7b295b0e365ed7365404c651349c32672784a07d69e64ac5f0b69efe368b58c1a798d21849eff713dc7e544820c624e8ff247ba5283c85f75850c738ba2c3410d81a0b9ecedd051ac51c7b59e6c163539d55e6f41161e0bd86fa9d66771aaa9e9efd536395fdb4a6ec525cc56532690b973b8cb6259e087b1fa0c212849978ce0097801150e75d124d612d549557eb594a1282a47c18dfabda81a3015686a74df779ca1d9f1819cde465df3393fe30e1622c733a3d6034681da72d4ae5d69041455ccc0544294c9a86f4b5c442dcc448a87518e95fbf9be9df4ab765ef45212619670c763bfa6faaae032c42381ba2d6a50fbfc8cbd0e21546bf8194023651250d34a88bd9e9ec5220a6f9b0e48ea631202bd9a500a0ad3074800df410d89d8b10dcbb49cd036aa72f3237b877a1b51a59bae965a2b1450c1ff26b2a140be98e006ac981c1d1a408de3b3381ea8f2d36c3470db84f2a67a97845635bc433c402cc47a9152b0ade129b40d05bd7fc621e4028c0b033e0d184a261f29f98a99aa17b46ee5cb638fa77b76861b83daddfa2439bb207489952ed0b8bbf5510fb5d5b32812963f49b984435b4b151bb6337bd5cd9c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000035a8f37a065dd696ad437ec82909261b842ec0a3e66f8ac574105a3c82ec8b4926f2466fa550f8ea1b6a9a142c00afa44be6512a85350930dffc99b95aa21012057051b68c48581ae439b9290a163aa4b6afcf80ffb91a3321c7b9abad56d5dc1be4e67e5576c9f3a7db96071859b94eb22a73dd96c66ae67ab11d1ab62a86d826c682dfb8cca3259dcb5b34be635421cd4206e7d92147f14c36424eaa407b441f58e5c187e58a26b2ae144888a3cc1387ac7d0a681eeddc3b7781ab282e8185ccf33fb27500cfd119e0415db1e45237520a868c8457c88a1d3ee97ec9451da35d7e74924f8902949e7eb14ba87c8ac672d7e4f3bec1b2814dfa67a8dd2e2d4ff4661d64bc4c6d6a78d4e489689b6063cdff5a3f1554501b424284a9f4b8fe777fe4e6afb83a85e36200a9ab40b9c18678454b2a3f50a4862ba1e36f0c57ad004ff90192b5619614e37dbb38a1b8a65ac613f7796c70772128377065b84f122540106d1b4f9123c4e009b4c0a85d59b35f72debddd154abec7f3fb25fd1fa04367386098de610b26fa3ecb031a6072d14607e92ffbe195abff71e586a984131af24e18ae94dbab0544fd2ad217960f337111bfbd4046809ea03c7c47b7177757a4a43e1fd0134859ba735a8fc17597e593bb58322136602954d3a21096b0d1dee5cf0ad17a5fcf561ffa21caa70d33998840e4cfa18ba481704a8b82d2cc1c110fc9a6704751365ae9f338afe4cf9c811697dddfa8635a2f3cd02dd1845251014bf2f2d6c02a907bd783207c4773a937048a07c500d7c424b5f65a2c376523740df9a0b60437cb8ae17d64dd51dd4e433af83b20c4b6b890b97976df09e3a86ac19006c229d59fc7a2923245b7b1f0acf7c42e486d41ca1ac1d7051aeef6003ce94182f97d099c74317f61eb47ae18c2bed6a3cb253c21ec835e435123e0a657ed926f880ce8e5de3155272328a467278f52ac50a1121ae818a3ea3a2e1f7401ce23aaf66a4ac289748a7e98a5124c586d8957bb4edd3f091492bb1a64d75efcd45ad51ca420f15da848b20dc6bb765e7b71359b3a9e95e121266ae4a40dc2e9a3d81ea1b1a643594b3d4e6abb7d1202201de92bdf0cc1ed977e2d5851822a01f48a6f23180822888ce345ac9be0cc69bc448d41ca20b79c35b1dad73e6c683e70c4439b404cbf07fcc39b0e5a1d33f3717a6bad28a6da4f091bc7a000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 25","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39d325086ed012aa552f85ff2dc29eb46260e7f56997816d109ec10b992cbb22c1663851dcc1c9e22db19e67e14edded864a56ec6f21dc34e4729c562af9bdeaf374866b5b178e16566211fdfbaf63a65956bc590a7de8b5becebf12ea4ec99e0e4b616373fc9fcc3e76d36a1d358be0b73571ab34a718d5c9b218f98d1e070012991a713161f9421edaa1fa040224cc216b6c1e687e7a16ffd7dea6803d9df51a1472e672466aedc88a410ec336802e71c6d2d8b02d58774fd725ad6572ee15120e7c2506e10b5239910bd2a96f55969e1648c5a28edefbd0dc61706e257949c4579f9414c44ecec36edce65693542c0c261d66e6b1c96f01aab13e9a56c9f88abef2cbddf9a4ddefd7474e024755ca3baf1d921d883424d5ae5ef620efce0a8db6a0e9d5d688c6451f9867d9ceef8a539fed890f492d41ccf6c18b9561895c313d749e34508a60a1a8d370c939e9022146639a698b8ed66656d8db6b2470f2ee391a6c6c830f0c17a65d73b6b688594f4fe58769ccd6ec5817a5d934c9d5952bc1a1e97a3f2e8ae4188f2eaa0123906e565e67ef6bec7bb57374ed5251e79b3bf2d5889cf0fc505acb0630dc5af7dea5da9fc35c7f067d0960b219a4e3311e4d226ddf75c5d7fef88a1a0fa82ede5e340234e8b5ecc22221b8aba445bff0df96578394e3ef50671e3db76d291d0c537ae956dce6611513ced78dece8e85a06ceb49c7590424de4e0ac98ce4e7d1fc031d0b3d677eeb5972f4d073959c9524b21c2cb49466dc5d1c84f751e8f01825cd60cebfd81e8d2b1d298ac6702d240f4f48e558b1f876b3b4c5c8246b6a51a794b4dfa26f0fae30464883291e643480cf7b8f3b67026b6c345c2417a9374f617234fdd22907e0a1ed212d921fd275f710becb934cd9a1660a1b0c481a4400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381094d55f0302f84e16ca4ede4b7ce7d10c91880774e4627a0c41977dad1173c5c9703dacc4926be81894c306ebc52e6a9a6638469f7a314a0409f409353ce5b2b6ec45fa5a2218f456570b5f162ec24698662d9af9d6ce27c548b5bd873560976934d835fb919abe46f182af92a4294d80a55bc3ea3b227f4bd193347380f5c930532c0f35acc6ab572944922be332282943a1be01fbc7977a8404012d55aba71e4fc2be1a384c25ead9ad035c130105b12b46cd217491d05b1ee028a0d237765c922676d4439c4ed55e7d70c8d99035bba2d931f263483d16ba53d020f5834d8126f41efcb6829d0aecec2b846e87e0cc5888b54848a0089b606ef669d7e52be55d441775c5c38bb5085315dd687c45d6e0ca43a3179941ed73e857bb4f84d6f1de96104e1a07cbe95c38b6e12323b405b021fc3c716d62c7a27cf1937bcff45a69e7e18bd8ee26d93be2b4228ea0bca906bc0e141dcdd7105e2b0c6185c3395e6955a88e4d828e568094a6e1f7c54796bbc088b264626561d49629b6e1ac5476cd402d5f480fb23429d8c67334e592784b9f2e44811b709cc623ab206d95cface03c0cba2b13c17a24b2dec7a807131e90198241dda9590cf4a569188522a4eba9804df61880f775f90ed9844cd2559666ac25edb747fba919686c7d717f133b35d99799450b29b3f01351290939723dd405ad08d6ae60f26419e9c9594991e320460b7f31062a908486b50e7c686f474b0755bab972ed2943dd39d5f0c85b870947b12498ba9d6c90e9865c14a0bc6173d39f886d8063271ac0afb7dcf688d129ec8aecb6f259a9594412bbab9393170d3ca6da14ce614d4524765c2c8b3b1e9ef162d73640e6adbb1b1309032ede646cebf9ac885c2bacdb65a7998a96dcdbad0b3920d4c665eb517c2a5794188d460d45f435699ebe7e25422edfe85b1a55c22da6f615b905a423c6b84279c0a9ea1297b9d1d7a9dbda245b569080f1d51618d1276051ea9564489e10ba6f943fd1ac14b0da56a5260f004b84602919897311d20a104486b5d22703344e26a4a78a5f58a5b686868de678545af649d16a03028df23b5ec21cfcfcd349ac08459d72448958b042957e624b637d200d9517f29ef6adaefa92824b5006d40d6152435909c46b7075a4a86a3095d9ea6d75ae841a29ec2af63fd2da2a922bacaddd02b42bd4b76e7cc87708612c68723c12c2821c99a97ad482024d7329956b5ea20153463055634cd416e4a2a6fb080c107e49f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000037b30d61c6fbd64113fced8c5205026ebac0d9f3522182617cb00b6e70c8da62ecc1bbc8e1fdaf17cc61dd01ce85a9072cc1d9d34fdadba5b93e0aab4c9c4c9e26d3f7f145fcb23673b6e0b373c0fd1a58f52486b72624ef91a539519ee5305772a006e49521744912bcf3cdbad424f00428aa96ccc21d000efb09da5ce652e361a6fb649a060835e3b9dc9cbec660c7531620115ec905dca6ee2a1ce36554c0fc1d6dd6863b8f3843508ed5c214b6923e7f5c0304e9b0d5e5e433bd029116a33a60cb980737ac950577d0594bfe0ad2225cb8d3fa42f192b0ec05a49391632a32fa931c0fbd83a7b6ea24301ad0906e7911f9d900d19ae1247ababb1c0e9b9bd165185d9d7413ea068fe8824cce5b3ad51fe8e2bb2c4022c61b002c1df4852e4910f38613787ca12371038b6364d920e07b4b417401253451ddc25624b5d038b2dfe29b8494ec960f87803caa256a95c9868af819747e4bf26faaba6ddbaed93a7815c795ad5eb7fb4592df678ac1375388cc7ed3a6230cbe80abbb113c80b70c789cf0c66b943e67ce814f12d3d83f3b90a4320feb7fb81dc93b05d7fe2d36584399214d3d7c71aef322a5d04b5470703b3660bf86b0b17ba9ff23e45f7befec3758786d2111c81ba4d81b83feea35a0668e5eb3694963bb4db3acce4fcba6f3f6fed9627580dd2d2dc103ef7e52bb9745bd42a7fbdb459b5c8aaeba67686eb899e3177faf0897c61b008ace3304c41b4c79e2ef9c865e9958d8716bddb69154fb33187d927b5296c1589fb1ae3d553f116ff6cae56910ce6717c446b9947ab2a981a8f5999c1c6e517eb3fe584f5d10059910e22f40fbddb709c9f686f51abf7d7206a8bab4a346b51523c362d749238d7ef6671a89cd86a8540604f134d760267e91eb92fc0fc275cab69c776ef81dbad35027e5307f1d34ebf5d6e4df424d709666a1e649c044c4930098b2e6e3782a93976b55073c504563c7e052b6816c07f0fd54a759d2bc189fac3ff54549fc4de192efb58a9e301863a77380967735910f63d35ef5fdbd8751de4bc6bf2e3095628dc7f67c1f5571d17aa342593b2c7f953c3f0f22da1862122031bbeaf0d00a029c043304e3e2609c4fed8a7404fa10e2ec846a70eb0e37c5be61e698cf2296ec1fbe6fed75f6fe3113c23b29afb5a6d7e3a9e46e2d89d8c06450cea11492c1a97f7d6be8ff6c014930043022b264fd32593952bc606f779598631e48eed86ec2a013d8eb866f311a4000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 26","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029139b5e6f6695f2c209a5bf45ef10f4a0aa6eae46204c5225b65ba72b7fe85b34f3b664eb4f709265a740665d03b48917610effe0494557b2b325503530cecae3a8643500b0451f56bbd5a87658c1a0468739aa687529ce734318ec1a52dfc2546674925d7d88ffeeccd708e9f49dd62a79d62bd0a2eb928546923b874ce32bb06a7b170883ecd3da99ac8fb0b9e43dd98b3729712b619fee5f638c9dd22b31f7c12835618ea16b290d21a471fd4b44fa288c64d866f8951d8bbd8e8f781814d61ec1b0334d065fd0df677f3cbe44125720ca1604b1069e35ba14432a9942d29222ac4bb082a1dbc7ce5264872f94a22b46eb7dd64b6f5f75132f816d5177af5ca0f6f98743d5a15e6a9995019f803dcfbc23402d16e40de8459f79aa071f6cdd85f5123115b6bb76d9e91b07ac72a73c2642c344874a6bf0397e22ce98dba77d2d16cb10cdf10fe29625bcbe2a52449d75331b0952d7275348a35792f7a110430c8abb979f38ca31fe332cfe058a2d300253033137c9eb8652d956621c9c455b97893c68b2266694f2ce27d1f15de805752f97449504b21165b3fb9e182af5bec294f8ab9f0fea611107c3e310335bc72e2148eae2e1deecca7f229db22e04c916caeef5d39f23d7a4dee52e26578a4b175aee8f8b877cb6518cbe620a521b4f8fced100f4e1cc9afeaefd666202231b76cdb86973ee7225d062f0d657611e3331f3fa40fd4c53d837471310a2ebf990e62a31402790e36d9d8f177f2dbe533fb6aea50d44954ea1710d349e0bab7e7066dcc530f9067fddd9c3c05a8da941c7246d2e0bfc987475e314b44b7e987d8f9940b8658cfda3648cfda0e46e78b1727bbd570127e2b329f6a63562b25336eb6f8e2a23d6666708fefb985822a921d550bb9f7d3b707be9e4cac393ab3bf0ad440000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109ae552855225ee73d39be22e2102f2d95f428d12cb699eee3133ddec7b0d1efa42c9f402d840871a2ef6cb531072849e6720200ae8a36cb25bcbadf252c698cb9edc88104adc0901285118658f2c0000050aae42436c1fd34300065860ef234f81c7c5cf8cf13e063aa1152389a76820604a2cb864d2ec041ad5f8b6c871c3c664219a7855a3b1906e55bee55048d3fc7239b5924603caab326780e9e84f59c27ffa7ca0072eb63ac8d22e808b6405a477ad69356c3152dca8d933bc6389a689aa800c1d10440a94916024a1ef04d82d62a502f824879ab6ded4c5a4df948e2c32c64e9a328c8b36facc71b5429be4d1d99d06eeb56a86658802e9520038a150753e2ee009d3640a301dd1aa4e7449385fb1579bfe9809262457db455d31be7b77208c61da45a33789372fd029e9d5656b7bb6562aa8d8a964c0c529542b1b215d8f0b6288ed767c63a0544b5b6c4d820546ef70951a8401192ccb95041692c4c8b55f524adb341343b88d1c5bb60088ba80d26b77e16164963d805a10623d216a43ac2002621dc2c2154c6a1f556d145999bd894872cb120aab5b4dd1a655120a1dec12f26228be93de0431b3a7a93ac1e970df87a87a254e709184da1a8447d3b0928d17aec22b87ef5c2ce4a8cb529bfc4b4dfa800b830868cd902198c3d302b46aa29c487cb808e43323aa1d3ef00b98dadb9e0a692cc62bdc8505d4a310588377a8f6badb88a7d50bb991d500a331b12822e465685a5209de53604d0477f91d7bf4d1435e44d2a93b093f117dacc093914221a6f3505dc4b241da4021ca65b37681362666265b82f23ef1305faaa238a5496598230920c6b7035bd926d438666f10437502a655bf14857db9ef2b76e436b364b1cb362fb89b8051c1adc7796f8606b7985f92812afd40694b8d8aea57da5725c7155df8802525932d58bb3bc28db7b6a93606fdeacb0b242b6be2c16a5685a7c4509cb5229161b2e14d4228a1832318a39d3b2aa473219a7a7774e13a7293e984eaacb330a154a8fa845963c8090dcac8d37cea6b03bccdc903c0406ca2e646642dfb6e9ac941390bdb478171a0ef298ead5ce9cab149853519dd9b26d88e037dcf21adc3859f218435c25fddb3692c085705d9b11dadf8d965c8367938041657ac6d3911a50c5bee85ce39b811434227528e71859dc8527e3d474c97934e36089675cca4aa8999192a28c3b27adb114c005cba25df46dbe26c70b29c426bad33bcd2c80bf2e7ef3b99bbf00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000039cc83441b16b39bd7993766e7260d07751af2f19a41e70689b0eeed0c118d9ef109866aaef31b2d2962a25a3d1ca999214cdf0eb54598382eead64435b7122d275ea8879bd47b41eb64ea908867fd78ecfbe8e992a2636aa7477de5058179565d3a2ceb8ace5c0302018043c411d89975a64927b48cb622a13f1ed85cc1113897a68488161afa1e636ec786a0aa37b928ba88a50164a9ec372523aa9ec8885aa9c95b29f7ca1bbf0652bac195ba94e976d336b69a9f5346b4c7c81457f802dc9757c7a2435a617317340f764c1a2ae131a716318f00af0efa89d3b57d8f31e155598b3944d950d6a1d6485b509358efb3745b95edc30dcff02574f54dfb2d31b259d132d18897df868115679f06d41102cd4eed4ea290f711148b99b647b8555a4c0dca1d2d0871c59ab1382a2d6417e6236d71e2bfa1a75cda54f93e6c087d611878ac7670a04fd7d8cb0993f456e3bc1c3b5898076e22d2d9e0eebc7d7bb8d142bd2b5f6fa42b40bf676fb69c532d7520a4a105ef0c1337f53d6e9b4ba17f1e76af4cfdf08f794752d2bf71e8777e2a209f8891b1a53d7bf2a5786b00b9a0cd0fce79408f26befa2535be188a68201b1514074cd70660971f86e8d3e92790ae7ac591aa7a996149bcdf060c615209ffab82e6000f41b2a5606fdaf4cd08cab0c2f1103b2436b1fd7dec477c6233fbca3b07a0ca01bf3476bfe5334e32aaa2ed35d5747d673e7bb622e1aa7901c77f28a3ab2197c8b8253a1d28c969eee73d17ad71c7919e7f217ba2badbd1ebf986cfe981024fc347028c1109cd4204c7d53535a9b677e39a43193e054d0fd68104d88934dc7ba6cb3e942aec744b935cdcfeef4221784f96798e650ffb0febf2715d75339d0cb6c2e57c1e9d10f13e6786b7f041ab307b8cfa51a2f10b622995230fba54b70d94ae278ec224d9d0950ba97beba7eeb0e2fbc4093e548d9ec09ca1a08e5f0483024d7c1927ff8dc270900d42d31b81b13a29839bd746cbb3591bc33817741a31dea308f549a74f3a4e5478844183b8d7363ac1f4d4a5e907d9ed98afd08fb8baa84c324563495387a4f12c239fb63f0810447131311b2d2ca302c7da2da57c94c3b5e844f537886fb766ec0e977254dbca8fc84ad77430428f0692e55d8e2cab294b857ab51a2ce4a725433df28d9caba86c770743ad987bba58c0565bd18590931e283292889294b607a5f19d9e905aa3940836e2a74a2e94ff3062e85a5c6c978b5eb2b254bbcde128280e6cf02c11a0c2066f349e3c6c083965d5b8a9c000e15ff36c5bf3a6d4200000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 27","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029339489320464ea8b179bd13b771054c23fc6c06602416c8b5dad336b62da10c42e1cc87d7210b94f88ab2c4d5262488974475f9e3c91832f4bfd9b49569e369253d69bc5417350308cb3429711ff077ecefaa35076a1eb8a42e3280b38ec2458c8ea59204a7874671e62f8b8772ff5ee2d2f46e1cc3bafe76cba1d0c2a6b9066acdda252d82fec52459a3df59b0d1b957a7e27b5a75d9aa94ff556deee722bc0b77260fca29299b6bba4539fc39c57999de4cb28a4d22e551d95b76af9373032ca8f9252328792fd4398c3eda8e97469dea9e38ed5ff7e1ad97efec33f902894eda15d3534584aeef5d19e798e6c84a7189be61f76c73c5159c2fe21e86c9c9005dbb56822e8557d8e91ef4c921446987214aebb65677264fecaf2b451292d4103670e4dd2d390afc61922704a228c9259d98f421c1825076d61f6983fec04f95e9564760472204e2b7aff6c4727509d5112aa510f91e33515bc698fcea819d8b4b64e9af3b98db44712540c2ad6f5e312069995caa07a4e3a61419fe5b81886cc8b1de279ac579af221bf6f92f7917da6bafb66c047edb1463130e07ad95aaa3eba0b2a4e9d4f9cfecdbef3324266afc6de9e31ad2b4aa4aa5b263e9c8b10dc79a21df495076e9a5da13e4c187f24a79cc524abffae72efeb6d28453f51819ca54dda776fdeee6c6c867a1c6dd5e2412b3dd593d39b7b16a71da56a48539afca8aba2c5167111b600b6d5b185ccdeeb549daa98d3bc773fa4f47398a092254f47ff1ed7b26e9787031e83b61c688585941ed4355d816923f883bd909340626eef02f28bc906431787c115575335dcb4c5959bed276d81ed6165bb448f0917c9e80c225c8b1886b16586b418c46b7a8c1fd8c3a0ba6858452d9ecbd938533f7237d6ece0b7db22bf3b78e0155d2ba0c232895c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810946851f2593af933346e227da5b194c643bb1a19dbc41482229668309373c369518deb646b8a940d5d7f3a9653d941ca38a64c4f90bdbdd313a397ff6b4d7e856b61d5829dd7e1ab2db01c384e3a261f6a88858c1ad9e31f5ea535ebb52c059ca85bf73468222dcde6b9c5e7bd255d3c730b5d61aee277f27e5c8c59f65752f744ff21b12ad325638f41f4621a7259556d6824861384e3bb6401ca5358ca1d312680b0d2f80388bb26c00ab0008515738f6bf11c913f07e803b0615a4712cf8aa743acf6e073e12e23411ca6435eeb60614106d7a3ca308cda71dfc5639318fde671da47a57e3af049a4dc71826af379a2bf33ea8f44894c7a61f56549e5ec3e761e1bf4d44970270a9273bed3fa969c40b3470383754a3013af4add24f960956e837608f48e7066d1b34f9188b7191fda1abab78a81d5c2a6153df432c437253dff62d50e3b05e6bd00c6d34f5a1561a7d6d796aeb950f53803ee750d3a3882c5057749e1dab118dda3bd3743db9a305b1c01f0d953c008fd687a1f21c9be124d21d9de9134ea7d29da03f13f14075182a9d54434f00b44ee979311212840ef0f92059bd5c7949116961cd8962c71410977d48c28965da442a470604561ada652830aebae44528919265592068d03e5d19e516c3d9ab4c3623dda510ac8663c1d3af63535630f0624e7b38255d909fedb9b8ec3de1ed9235ac10c9d349dc6ca60d238ba9150e30cd5452c8cb4f59e49093740dde4a60973655a42604a2d064208ed97dd93f699e166066c0dce3339cfd5226dfea15e7c7443d08b5e5e45672653d89ea003b8b819a0537c11e8904f00b58e72029556d2b1dcffe67ca763879527e13ec960a8c23d216b90c36e96e623bccca7a20a7833ffd70d7dc50b038b89e7968606c5608e8062445ebb7a926e9c7ccbea432fb3623c8b4a7a675f05c833996b0d8b081902a99e281625798be81a290fac1011e56286893869f9b5fb40204645ce852787cba9a1ef89f026502ce2fa4b7aeba563b95cca136b5a05389ea4926690b7ecfa5b31204a4c124dd5f61eb63d7268246c651920bdf2455fd7d31950f278e163154291b79b6c93ad261efa0381ea980dd4efb5f8406d62c508a77d9be5b8799a598584cc9df588a598c4b97cfc63579967639f6d0c20b5866eb1d5b593d46ca363de17287498e3179ea16b43eab381d46f8b98575640215f4272158156e6bcd01c1dad878c809459510069e60dc817ae965609c06b1acbe15b2691d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003bd86d27c1fcdb8164f8909073f590d0a280e5ef193b0c42863ba518bc8a51e625658dbe2184c3353faeb674c991eed3f1b0fe3bbe50a21ec70e9f57b97c38d6e436d3dd577d7056b07a401ff0ebbbefaf8212b993a39281190e309ed0c50b269e4852dea85432a5941269fdf63766b21d25d8816de5e87ffa051009d232d6b258c5f43f45f2d48be09b2ccd8fc963fad81fb368502057afa7c865d62d932f652802a299295b29411439dcf832e8367a749b4d7adf7e8abde3ebfb844a9b1d32f77b2bf96b5d29fc15dae83ea80a990aef6590776ce1cb81587ada80b9a7b45aca3bbc54dbe67df090104fa196701280b97607a333a9b56a728710cc1cbb7569b79ff034572495181a92d2380a7ee5e9cd1b0f758c2bfbcc4e11464f1cc7d91f117319c30ccbf4c11e60b5dec724225b8d77b71aa58f5fbd498a3f49115687d58393be648805ba1737bb921a08d738243920c3834f8782a8256b7dd22ccd5f4ece86b8a0860bff21c5c8f0be987f2d510ed4df9cf94bf698680b7cfa22a575a3d1b5b431734b59a4b31913019c1f42dcb76a9ff32bfbc6e16d2fade26e3c17bae49cc415e4b370d1fb43ff652be62d18b0affdf286765f4f30fc8d6f2c4a58cd17b3bdfa013bb2daa075be5f522ef9bfc2e1506cc1c4d381b3342edc19c955a5fe48a712af5ace66a028d03fc859711c9d33231e48d41e58a2c2ad81da77529ad5e6b73e1ac96f0c8e53f153faea7903f917492a1d2b1203174a08551ff0f9f91e32bd0f31d606c80a505d5eb55265542db3653c2621e7eb3fd677f49534f261205f834eef1645af419ef6be5cfc16d54c7eeea12d2eb9458831f77fa558e4d5c7fe446ddaac3e1d502c941c95f572ad545ecc7cad21f0dd50845cbdedf589505fd34cd8c00d57243c3aa3615d84c39b0a72c28f40ac72da25ebc6987df5a7e390399463786e75d524ffb6c961bbc9301264bfe3c699101d18ada4a72d193971d54089e6fffa684cd3d77570ce0bb9179a156d3e2dcf266358499bfc158ac9a6913f622ca861c968ebba0a59a12674bfe39389a2125a02563b082259483e80c89a3763c0a9c3db485aebf22c844539edaa28a3fbc0053eec475679b741d9afc16b5fa109399fdd1fc3574df8a1292b8d7401aac1be452d38f97d531813369ee4c50f36736b95ae9c3e4f91ae85e2d664337daa40f75cced2f4a4d210bb4ee25a56dc217dd176db5aca43c002afd63ed8712d89e266674d9736fe4a9f202a81d177970411dccd289b25798272d2647ce6451906a4f7d46e87a46cf6cd048b6bdb62488a24f48d1ebd61ffa474321b929e0a7b6f9d0f6d777acc14815f343e1000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 28","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029139b5ba7b60079daf1ba5a00cda43cd554b77ce43d9d4885b0b9e7561ca1741227d47ae62242d2b951a8e67b0714461be74139693b2adea9b6653fac921dc46ad1eeb5397e87ce1bce4fa36a907ed115d7274daa6616caf3f7d06c3f9ffe034f12abd9ac3f8e2321a4d5ab10e8558104d8ba781db11b41790422f344cae93cedce159d8ee3dc83b354803492faa68fe9e15f2d3d04c0d062067348859706b5803bd681e8a0a79db5117ed7add5bcb11f2dd86c41b49dd9fcd5ed6785d3943bcb949909bdf93957b48d162d471ff72892a8727882cd4ce14d1e48fbdd44d1a71b362505ed5610012f492019d9db4a7ea0b297bd5d688c20fcec21482a3ca4c3b8aa1ddd02e42bbaf4e1e41dd9728cf0c09cb49d06f12356cca37c63a144def14474d6cbbea9699aaef8397e213787280e538b97c7c591b952578276e449bf1de6e7aa47fb228efab148814231bca8e90387fa779f18149abe7235ebb469894191e925bb1e882c1a4d0dc22ed517676e39afa776dbaaa6906c69aac21506c7ba2b0c079c2b1efd36a09bc530f6b337345b3d91c3d9345ecb07c6a48e2d833234e5e57732c9f5698b82441f3d07e212ac4154925bed83519a014a8015d74dbb8dda9774ea3d58d951a46c93766a6930c2055c7775544e14409da5a847f367c09c6e15657382ce993c240db963ffd8c299ec7a34dcb658efe6d6a788a0e3e628a1a5b9205d953bc388f84208514fdc1d365dc5a091f25fe86d1464061630fe88c08dc5f508a94bda1acbff64f2f15f0c17d60b50edc4718ead7ba98f6f6423d178449913cf03cec708bac1563928e6d574c1ed9a36a94e3c1822b7f56ba63b5d7671489421d97663d4ec27f657869383b2c78d342fe64ca30ca5b58e59ec7638771ca8bc1d025af69077c2a3f73857eff691e680000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381094c22565a9ad9cfa0b93be14391a241559b03ff8bfb54b007484e5065638a4092d090e203815a51ab5d2614698cc8942ac693355a9aa8d34b37d42d57332a2320943676aa47b456c9ed35e5a68e1456edaa9a2422244a6c0a5490d0ac1dfc700feb870518772b449849196cfdc64a4bebbe6cbf0158e84abb513378248cae12c1976922ef0b6ac414d97d16825d0e02d4c14d625d9d0090d62e13508d18f21c1a9736982df0f266e3b4e465d3496569bec5e346f9c6a52b357e25f8df839f6e3af003a427a9a234a90dc3a084d2a0a828d65a44d6ebc209146d9de20f14df1fad5dcc94a6c50eed2ab022ba9899696528b626ac84f688952d84bccb1f106567e58dd468a9a1db62a2492650012aeb5b5c1267c20f2394da5a88a49580fb5da879846cf591dd0054855d617145916d207079195b620f38bd87da84060120c3b567ca925b488205c89d48b5849347fe0eec48326fc926d064bae1f96afc55bd84881020304a85096cee63cea82c79deedf823eb0327ae9707aad60a1ebd6d0b271bcfb109cfe57e968559499f2436079309aab1d7b69262bfede22bb7deac232cee72e406e472d29968f7cbef22c2c2ba759d359d393e56bfc6851d0284a5ef126a229639fb52168a0b18d906d6426a45d4ed269322be6b12e642b00ae6bd5df40ba394db03c414f17fc36a81eafdea089340b7cedb42a418b0bdc5c065cd2a5b832d41d9ad8bcd90313ad241283a9209bb7b3393b111ce8a40e7c4fb68d5591a802669ac895db467d25d8f0da7584b4dba9c8acc0b1d83cf665cf6b03c43a6697999701ccc327476320b1e49f16421f3c8896f2b225eef59af0707ad2692394b6125a828112a7704b4b2206ec8b524bd0b2081d04bd6c211b514a009cf0e34284a006bae44b98e68aa7646619d49b838b19d9aba21919bcf19c50e3cfde3dc12131a8e435198d7060b3e9ef4fc1a8b7ddd97ca77173a2de081db232b6f62218201af0b232ef90598ae99257709c4443bd5933cf8eac32285215014ae3502af68b52cccc4dda13830be2f20c26abaa8f97af22f53572c340181d403d5290abda684d48436d9c4b6d2922cabf2d8e684188d94b25539bbe6853a362ac890e9518b4ee6b46fe72c230eda281a8f285565d379b7c553ae214debef17da1a9660e8cc13b019eca87be154c813ae82b9eeee6982f1cf39f699bda514d333c8ef7d77c2e691e1065c2fd4eb82b6ed8d15b4851a642dc8be1e4e43ac64e50dd1564b7dab7c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003de56ed7708f98432fbc623424c2a3634780470a01784becff01bea5ba192d02c33675084263c4315420a009579ef80dd15eccbb812652421872a9577ef7d07896a727a64141bae7173426dd5a3925159bfa927ff1039e70f729847b48365b4d3551476206aa049ba5ae8f605847aa03965f058fcfd478961ebeed06530abe900042321059c297dacfe76cc12d52311b2ff8ee1231c77049e232d9fdb751fb27eb7eb6a373b4b1c06bd0ff46b1b208072c873e6f938e689839079e48c6d18f678769f5f28a903467f2ff2a8b02cb19df675a8fc7560a7d38a918ab8be083ec4e0ea148517ab90f38394833304f245bffc47f9eca771fb80b9c71ccd05fc3b0d66eb06d24b914b63d9f16ad2f2bc454b591d01ecfc527277ae71e3dc683161a53f129743f3428fb82a89dbd5d42f3eed237cd2f8d76de2e56a2143ac6b2ba811f745cc72132028eecd4412b76fdd87a2e396adce72dc69b8fe053042e798b220974587af96ba419da6888b13ffe217c9d01434347f4162fd554b760883e8eb1aee46c4c26b990c6ba10d2d939f513bf0eecade8b5deb8de2bc8c8894aca51e65aa696e390c11689f1c2cfbb70bc5f72c1872d99babe8de8fe2dbb446a8129af0ab8d9613f0cbf3cfa6ea3cc409f4a97581d5012707756994b6c8d4fe7f64e0f0b85a85d0a5fe23224dfd7abeba8e3fb2e97ad87fa8dd477adf48f64faf486d0df11ae9c3bd3a04abc962c5b02cda02d48f0b52d84d4920c116c22455df291a96e6adff91e3cd35cb8b5b4e70e3da8b87cdc969643a32b1f97131c5e0bae7f6dfbfac32218eaa596d444574ee85ef7c9998dc1088e5813d50a4377d29506817e4234f68b32ad68e00adbf6462f8d4e215f15a19dfde452f0a65360f7c1f20e11c42eec55565ccb23ce248bd62e9dbe8a7d6639028a92b422ab444c5688b5d191a4ba8956f358d131e2ff6dfc607accc5d31af9678f1a226530078ff9a73d681deb697670ddc3e9096ab0fedab664473dcffedf9be62a5c7c54fa2eb5059e9a1d38413b1a4fe6d531b799453bc7185abaf78cabcf65f365b00827cec5f29c4737047e3b2932a78757e9626a958486d1740ecf1ec17a01aae6adec5104eb934f432207ce31d7096acb3a0fe2f5dd7890c021892fe7d3f34596cf20b6b12fd55911acb46d7386f99a9e9ee067a45c6a1fbb463e63d69cb582da6ebd6330f4f80a1fa72f2ed24ce9bbcd967118cfc7e21f6bfb68a905f532bcf8b8befa03295d362b41d25cdccfc9b41767858f651bc56ab2bb4a8675513c5d6f1c943a20a27dd29f941ad141debaad219e056510bc984063fa0f389090d434157438bb1759690c453a2f55f72c033797a4b0c534ea2ea084b3b6f8966ac56b106fcc11ef08902f2ed0000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 29","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39e6cd3fa7e7e09b93000e06907c4ae1064148b82f3a467c01431a8d689cf7fd2760b85d27520e2b41d08423f3b27c70a993782b97eface24802f3448210ba2f865629d26608fb198e6275cbd89c29250503189f2e2e21861b355104e5b08ca4ea590086cb7a7d0d6493b526bfb3d63c494d84a65c945521d893644e57fe67553db48d3155c912213063fd5d3c7be362d4742f556ec6177f208145113e1bc348551bbf621a5be7e6a311097474f585d8c9b42461ed4c27861af281ee7d53a72535849f51008e4b4e9e8a3a68132c7cd73ec0348f4b5b4dd6e38d6cce6134819d6b869b2058ed9be8eae47cf219e20aa5f41c96490bebd628d9a701db97ee6317ed3ec8e432bbe30da6811a5fe20828f19922132eb1c3a1ebc5adbbd5d6b1c9e105facbeced43cecb52657a8c4aa33dc0be7cabde99c65c9b164d1b4bf88827ee6f0292dae893bc5c5c8c610631121b26c172bcd113623698eab59abddd10ffe0bcf88d125c6714362e6a630c2a6b0a43b37b572fb765f6dc7ff06f2c13e28a932722ccc63329c70f5982312d7f6f0ebdd2f3b75d1a272aeeeda36ca9e644bc79f4d39b47627e8c2ac9e75bdd9f3d1724af6c54d844cb34d95bfa5e3bd4e9b18b78e4d6e941b44be7673a0dae6d86b5a84ca1183f3b0590c97f3eea4a3e9545238ab20bccd32fc63afbccb9d318c5b114acb05026f2514840d7357ae4fb3383a9da9ed9620a53c7754fa8adc722453841515807534581c6a4ebbbeb3aecdbf4090f559070e0bb753ed6d47b63c5de7289de1953e6dd58db744af31ede53d8c88316344ebf7d1e62a37c754b6f3044f9487a46525896dbc904bef437adaf71d4b42b0c0eedc14bdcafc1eec9c7d627e2290397ec50b388f1b329975d28f24d74e6f4d2f03233d2c7105ba25babfc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381099b51c80124dfdc38dd3ba9db5f74653deab8598994a89d41228d2ebfa982cbc834a90283e96223528d7b585d77615c2c2dbac0fea0b945cb7f543b0340e85390714892c9d816a21185f09da28d2d0cc924e09b756be94ca73e8488aa79827b0e698037a067ab9096f7885838b5786ed792f23559ca563e963604f3ad29660d7d659a7f2b4b8605ff51ab589752f1be127fd50757d83fd5a00460bc1c99eb64cc141219ff0a821ad65c00ce199cdb24a7106c62c5c2463af1d8d6c5d49b47d697a22162c25e5483820a5ec3ba82e38abd8dfa69fcef9ab6c0d09125f197ee8682708546285d52c4759ea5f37c58a6098e67d5fdd36430727033e821eb8508e58601955fae4ac50a32ec7b1cd884d999a73137e2d16801e52a7ee88cb2a08facbd0d2e02fb6065647886c768695c7b11a169525b958b74ebe233943c9a2c61eb9503ffa4da46704fccdcab66adc40753e22b55e5848b154d4534d3bb5ce37fbb3c6d55690336a32869198a87d9236e9b54e4a09594b1a3f176214aa9b48d52b4d585b68d0a0b990011aeae9c73a950da77b25065b0c1915f5db4116e09be7e5c8774cfce821fc066960fc5fa57f8efe72cdfbf07bde8a6c62b7da0326c7372d1a080c041610b24216d4ad715eaca9708209321591a785fda386591dea20b3ebd15cc643db8d0666241c56f84c63de3fdad569d651aa88d550fb66a51c6670dae05220ca3c223b413e84509fd16fd8bb87d186d09ce701e2b416fa6cf9d6e369a1b6c0194fa059be0d989551072b561caed1db6978361016828ddb0e65e633664e6d097b58d837f49d7fb11c3cda52a35919410d167596b6609c8c303d95d08ef6ff98aaccbfa1dc22e5ff5d3037d8ce52a5e3bc91f64ff02f63c788627884a31fe1a3d2dbd662e64f59356ca6a60b1692a639294de1217e5ab5a79d6d3f84b084d797ee455ed0ed55f1485835e04bf89b4ed7bd8207d07fe0fa55b61a237da47f2a521618c1ce65a254f4e3a95a9021b8555683888c9461a432f55dd225f1d4e09e0ca3a288df88205b4232907d409589b326745525d0de8e596a973bea5479757d76c2926ad1b2499a25bc19fc94ba6d63ab4d5886e8e3b229604f3278c0e5c39983b9d212c40d6663010ece0969c8519e39334082636713d942fbd142e5a632d721e11fba3fd8ded20c269067adbdd8058976b76931d1a7ec84a9a063c9cc2e8846d8a9181d4d2f42a42575b88b0f8cc5bbb8a90b0674f22c3364d30094b8e530000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003ffe42c006f144b0b4e188febc82d63d3d37096deec9d3dfc3b421635dddb73c76f6260ff1c53222a50d30b26e2de3d16e3aa64c78604e1191bbc0e2553117a441159b2a35fc8889499a2efbdd2f30b8b4c6cea38eb5b2575926e6f22ab96ddb4b0c5c6d78c3754a1b6deba49ffbcfa7477be9a0f74ec379d1c9aa59247c091611573af765ae698d78152187b291717a9f03fe767bcbb12f52311215579352e7ceaa8654b5403f18ce82e0a73bfd5fec1063b506f44eb1c9c5a03697d03dcb2ae15c5095f292b4bcb130b55c19ab728b3232ef77d1594611573cc6bdaa254f05934a329dc27cfa6cd8c02cb51c3c295c964c40502fe2b1a81a51c866f7c7380bfbe339b39c8f51f73722a05b5d1e9cb6313557b3656863803c9dc99bb1905d7f729b2db8da23d88200032f36ffd04da11ffdf6277acc69c5407289d00fdc3c56b32d54877f4a8dc70abd37ec532b8617d9f3c535b8e962fb389e976b4d1aa12de5c1c2ffacd50acfff65201104648e0c04cf7c1f880e8bda1d68404ba67c4bf64c9d2aceef81b35fabce58645e0f2f61eb4ccfefde7239be408710d349987d849d40b3ad294b9d815a91848f9ed53b69f78d9e955f6d1fd7e38ec291664d54c2bc359fba241ba6abcbf5fc2502d93760d9f6b1f7fb766040e98bdc23a6047134a35327fe128ae24b4c7d0cdcf1801947a1821ddd7424892df50e2dd5c1e2e6c5bfb4467524fb45c7d977604e7e0f1f98eb8c03eee1d9a5796c8a801f082678940f076bf44d3496730c9a640fefce385865899fc33b5dd34d036f2fd5d07fdc0a40fb725e84ce403b46de712b4b44ca8801a1ccf58233c5da06719769823b5945849ddabca56b0b4ef9327c8b5e5a445e6853e5b66b8d590759d6b2db722c22f8c741cf3c6325a76d93f4fde5872d5732fb19aaadeb7c18094727ed43b305b87ae2dbaad67f90feb86498cf65cc57ea635340f27ae5c5cd60ad3c763223af877e65a005c488aa4af9309e1aa02002b01df8865fd481ea254015796985969997a53b06df0355a6ab3c8219b652b09e1f86a6ca12d27c4bcb9e8d35e6889198c8fed71ad5642f5f9f7ce1df270d68aa05467ef9acd9a51347af1ee9ca7c4a5d78189042900c6d561f68d410a77e79726dc123b196c78829f02cae7d0623bfe9e7b0d8bf84033086295992b77acf027489d51bc7ff006a8d4ab8079d494413a565e7f687af40dd18b86aa4274edb8845df114c0146de3199cb55f773a87ffb126b3a4d00d38835cfd2d6652c07f572f39d0397fcd62acf6ed9f3e8951348ae7e52a669fa4e2bfcda548abb1989a1d74a27b73103770290e6ecac87029359354ee4c87a77bcb5ceb10162dd54499905ac8ed442c173cacde068bc546720d1284015acb90ca19147694b53899395dc663d6683908f3cba29ad37f15cd3903c4c7f4bd7300","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 30","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f39edd2abd40b20f20393d7704593cf791ee9bca0b1246688d9b6211eb46c6c9e87e85b7cf7118e0c94c255bc37c95a0e7c7beafb52c6701b1316d4987416d2aaf491648067d407e682dc326a65f7bcdac5541965d3b4c73d358c7adadb37430ff5e3dd68c850d969e27e3f34445b648fcfd7c9dbfba90413624cf3c66102db52e65a28e204fdb0a646eb864410585523c08d99ec6f5eb43b767acadfc0459119fe2a07bfb3390779a86e2566510132f819ac55dd6b19f77168883f94dbe7d204d9788baa945c5d9dedbe424b0dfe76532af846e76d4b075339d71ac5bd838240199875a57d23b609bf310c7c7e5b5c1b28c46df55914092786c80ceb528d947e54eeb686baa7514ba921821581ddeb2d8eeb0feeabb1544501b4757125266dab57d27e3f12c900ccad3ab62de8c9278fbfde18a41994818bc2307f0f3d6af98963e87ad7fb5b556a4fba0286f9eceb7b2dc8c559b1d6ebc492e56aa04a20391096e7a6f8c6112a4b4b5c314a643d39f8445bc454f1d9866c8eaa75141e01c3d741fc4d91b0a1ad9507635a81127986b2361008675fc718eefaf8da45e8d5e41f56d6088ad430ab65565c97c2d98d41baab689cf71b12f135e815428130936faadd1e469b128dca1256375135dbdc8e0d3db7d9387364e30f413e728c8e799918bfe3176598baa2352c854ad1188d834eca3e3cd90a7b3887fee904a88716f4fca868beedd2379eaa743af4357ad98b8228d7346a5fb776a0d4d9ee6cb6c574c42089fe16a33264f31abc4e65a073940ae53c96a12a5501b1f424b87a2cb23ec454b3683c456ae1d350961c6a77ed4d08fb9d0af1aa2b7f98a36ba7d6ed62d38dd6b6db0b45e3711edd05733937afd24b09e7266b78559a2c5e24cdb32aa4010ab1329bbc8e895162d53f4bc3b61e2800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381092fc8155424abb0325dbd754ec57804c00f7af71f503cec4904e4818417b216f4dd6bcc4a9a9ba1b5c6f84a1912e6f06fd33ba229b792d5d5860e9cb23f657f80aa103871242c88991648dc93f1311a7f7688e4608f2013686859873e6d0210dad3904448aee3e3d40811012417f15ec800b672581aa023a526f4e4ddeace04faf63406ce6718c1af84bf87fca92cd23850daae5ea2a528aaeff240564d0197da3966e10ef390c36d624db4d81dd7f578c6a024ad1c5fb900f5e39d22cf8329c883231390337e3c59209b518294dd39d2a96ea77174a75897446f1d7a5783805bbb21c272a2ec5e39a51535351643474088b55820e701f9d9e01b26ed2cbd3622b9ef631a3de74980aeca0815588b23064433d69f75662e0f1a3ec33397065397c6c6a48f5f4012ae7cb6e6434926586cd9f688eba3aeafb2b4925d0ffe29b8915747b2214cf46ed5b079980279c609f41d99e4e8351b4486d5789936aee5b9520666e2d77a1a79cfbabb10daa5385ec0811f7653cc05513042b56959d3c570dce4ade1ab22718c19927945156393260680ccc516845c53190087fd80e21438cd57446bd671dd88c078553e4ab8d13aed4d5a648c4068b50460bc459ee81e02116361eedbfa16662634759ad5c2579774f1425a19197408d375912d346c4c9dbb746ebf06e15e45b7e9db5ff920245821fa4f213c61980a8e0ff973f46c57b08d09dc5a6c88d9bdb8328560541a047a3e5ad9946e0f76087bdcda3e1c6de131e681132c70db56ca9d5756a5ec70f5491d5471a807330831ad388cb51a48094aecac69bea30b4a5e8850ff87ea78c2781049e05925f81f3bac45280ab4988696cb4a3e3077e664eb9539c5dd71091e18169c8dd83d8d22970958e772d38d14c4ed314fc9ff03a647a36b23768e10df64e8d1bb0cba5bd0ada0016ad015331da96dbe34847b5cd84952622707e2cedc1b48ef16c3414e5a9e26e98c8c2d4c76d5243e26ff016e2b77b31f638f0c85c7cd6c1d847e37933dc01f8a79723aa9ab9b36484f15ad0a6d02a5c012a642cb1a14bee319c1df463a4562b08ce4909e1bc8ef991810ddd5549f971071d6c7c6cc60e8023c63559febdf5c4cf92b47d6d96615c8573382f3184c2ae6426366b4f1d088758e4e6a2ef39313c4638f5a3da0de2c0f612aa653fdc683a9512e1643c61c81da50a7196d1a4f8a78186f01fd3c861083f69b9f10142630d2c4ebb19216317b5dd9adda05ba671d77611a681085a0e70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004209c311ff20f574cd9b7bce1df705ae7dce6e7a621c935a6e57a59eb31fc443ab1e014ad332fa784583260aa6153c464565c4568108d60cc126f6e8ec3bc9120e5659c86cda8a31a7131936de7b3db39a4692808dc3d2bee8a99880ff9d1d5eff1e825a0f043d908d62a99779e013845ac0c21abe8e4df0ee901e4c6beb8bb36b30228b7756d617a8f30c16351d8ff91786f7406f75d9fb648830f88ea4537f42ead62e8790e9cf11f72c31d718221049c9aa35376ad8fb065f4809f4383a23c2b29425836c2dbce4680450896eeadee6b83539adfdf59aa4fce709d601640eb9a22dc3b41108a8ee1fccde9945ebb1d3f676ec8395255e125e62a32149c73451f597e1c32ad979e5be914ffc7c548d6ae92ed08501831e9007770a0233e5778f22adf7f1aaadf9c9a7c82d2f42989bf21627d3ef8bd0377a5be5c9f5a585a246a73de4340e6b43b36db775b34033962646c16f26a2b7179c40a721fea54805b9ec42177b42160b1a67341235b5af9f30b2703bff8cdeee5bd7ce506b0707a69f84225b6e5a92e80edfa235803dbe2cec47cfef0d9fac95c3379816a39f4550bdbfb45609c76d0351ddf8d61724bd5e8be94673b3013eebe172cace247d79925b12b5dba2f6fb72e797b2da849b79dee3db76775f5f1dd4595678671c7b18bb3749fbb0c6a7135d639f16b3864b5a251114de7e9f8cb02b4cc69902ec8d7d544d98e24a05f8accb182e2eb44bde868b077b1fac4726e8b01cdd0d024405665f7adb60a23fdbacf421246354e824cb74dfb35e57902794e459493905400d0a0bad51d8eb94efad55c67cd0c7cefe7a1b055f06371aec7f490fa685c611d553d8430992ee7b1855a9cb305b5ce53154345d7def6110ddbdb5cb59559eb664c6439e057dc022f8686f2aa0ca81552428437b0ceb5fbb5df254036bd2bae7290d947c963046771a39d2656312236569e775e7d2a041b7eeccec99c1b9d2757c7370e474012ae707ae00ac37b73ed9c8e1a2774e54baceb42e8b31bea734463cc15576bd4f7a33430b1987d62e47473391938312f2481838f286c4dfaf701ecbc6eab1a9f074c1f8d8963457dfaac9a9a8eea70c50ce70d1ba1006760ad3887605ec38861dc1a777d21e46ea169537057cdfe256cc08699d73b1ac4fbc62f863353581cad358b9c573d77585df6544e5d55048d66a352828cd1adf5f42310ffac022a25824430f741371027b2dc14717dc87342a74f0038674187e478d8eceffc16474a4aa8bda0c8d41962ef2a4b64a036c888ccf4ea628e1cb9ee0f9a918fb1b22b9367feeee0218c83cc7e27c5cb2ac64dc7e111e3c85ca0e6bd4f685e5ddd428e028d192142ccee3f0c8337bdf43ce4b62704aa53c703ec334fb56ffdfb81d7d4419535d17e5fcc0e6f558ad82149c591fe0357da15660f61544b4041128218b6de2b75d3801510669a3977e2983bcaf957ee2942e504c29890a81542ea208e1cec","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 31","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002913986734218879d5a676e906d60725dd48becb9fb270dffe982b44c0e20bb46cdc8032a9c81c0e39cf4468a933824738f9185fababe4814112e3b3ca47bc1cdebdfb6b37c353d91701b4c921de7f598ae476ef50cb15dcc2c3bb7b7df9c9a4a70882c7ff30d528679fef4d85163c6a9712e5a179217fa516ca81841a687b2f1ae0ed8d591571309ae641dee6a026b70cd90f2cb14351f72c3559d1673bba036e8b64ccc790ce36aa2313226f0bfe11757f3dbdaf2edb4347e84be6cd3a09f11334dbd1ac6efaff0c9619265339ea04f7fb3ed0d031bc941060df534c8b31e79f74fcb3aa5b58588f8e4302db65690c14992a43e87ea44a6aee23ad63391e6fe6de8c2cbe9f6f8caac85d0aae47aacc1cdb2c305c66210530ecb16e5e78f48ed3cd2fa8f69bddce67d163bae5cced89a3283c18527983d5255896adfbe6d622c94b3b32a1c51538283a19cc9739b8419f663d0064d01d0dcd1c7651a29e5212ac672d9d77ea1c243501723afabadd1c8867fc91396c851c91a5ad0c04d7087e619624257fd3788ddd2a3e05eb80c27b3cba925bd3620c9bba9dc31dc39917f3b3c9ca23036a1b9d02ece4379548819a749037a27d37f1a706d23b9b69fb32757ceedfe854df2c218422a4de7be8b2e365aa8e8a1b799d5d95d40dc5ce1d3b10d8acd824a39e789e0f4f539a461045150e732dba2a44dd1ac83b04a2fbaaf23ec812ecd25b61d2b6b2ef8282f0c6df831fe0af19b77d4dba42d4886275b0be42f73cc8d9ba99c3bd76689ea372dfe6a5e30f3911f818cf5c2daae4e58073e5d8e83c559b9132ea74c64fcde4c70badc1c14d1eecfb75f06191dcf4abba5da00e3286abeea1aca746e0ac4b4f3e790c2ecd8694d24dcd5b48b8300a89db5c26c4f9082b4a9f374dc4a8c30c84d599668bde7080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381092c7504e654e94f1301733554cae3b351480ae99a556266091aa6a94538c28bebb58da27fc659f15e4eb9a756f986d08b186081c5e40769a82bec41517feceea8a06ee40fa1aa6604cfe55e025e68eea241994ec313fd83b56095f459e0bd2b8fd236b2ea50557550ff06fc5489248361b0edce30f762b0a0dd137b6f963aabddf69549992db0fad74b0e28a19f85c59be3266c76eefe9855ee54993c4ca06092185a4db5a57d29bf97b811e6b52e3c6bc5f1a5a906178c14caf632a6b5b4965a886a09b63051f9da2f49deaad93fb7c3d75f77725e049a95078e4c2c925f8d3765a9c009704704a9f27969e5c6635a081544f99884b345b5aae39975a834bc9743eec73eb5625a9e92648d96631569ac586852bcd8ca9c404365ef725594d77a8896600d46b40da2cce7951dc4008de7a0594b6090108ed5b9c79979f46f8ae6082aba5d2d347e229933c89883afd83f3589b03995d6a9931553189853c6b3200f8a2ac49cb93605e133d8b0510c1ae9a806bc09dc5fa291d2931b1ec2bb668ffe3a6c34a2ec89b34c46f3a1688aec80590308088e5653e9112b4364b16e2e4a06b9641d15f5d9c1e5a2999e9a245a3198d44a1483453f9be87eb148268821d9a760c1e7d9ed7f2fca655b16084949ec76629ad8e9015d7b56b25b32b86c0396c5da11bd6cd92adb55df8f0dd1a58cdbeb58320d71dca512994d83a138691e171ae0144324ce74029074dd1d0e8f5a3020ea0c00111c6b6ac3ae284d7a1ff1e25a7f243c4981174bc5027a3d582ea399adbdcaa879862f47452d1ae3c3dd6056475ac929eb5e5611e7600d75acc119f0d067cd476834b2859a959cc4211a312d4561d2b15529ab4894558d44f22768b05ee4164c62c70a36b1d4612eed6b8959a54bdddf868a6131955138ad29f932cbec17b74d3e779122501d541cc0418b0485da1307f2de748c582641faab6929394fc28d2d132b2a1fc54d4ce3a7ca1381e1c7942bdd4757b9a0f6165e26a9a9d4ec587e1ea40ce2e8b982ae6025afa147ddeb4619c507a9ec805074e4089d7203c5fcaf450e01a27bb21a3e8c8273a5caedd7435066c5b919df6766be779fc54712ec725107267a382545e08a0e6a079c6d11a50dec70b24c45d6503d6bc13947bd6a3239a6112b210a4994453cc501535c20a908c78f0b247139a92533e20f7cfeabcb0d13173fca1c7b7683f59762d8e08ec182b5a5ef40686e8774918cc0ffdf8a3d716111ec69cb2ce623774aaae70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004417ff38725f35312d75e58845fbc33e112dd95d5c1cf78119cb413ac839377c7051bf5f17add1484f5ee12f42b0587ab41df487ba5e4d8836777b614a9931a5fefdc4ac451662b342d675c940061c4ff01f747b69cff585fc5317636e2a830140c0007f73c76fcab96195c86db98e5e65c733825db0325407e5bb059490f2e9133f9b4aa328976256eaaed2fbc59d00288d4830d99731a3aef36e5bf5239f2899c500f942b80b00c3b33307450ff0c105bedb7df84231c5d24c3c3475ae2f46336582de93aadbfd385c824f21362c19b1c6a75f56b69297fb3084b6164204e2348cb1d7cd3ab494bfa7ec8fe346251c874085f803bd7f4dde1995f0d3d17033c461d06b49ecceee0d5312c3a435af5bec9808acc524599668aacd95ecea7ef07c4ca3fab1cf964fdba987c345046e6507ac3d372bf07d72cab816ba627c2bd452ab8dc3044a7f0a01d8c0ea47904a5dd66c6b7ef9130d628a4f2cea5a0d05aeab7daf2729c1041fbdb3c2d17bd66ae293c03e77a0837419471c29691edfb20cf69bc6260975089aa437628f140a44fa2e2967357ac1bf1345e4208c33cffede6cd634b371e7745143ff848f77e5130d1e0f51868585509f9cd3b906ee0a5072ca2e908d6765c74d9b5c35b6ba784a3ea59d808acbb1c24d6c088ca6c9e17bceb18337a4da0c1daeb5d51efb35712a475d6c5a2ea51e93fd79f7deb127f3418f354df06489e10b42bc1f20651660caea17f67f306f48e15db7e67a1b56578ba7be6c229fed9567e128d48551e6eefa17af5b95a716555571f44fbc41ab29208db7c1846e130866d5c9be6f73e601c55610dfd0f67d98933d252059daa1dec20ae0e5bed6568a6322322d8a40e6835fa66e317733e1b465434532eea8fa76886b600e06efc1da41f8dcec0a5e8ba8419f0b7879cc0a93bd14d99608b5bea931d8971da8d2d89053e1de40209e257e741bef48c17fa15467f1312a368d4a061bfc76c2b7bbd900b4a34da51b7cb5bd6e2fb08806a53c0d60273167d822fb6982785f2c3b0ec7d893b615724d0193928d0ea8ea2a1dec5abdcaa904c754cb7747449e87221b3d86bd5df26e11da753e768a8b481c306e485ec91074377dfc68be74a444906e420c2d8bccd84be13aa5ccd11115b669c89e9c0ce374bc4059c696e5f8344fee467ac8c8ade37daf614992914c763d971327b60946943847fb6b82672cc376b780953b6f4433df69ac61e110fbf1a35f6272561193d8652ebce3291333fdd4d84b9cfbc60a57e1f8b817e84ea15d440d4a4b4f7e19c08ddfc5949fe8cbddcd0296a62f12f53d48b1288b80e24c756fc38e2fae9c7a3315d1c6da42ae838afbbf5569f633a68289eb7073babcb210f4e08856fa65057bfabc70ad3b58c2c870dfb5e1b0d11b6fa6d5bbb68285d8f9c21bd89669781c9f4dc32eb1ef58b80b1d371334d36fa66a2b3dd4b3e4dedba7aa9fb7e0245f5fdbb66cda653c5232a131ec1f0c21db1c47b990a64a24dc8c4da951f419f57c03ff506e0147c22e9946100000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 32","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028c39d7986b401570e9f4bb9eec15430f66acef2c75e41dba700df6d2d192757696589b40df7939164d6f38fce5b3ac4af3b167691ead5efe7d53d0f5acebe4b5255069cbdb094a8841f890f7fb87fa80b7922be2bb9261ab0cbb9a4832adc2030221c7fdd1c1de61b47ecd2ae12ce354d06e14119b45eeeff5cf10593f52b108bc7a3e28c7495149665286d3d9ebb55111a24c49ec54ce3d09ae2cf35bac2733b2e5f3f0540b961e49b4cc4e928dae6ba0ae2ec944be7fb340d1561358c1331174e75f6e57a42bd48a255deedc2f6f34babc942e58a8230491242a92e7a4d82547be3a9b35559d9a4fbc9aa5ab73126c2986a6ecfc402252888e6f0f40813b7cd70dfe90f3ebbb55423ac1957d442464379fc9b576245fdf8bfc1a502c08c60674869df4c9fb82d76524db883a3672de91cb3f520bf2a1bf8ad8907306b2df7c100b7d30424f536558b4566b68f430e61b58430336d8a1694c5e0549b2c2b11ef83a19c053610d443976c34e649fb2424715fb628b95d7307bc38092a1f23590d8290d0abb8b2b76f9cee894de62d0df51e0bb53a599d7578be97f92a71b9928dad72e6ccaa37f48ab64baa971b93a6f341a4edb96f730e6b97c0e3220c9e1a5882742df32328d89c346107ac284cab77f6ed205e493cce399f9e3a0dbf84bc13d4689f6e668f051fdec8988926fa69ca4f1cbc3114e441119b4d3b7899aa1a5c429f91a168e25c569672956990ce441c9cacd47903c7b94c8e2370a76633cdf313d63e17c21cc948a22c4a1aa7a091f9145e5788b8b9cadf0aaa4ad64763cc4b9d040ac888b9ba6c1306fba7eb979e2689467d2bf23a987fa1ddecf2c934f8c6db7c9222d2b52a834d4680ad7f2c2669434b2a17573dba8576da649578b2c62c482248b3f1fa8485855d2c6800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109399153e3f95c2d61911e5918ca17977aaac8c51b0e03ee26c80466d0b1a021f425a281acea56322cdfda82cc0f8b31e20094fc0194ba09fe849dad90f5df94183c65f18e2758297a6d7481008892def78232057320c264d1475b4680002ab49b1c9d27de9164aa49fe9dc5ed67db62b8832a448a079450aa163ef495175a19d56fa5416f63a97992c85e215b38c5115585d2b27fd0a8f874ed000904e573dadd18a55e45f307c1b47a364522f4e19236759ae2ce2672741eeb11e49a6a2af119c098c707b89db786f729d23328eeb06fe24c754ad91459d9dbb844109aa8dc159eed5f22b16bafa53d906ac9a6676c61df402c09b0a6ceef27d028b2029a6a9062ddb05b45a6559909c260322ac96de0213fe26139190f92afed3663cd80470c6027f8b322efba6096fa25aaf46b4225998a470e548652db19e6b5a14e9555edd823761a24d055adf10d5dff930fd5a302d4e2d9cf2987056091e6ed0fc89d11bc688406a04d7c988386878509cac21338a9043d9122d7cd8c8688ca8f3b979a594eddf911860d552e01739619aa0b1795fa94f897e064224bf442d63ab17d6e1ab811bbb368c7fae6079930bdcbe62d2fc104b0c687fccbef3a9459776554a07f54b1372b82575a8e5710d8984bac0654250b544214fa37e8f5cefb6aacb276f08aad92ae08716198b725e2c9f62a834a7be6c0223009185c9001991061ada756f8c502c6361fc5daa1d34d158dedfd823b084f9fde329297ed0a61e5a58b852d1467628b37838949597e29c7468a1c5d889113d2257702c0ad1907e8d5b83446d3966313923552c36c496f0f8c2226de0c148bf02029e4cff0b29842f666cf14062a40997aa2f624b4574b006c284a56ede8876b5a123ec56385024db86d205335dec40a7456d39b9269b629cf9304a2c13146c119ff69318c2e7217f368192beab745e581f893c56170ca1f94228d2a00e401131edc89ca3bab5e1f198e768c0636b4164d38bbdecba120ce75c20aee452c8ff7cb82b89e0c07aafae327710584a61e6d7705d4e739aa444b029ea4aa17d3ba90b4e77aa60bbc73d1d286f61a93b260281af16bce4376b9e126e1b28d84e0d502420e6c5ef44a0d49239d8d7c56ec00bf3db5620613978752891b90b0ac786d74f5975964ab9745982496178164e65cc8989f7d5f853360c45a8f5a847f943314cc21700be8c543641031b278f5e91e01d49f05e2d29d9a5ece306d40e51e30a2b9ac22a1a0c538f76fa4ea000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000462789518ee21dc99cac94dd5298b2f3eb8f6ab8d0705d24d9aa3012f217464e7f203e08e5cea9e44f54a6f73e88d81592826e243b7f0b2a1b3a06e5afde23a2985183a0e430e01c3fa90e9f1db7e69dd8e7dc6fb802933e04a18834c091ecd46f0dd423f532668cee8a12a06bbc7e5ff3b9488b8f4a87a92bb8d6f313269ad95c574245e06563bb58bff6169b8f4c333033bc128b91cb81dd41b831df5103b295f744ede95fc3a0c72f1134a9321836afcfd563192c343040b943f69c0e98e8d740c06ccf840cbfc6bf777c9561065916f13d116d758a151e8ff4c355363aae8e4f49d2a2e062a2bb213aff25662d95549b4b025e70aa3363b50d25af84a3e5b0ffa598ce074733ad191c86c351592299c26c0a4933573ef436b73dfd0c4eacf93d361afe5f824b91bc178ee8381b9efd52302ab8cad6c08c7e090393b9b8abc78af374fac6e60bd104baaba524e68d75a759b94176105a9cff2e5b9c3984ff61c5afbf22b8e1b9e4f9bdffec0b19c2a5c8db3b8b2c02115d101805c1bd6652f738f02600e38998ca41ba8955094fad5bdc34133d4b523ede66cf483f1cd5acd9efaa69703807410939974d6dc033bc696541357da9881a4fd1385671b6e4bb889c68b544175c1e2ec1395dff4cc87e037087c615caf40804d5f44a2de301961a59818173730a45cf4c2df172614aff7199a40c9ffb9957242a89ff86b36a4f4d60f15db569c2fefaf677b35fe5f12ad5a323397714286e338ff6b9080fca50b657db477a52a93b243bf28ce2743794c361f443ad81ebaaeab2b237ebbc572d8586c3eab1f42baec1c985d28bc58b296a11d96a04b0e1f7f6790b92e450248804f3f62b5865941bfd444a910f31e1d6b79d8906e7e9828618f960ec14124fbeed28e1f58a8bc9d31773442fedc5a220f3912d0b41267d427c0c15bb76f9200c54b5f050307e13f1eb3de92b864c994a3df4cebd1bca634710fa342e23d7c8a5bac1b58aa321e215e4418428206f05232e2bcd1b5ee1bb7e34e7d4c93088991ee9dd643fd08b0185a2f0aeffb0ef0eea3acb4ce234bd5479a4f4296001305826f23083cc9dc99011864f250e77e42a0de26ab09ff6e3f32552f6f913256729b357cbf5dfc825e91bb5d3fac1f729803d431d339955960ead69b1e54536cfd774341cdfde1d1f527da4e738b2e292bdc884687d1016dc193edf34a37d284d026d33698295e864196e0bf16fa83a35f65ff2b38b7030e9e63eaaf594f272e07941313d538546bc84671739af822391ca4dbe6a579a81f45ff51fa5b7ef49beee7beba4ae07452c13366668f02752923ea3653043b26c883799fe6352f95144283d946ca87143b74c8a009c024d073baab9bc4da6c87d35fffd753e1eec7f01944639e566fe17a6f715f4197d1cba58d3d153bda37d7d2d5e19620ff0842527d109333fa2ba8bfc491689f4551bee6c9d13bb9e69ee4f44b782bb05d1e48d293bc15b9fc706d52b021c7159ff7df80e55627dd7555795f1fc616830a4ba2c02fe1a19dabe088e460bf3c5a88313c443179c593458467faa468791ca74e9b1e759847b6939f000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 33","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000291397d9d0f927817bec6bc25f3b047328080413df9bd8c2e1e4c6fad97f7a8e4e4e12f51ffcbb5449615d0c4bc714d0291b6a7276d51fd54c89b85199abaef153f62dc493b04561ca05c7212f656cf30c546ce8bf1a32a6ae9bd9eba3dbe74bbfcec5c60cc339e4e5504c511a835682c55be64728da143a4b5d7c7563ce1bb779847d5981af5291b77dac7a59471baaa350a5493a8d6e62f51266912449160c6e2649f2abe6d166c1a14cf816387aff2b4052e2012dc7b696fc7c831143351ebc6f85d5d32493d515a998d51cf9d51d5ee6d035da199e51e73c927eecb17e2cb1aca95dd23a2966acab882e170ec8709a48d45cfaea9a9b04119be742fbc7250d913f9021511b35908dce1eb69910c354fa4b6a136bd4fd13e76f6500d5e74ad1ff8cea52412b7e7f0a36ad04e0258f2482baa54c3135560947d519b49ef0b3cb78f417bd9a47a04d1c517e8db15b4d77cd2fae5f10c1d7c920b4f6d23ca12f30b9e50272f873bc8736408d6249b99230dad2d386449428ee908dc645addb60d37f04eb6c57a77bd607af1f157399c39de93e570ad0c03376ee34eb29cad333105864ece4c5e8b2447fa52f667046650af0cd9dac46505569487113f2e5209a8514e34c1c137752cc383e8d6e81957a541d3789ba52ce91b692b4081bf8ab4652351758ade2f1a90aca6f3595f3777a66aaf0f8256222f7c23c4d128c829863ce83dd5b67fe93b0e732311d566d3adb33e844497af2214b37db584ab22cef321119cead700639cda866501d431083a3f1848cdf9bb4a1ecf06289f3bd4b924086e306d240624868ea5e0cd25298421689a29b168bcc29fbcb5ef5194cb193d7ce00cae659587c19b0d0dbad5414ce4395449b121c69c9658278d036edace54dc7188df236a3dcbcd0443b0b2d9f5ff464d10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a84d8d076d428ab2e474b3a057fe55827fa9e56c0402a6656a184cd8253ad8e07449f37eb6f8a3ad240079faf0c16346c2a66556f44aa6216d6548b12710199a1cccd446995671c1fa6271e61b9138d50a849e347d6e5cb2b69c09026e6bf1beaa5eb374db774e89cbb6ce5a62479f676775257658e19f6e765115965f71a059b6115c26384a0e7164bd18dd0e099c52c8aaf9547d4bb4b7c8f0225c3fd558ac00bfa4ed5623499629dade1281a392268caf7911cd0d93fe36675062292389c1c0fdcc6cbd54cca799190235e23957e9cae462f9e161b1a9a45c95930ba91417bad64db236c71b0e6c5d3993aa893af9e1a94b211db6a6a8c39edf1a10f45317e767fc423ee9094c812661711c2a3e9370817c99f644ca4b0ed2e36a6c235a968cd9abb6ac7186d60fc674a47b1429b6682957ec0d3dc1f8b6423e4986fe29c45e2505edf9949189cd63ac7943bfc13d0925947b2457752714c8747f253e6dbe9cd4630c5095e6a9e2a7072b376c0f65705dcb74d56bdb9c64b150e26923c0035da2c996879e2b5e7dee2ee381da452890642bd7ef914cf8a6744a5b551f56d37212d3291e2a66c7471fce1fbdceb4e3538f067c3806bad5de04f801f206257b01f02eba2b9962205da334d2934749b595b29454500870a4804c17965601c1f9f6d77e02645b0138c1782646b988b3cffd2fa2a7b3c261500b71999a912d52b02052b81e0d419ef6abdaee273f8fd2fef41149906fead6814994408572bebbc3e26a06de011a5611dab53606362729925cf25c803a22d5317ab667f56d684aa01511bbe2e7a43cf2f2ca443f7298a3236d9e485a3cca21aacad5378504f671d78a57b1f1d112a39521984c89298d569379f9b829ca193f6e8859e6e10459566854f0699c23c5e8d2f04f5f59e40d0949585a3e82f2291f83392809eae2594244b4185ad1c0a5947db11960aa57503c34e0da565a9f2bea8613454f8133352f651ba1bf7748a741601bc76739c522e6607fa869b73bd2cc93a911b702a6e21fba80c1f07b059624613d98e24b330ba9afea718f9fa2564079679620b744af23a0e13739641eb884a0fe4909defb712b731d14cb64624967bac9c5429566099c5d0376f8d1a0307a3524c5a1a960b4877549e8ba1a21374242c0b7ae81720280d262729ccdf15eac7f499209a197cf97b4a082918c1a9180ec1b52a7a57738088118d10b9b6cc6e1288bccc166f110851e6a138658d3f3ce88cba001f931f4817f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000483a4117808d9d05b702483924e99623e778e7a3b7623739ab7ac488ed93e711ebddec383bfb7e06086fd0c374f4668ab744ad99b8af1c75309b60f55dc03ff7be6f23187ffd5cb224068568ce2d06abe441557b04a5a0c2858c416f6f7aa89a96adfc2afc54e0f31416ceed005b7b140b342652dac7bf401fed4d94d475784936fceb4b4f334bb14ba55b1ea9a36e2b0591287eaf4aced997162691a96e7f59853e609eca9a225f615a49a12763d80b5dfe6f8638923c39bd652936b19b944d5116f790e866a61947eb60cd1f3a1f319710d0f40e487efbef51fb4d00f5dbb94810128215f72b1aedd74a1b1d237088de3098417714eeb67d6a3e6bb647b6b0ac6d0ba3089d4cf6252b69c414e2bd6614429b6fceabeba50a4b53c7394652acf7dd9403ae14436ed5fd4d1c9e238a8399a763806fef5c3742c55b7159ebf5a13b271428f91229c191d617808a26af9190f9d445bfd3b273702bc3e7f610854c8e86066be7757960a880cb6727cef19dc7b464c464a7dac9ae85b799747b8488a4123b6bc7f0f7c2a8e53fd4f8687075b4e25660f5107acf22ca688057dae0496ff15a3eb9379a9f6e22fa43c932f137e389478c05db86060686afeafbcb9ed79ae194c4146a48ce5e07eaf585279313851cb864a50075ae46c1aab3b3cb920dee2652f5afa0138051c7c980946e8d5e18c16789cd184dc5598f65875ef43418dd56e11defb5a4a6afbce041bb292e0e2ec563296ba4ea6cbfdcca32a18c8aa395515a83d0fb7819413e5ae056ff0ec2f63f1d52a8be0b334a628d00995bec7e46a34bcd2dca0e9c5a88e0fc8c43843d6ae074c699276293fd8db2be48885155688428c2f5a6c6c91bd4a03cde2126205f9ebafe319d1b4f80277fe99211a09628ad840046eb9aa568ec71252ce9f69827b677d9c0d99546df5a48a8d253ac0036ddaf4d045a70f94ec54bf5f06296b2c2617f2b0ec0b8374dd28de269faf739b1e55ae1846f548fb6c0403c5ecee3cf9d1927e317f0d07e11aeba01c240fe17c6660f7cb32305af1eb6de4312fdea6990da4e9135dbc0b88ad0ae0847e1576f3c2711b785b846c7a4b823688e4218596caed583a90dc46bb9b27e00e4c1110b65f77e602f043a8441563667691c07162e52a53cd76e2d74dcaaa2983bf2e8f02cc30b05bd4f9ac731931c59f9ebc038fafb09fbc886f4c4191352206bb49adaef9d74bd08a5b780ff0fa301343f5ea81d36912eccb0ff24bbf0be6a8283ebdeca79cfb22639da38c9c639c4bd66fe5a75f0414fcc1455702856e6fc58344bf02998e17e967183ae920b7e04f58aa09145d6da79b65efcd18ec55bb9cfd53914f80d73c2b08bb754ac63e4c82d44b72376a544d97394b7c99678758b15cb94e71f9fccf674b29ed5afdce452959be5af510d57f9e5395a576eaa1fa7ba9aa4122a779727071fa485c005b447760410dee20b7c2299b4a0d5d9e5e4e038a19c87806c3fb875ea5bd7f47d034d7d5fec4bf132b04e47574172d392ea7b371516190ab81c67b45fef6332848a51b6c7dba90c410a44e9a88ac082fe296a7435e7d2ddfc645d5aebbc29620525757dad1b0222159d658c7225d02374ee6af479fcf1aa28cd91b0000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 34","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39a00fa134c1932aba2186fb7876bdac185b05223194b816efa21c281a18f17111008bb6d0789fd29ac3e423d9f6f9d9c5e82d739a7e74c723870330b8e618a479bba073708956346cf788af05305377afcedf5084aa3dadfc6114674c691ad5aa335ca6a156be1b5649295128d1f6352fa44e95e7b204866c861e3b06455a9fa6a654c9add67b2e39f0f8416eda9d538ffad2305ca506a4e0a328c57d8b8ddda55528ab936890355e1526fbb624a43eebb158f1a80d51d486a6f52673a4ca43b4099cddb58b23bdff17077be248d3747125288c8134884589dc15da229004d787f868a6975d2de3235fc3298f88cf7ca05cea7220cab3185ef6d1414091ebb68dc9498a9d9bdd7cb3938aa253ead21f851a8acbcee1f298ee1fb9abe2335e66df631c6ab5b764378fc14034dac8ad76a321b61256b60db4e1f8a3c3064b574ab171cc9af7738146bbfb3a997619093e320c5b5de6f1f9a7d116249386ea5d1a209f876fa7e7ec69b19aba120ccab424c708a7eb37575abfe141328d7d36532adbe0dee83516a27118772a3d8d9969c81394c5189807cd985ab4c4584c63e3ff4ef4e47acfba6046eb6ebdd3169836314c3ddd617061d6fe3d4094bbd8ea1773dfff679cf4edaa87432659fd175d2d77fdad9b56f9dbdb1d1abddb83e06513697309c5dece0e4ee69ec6a6468b4be0f38f1b21af5bf94d821c656dc45765ad7ba459c45d4a9a6419cc82037a83e18c14b5547e2c2409694f2b8a9fea5e67f9e87878ad3a1c6eaccd6df9f0d61cadd5e9b0422d7fd4d33809e1b3b3c4dcfabb7138c937fa1ab61d985f2c8d6dbf295f20434a6a761ade2eb8bb6dd4f8898d138d0b679d74a08277d9f76d7b7d4f5e82519c99956619bd9042ae9216291b785bdfc16f75891429f553db9650a713e80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381099ad9c55170eb9d1e9c0ee9af0c43955dabc117a797689e9d9a09dc200ca154e27d02afaf1982141dd69b1d467f0a4967f554215b2316826a4c59b193dd1098bf8089bba50084aa76011378af261a51f551ce4f0413ec7002d2efdda834f811cdaa8f6a1c9a04c4a31d30942cb5c965404162e22970d33d4d810e536febf89fcdbf1bf19a5c1a0a7ddb0bc060117a014830e8cf51197ba7dbee84628a030a4e51b91c94f1d1a60b625be9114547887e3b31a693b326e66a48a594f5411b7912e7db86a2992d959765ed2ffa04b463d207d9bb4a8a03f9e41ee868cc78c1e0daeb4f0e4de700525368e0f1f70c55e3124efd59579326124c7d018765fe31fd91043ee26f619cd4a78a49a11620bdaa2e93eb17b1395a559715a0468eb7e04afa76d44eb9d20cf982e4c8975cad6b960aa48597db69035a39b8e45e848b0091a0a75f89282da160d7888a3dded852a912c4892e5fa4511303120538a31f53bfa76e7cf4552f35b6b8c8079f4d17611dbe205aed729b0510042596fb3f3df250f0e48e98a9e6b330d5652fded709804b3e5a2ab21501912ba4e6a695cb9c3d81121615eca9aa0f8465b2af1b167c909a540a1778b704baf685efa42d7574a91c22f9b36408739f0f430b491f3a27d1545fc6c861ddd973aeb2c9b97740a8169ec7a91f4bbd35ec0ddaacd0f19465d366888a5b88a51bd6e64e3049ca37e93e2b480986a6156d14e3093ec4670edb9ab932d0534e1327017855639eeef5ae2468a6481d8d29801ce7ee22968375bc29409e0b3778bfc14ed3717f8df3f6ec0c00153e0fdb6e884611819ffa8ea68a9a9cb0fa23c74dbefdbf48f441f120442b3b5721a512c476e2871e65926d82f6346aa2727ade2b746386a0d86a376482d7a3e4de202e6a423e6d1d9a12060e4515875568c2ea8e31e82557cf2257de42492f89c2870a3d49c36f0b926d6c72d51f5d3bf23f867c468d6a08750a942a8b95f9ac745ea8265bd158555c8ad345e51afa3aa0ea10ce716535c312594efb83eb6ba4af59771024645d74c90906281bf0626a52db14c6b3b42215f0c884e79280aae4a640e21c7264b591e4a78dc49bab130ea64c9d82d3e7d68940527b30032d05b51df0ebec18f1aea517eb32dd0e3e9698a7eb57565cbce72669582c4768cd6544dd7da876ec9998e0609fd1c65bdc0dd0a9717f719754cf4dfabf71b399a5ab8c99f48da50f1230bb547fe830abde7634f789590a74239bcacefa11fd7258ca5c5c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004a4e82f5acc7c1a326d430475357629d568ea3d0dbe131114781d5bf8daa32fde9f3cecd288acd14445678c5ea6d3afafce48ea3957a6af8d8f23f78d84130fb6419f706eadd430cc85aff48283f15602265059abb075e011e3941834ebe70787cdd55f1e604c6b86f761d94c4f5e525791333df6d43869d6f36b212a8f35583d38a21d0947cbe26fbe6a36e189c73137f2f2d89f48566d04d2dd9125d2ea4e0b2a7e5c1e9d2ea036cfadcf7bb28f6df3b7d6395230c9d39d1e7558ea25340252708be23ec6c0c9a0946c5c5af0fe037c254d1a5b2b70b8f916cf37945bef76bdfdfb19a0daac5a83a6357e986b3155cff31024121634c3700ca99e5ecef1f2e411c6621fed6092c1ab59860271ac7f431e568075d59f71aa18096195f30bbeb1a6bac20e034f83c72be0536315879f1d1b7f31d38c12dd8e97819b4803d02becd436b61d1296ceb78ebf857e34087ec8ae8395269b5b0770b3423b39638910d2a3ddfec8502389fd8b5b09ffd10caad1a5c86e7e39629ab09a4abcdd00fbb9821f92e7dd24dda83d1d9762f52a89bed6c20648ea04fbad4233e5920ae83ffec28fdb5e432929a41db782b2cea8feb40cad0b27903050b650477e5d9443a536ecdfdac673952810596f1985427359d9e4797cabccd2fa0c0a2394d853b4e6f8e150b3e3ab5136cf476605ff5ffa9067c0fe58a143b50b18b09256657cf091132d449a6e7ee79aa870e9dbe46bf840edcb983f585ec2856c059808e72b8c901a25d6afd5372f168d533052a6d26418e035d87d0bf818adea19915047c8d824a425a8c7915756673e0f5fccb1b4fe7c1fdfce505f7e18f023fdd32a605906ec48e0fa755b6d87e47711e158d672c5fb4cd3b8d1d13fe9eece58453987cfcdd87b621b870f3aa27e73b6fb7fc0a6757893b978c63b7723c49d1005a1e5b1a4d60c4a2fef392df7ef97f149b499164455633fa485bdf92f804a47c8703d124522d73887a2b032f10f45343993ffb009d69e80fb54b6999a5bdb2760f8bcca648f3c52bfa1d887ae49862db4cbccc7213acbfdc48a57c3da1f1ebbea828182432aa1c593c3e5591c825e5706a5f9503311e91ec3d8f4a9554c3df915b5fbe0516a7a5597ecf8862a8df286ada96c90c9f2783f7f947a18ebbc64c1baf24b29f77521a9ebe09becffdb902efcd024046fd3e6182bf0c84bd3a0a5410eedbabfc60114e5db28b0943d79f58f766e2edb16759850d4cc3a9a57ae073cf6f3b24d36a4365e2bc64674259170b6d11dff63d0deed085b6321c45f218e09351aa0d4155189cc98de5627a03396a067ab3fea2c133062e3823fb1cafa5d592070c8e82abe812979dbdcb6d2e595f33830ad0e8e2f9e6cdc4d9c74b8026ead1815de36772769c4e00806f79950a40c979c14a4bdbfdb79df1de01fdfcaaebc93ddbad62ba166843a121d2b144559064e9de9e310dfc93d624c1061bad3195d6c9f46db64c65a31e90371f9b644e2a15e01c262395269a9ae83f50776f852903f86e5518bd008cf1b35e78f910d48c0b7bbaaad5dff2375c55d56b8f65b922229d5f494edccd2d676361619fedfe6bf0bfd7e4c77fc459f181120c4430c409ba89d2e5a8c36cc6200497611d9d705da6ae1aca4e16b389d632a982e017e1dad95dffbc7a7d7191e7b8fa1c0ed00000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 35","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39b2b6104233bc4d6d8242f22e0af819b55d9a43f65f4cc9d1f84b23372792c8de51494f7d6e3230fb9c955aab192e0ccd57606b888a2def33ea8ecb10e1d55aca9a05b9f2b26c2aef9f2949df9e8df6d77d6664cf9772da6bec91687f7d9bdf4bb92e4f1d69dc61d2f2aadfcacb94a2a1aa305158cd1d5dced6dd6edec628d3f5bd5478132bb25325f4d6a4d4f26c8a0b5df798ab920c4e6a584c2102a5af405a8830f8f8234c4f3e887ce8ec7c5fd8e16cde4f53366f239b848ad2405285a37998a9e97096a59ea98fba610861a3729d3d3b859dd86d20aed7de1df6dbc52af712c911359182924e6ba9271a3d3e8d2b054327739abe9bb75ac5cc49e3a571b99837384e7e29ff52929a1f0f1a84b914cd83e726927a38c9b25bcee3c37d7f2eeb48cdf296363d9c60a52869eec732aa17f696f6d5d1b2c11be8f69916524eea72cc77ae4a71cbb76eed0dada9dc36b71942843a15280f0f68844f94fc6a629ce1e5730a596773220c7e498d94e57618ef6773516281f8e41016019e68668632283374586ed6023a6ba40855b0486f0af3a5ab286c81a28e18659cfbfc1165011d3797b92cc114cb4d6283d7e3618451b1247c99e10e7d2eeefc2707a497bf78132b8cba4ddbdcc14f31cd9271b4c1fdb4b315e8826f9b1c56ecc5c5a30e6ce90bdae15c07f77360404d7c11df219d315b41e6f87474dcb60e26390ef97417afe7367b239d697ced464b0c4f0baf6d3828f087056d2cec0f5599a0eea10af46acd0e4a97c74969691239ad6e732d6529f7f43a84ca9103ad8f2e38b40cd4911893094d9de38d4a32bbe5e86b7ea0cd25c72fdf05e3211a7adf8a3a81d8fff2e42a5bb639b03f83e90582aa782687f2c8ea73155932dffd27f3918d15a7a50cdd3f760dbac55a8962969c5d660000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810918219f6b58dfa21c609e50305ed12f58581acd6dfe57f4287669474b435cfa9012a7fc19c9bfd73dd8909c1c91858095e39fb6c9a7f0e96c743a6f856e292d1e95e4168656ba23216f47cd450e28717c0754ab57735493b9cf867287a47efb6a166d8330e5f762104469552c30c01a8593fa6563596fad566945c465a11b7dc279f362159c758a76566b17fd491c10a137ea5689d58ef39927cb85424dd8bd0c16a0b9b53b5bde864c6910495c53950f8178e0320bf2543d41b57b478c9ee8d83971c61120b8f3035cea799726d02a9d560808e6cba855e3014141a41512a8382ad07ef7e96b596cd65578a41dd0a57c96b8de5c321a04c1a6931880512dcea2e2c5e22222c1a3385d2f00e9288800584a912dcfc967c31a6bb61631810d4c05c173a4a9d4ee78ed58c687c1e653b0cec03e2fb05942ace0c1a24a8026c7d9226adb430da2738f85e51ae23eb776d818a646ac11742d3d47f1bc5bb5c0d74ba8c357ad03d5b16845584fd7e53e340387558c1654717491fa5c591024939484d837a7929c5994d78e797523f515a888138c07aaab6e920c7e4e0750cde4559d9cf51e57154d92e30761d7859179f957610ac8643439e45f137ab66dbe995f868c4f45742696a8ad3974ba5254a8dba2ccee71cbe664441c02b6511c3f85241d2870874e69313365dcc91724d5a455d2d78828bcf690e8cb4d0ae53b0088df642a59197687c38a57a654b567df80015ee6f7b5aaa627fc0543f22f8b10ce262635ecc24f7967b641ee8a4d9140b89716548a5977f1e48f461730bc931f9ad661806888e599d68778ba59871d09538275bb112aeebf9dc48ae3857f579272245dccef3c3533eab5e67db9e96a119c9c063d992acb8f49581c44c41ad702b356229c8bc6c0531f3abb81fa888e20327a0266947ab870c195db2c097a4234946c630984245845c80f6c6d5238b83aad14b6314776e149bf7c9221d2a7d0b5966c4f920ad3d355547bc3d54e2b09dc78867fcf55afa9d5910eafc77315494697065a679c9137f38db72cc0f2f4d14ded8926cd952fd65654f24ce0899abf3eb1f851d6c9c04fa4265bcf2e260845782a939f951c7c5ad99340204499fb2622cd003570545853572599c6fe11ed83c20e8ab48690ae072a76d7c89b475940d5720b8923e836b93d647bc7f38735862bc7ac3b9bc42054d46ca3a8302583ebcd3e029299f90f42bcae7559247285dc8051d3cb70ef3729505760361c751e5a40a167e3750000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004c5743e5d96b9b4c1469e7ad2b3703f711faf60ca335358ff3efc8fcff02cd020a443243b4169f9123351b6c36762b85be5e5eddf8d4b43d82caa615788406a31cdf4f7087d42db21ae48a069aa23a8f6d20a1c0762f973e526f011dec737e986cc324724bc5336d0362525757410e21046a12ac54f2237e68da036a5c1389e46a53ed8c21774906948d4c9e14f40519c54dbd02b7a4acaabd24ffd7f6ca4d6d582ef48940296d2893415e811fe7ef0801b35f1c594e6fea2c293869bbd45618b6f04fc26b55d55a0ae99445aea12f851b7e58a49cc6a0044f28e3eb838cfa6bac5df53b0db78be2ca2bea1bf2deffebd673a783c91a6c9ee710b12042ec2863a9b52eada5b0d32101bba8338f7c75cdae7b7fd6797b25f96abd53a24a7647a1c91610306ffc72a8da4d46b1778146a98bd59cea3173d41d5a53f9a7f9e282b5fda1afb062d8afb63cb19b0e76df782feb9f7fd50902133529cfdd7c51af297895ef6e1871afd4c3de93defa8fcf1fe67bd27b7eeb0cf37a6a8e09af1203922bd9b62672d4756519cd09dd9271ecd0285f92030a9fc81c09bf2fae86f5f50596c628e0be673571cbc2fd76c563e113004529b234fb50e9e3d6d1f814cb8e5b5cc3ea365d0bc7602b146cc0361397d9bee9246fba3a724c462e177d27836093ec009741abfa28379aebcf5ef09bbce00ce449fec3a3302fb9ad0f010ca338363539da545f159fbcd3d6a0482454023587a324f5132fb6f4ca602fab2cf6cd59104427264cc9ede8d10cd9dd7fa6133e65693dbf744443ae920994226e21d98634bc7f0710dbc37c18203efa5adb467b523322e21e4e686b6b85b00cb501ed84153baecd4d6cac9d1183e38b510f7b1dbbe5995bcb717529b83fbbe969dfd8de21183762fcded692b16502834fe8e7a7c46f84acdcd2c9975098cf0cde8ac0efafa449dc26840180dcd9353a2f1b06962677c808b07345e8abe95b8d24f21d751a4edcfa0e02ff077de64e6b992e8c8822682dcc7f03ca7582fe7c74e0a9822a02d888fdde1fc9e73c2ededdf32001e918771e5f511ef8f88ac19b76fac0c812f56938f814d712d99269d7802e47634e541b54e00f9eaf78a421506a88b4bf7332dfc7d79e8c41835031fb449507d19d5a8a512a5c527c95b6f21ee3e41fa43591dd9bd2e4293701bdafb624e0ea290da4b7a173003867c4cc3fd814e117b4eee283c58f5fb33d653e410f68c8962155b8c4fbc13bb750a0343737d1fab36ebc618a6a7c8e6f93855cb24937b01c438fa713d334df335d0745582f680627d8b94cbc25f0d12e3b1c27a3ed72e2558b800c19dc6b719b961e0fee43bfc34e999027ca1969aba4c45fdab9af01b955e948de951f5a1088beda43ac930fe99d8cbb3473475c444f43e928e1a44966265b38fadf9b1183700a95a81f85ea43e5c61dd9b2d67701c95583e8e3f15083717e1722d764b6e624505347c30e5e70163ed9a046c504ff534956e911294d2b9097bbeef8740377ef0d6c4cc8086422902bf63556ce6da8e33e68fcfb42707c00693a995d17680b76293194db217eb5a928303dcf1814e4a881b057baf2553ac4faac8e4bf23fd4074154cd4ae189ff7e204eedb8edd594cdc21b5b7d73a712b511d068f4d217c0f91f9d84c524d973d67aa741eb13fe922afabf79cd2396181143783030fd2d0cfefc877934d8037a4c32ae8e15b50a6fa4269000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 36","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028c3942cd9f37e96c32f0209a80ad3ff7bac01256d63c1e3b37bb8977ed51d0a1e68911771b6f1a95bfc9117f79373a64cfd2ce447184388b49edaa01c7abe811284a45aec212e44f71435210270eb8c24070bcc4d2e71069f3f4d8828d6bf5b148e43a0e9bc82171d36c50b122f2c61f598258f3fe091e36bed0c7f2688a299b681c7e2e6ef7dbf5d0b9993714b7fcb0a52613ada668b3d2d9ac723330ed586c1402e59c330cdf09a4849802390238cc3ed9137d443edeb19f3c645145cfac27a1eac2e118022aefc9e09e4207d0fe3313157779ba54fd9aa8b7a4f9ef570f1a52cb968c876948546a94a68df7687892132fc4d5455a3c8b25bd6d3d1afc7d7be54274dd050088d31345254d71757bc2f9f341365e7ad37c2036eb83d9c729290406b98763a88c8644e4987d02cd5e99bbbc6c26cce95db6e7f2fd137322efe74160cef6b05e94cd268aa98936d13a5ea00a1aa97833fdcfd726ce94a7b40a441a1ec1b6356be2a7b6e2299e853f4902c4c15966d322e1d427cbf133d3a9a44d2d9a691a1dccfaf58044bf3b1803eb4daf3db1992a3adda81053f5c9e5edb313e3cd90f07c2d5f785d410244e12ca1bb729d891ca3c67d3cf3edb64530ad584425f69b7eb905c2f320a4473f3cce8f879a33bdb4a5894447779a7d35530c337bd7d29ba88ea51f78e158c504d72ab26d347b3cddfd215fdcca482c544d66e7e10b25073d93455906c70ad738487e890c71b70eb36b4f22130b1118165f4c1885334e6436defe77f3f4d460b41fa889039ef8506d4a93f3ac39f1eea563cb3ac294091a12c5cff83d4afdab670e85c7149b7db12d24ce6264e67c6a4a7f7a82c231338dd5d57c42bd54475fb7a698ccf8fd8fb73d9b884460680cb750e34f13c7552c6924f2d6ddb5b417defe1a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381092cfabf566f8a956c0c7a080fdb186faab74a1654a537684bc23c86349afceaa31da9b3650c3d30e9a83059fd578a13d1ea15e5a27ba2276bab065d68fc8ea67bba7cb6255ca098c5bfc1806b043f1e68579cead41efa3732758a1e480dae94aa2d2424f58b89e3848aafb1bd1b510bf94aeec48787273db94dfdb655495a209898204ed7cc03b64ac5372617aec633fa0308615eb5abf31a4d750f38f7693de3f41d545ca116afb532320af6a69c84bc8d8ee4f89b3984565e7b1f0e661358829324a5559a3448268f297e0d40bf253c57ed7164581277617f8d54a6e63193cf598a90fb841348b1a439812fde084a4839576212f3444601f9b046b8bd9a3e69fb055c97b51021cc42f651c00a5369d93240cc25c34451b6a739f426778e89635e5876109d2d3ec2794071eb910e1062c030ae864544f4640de7d843a046d29bea0dbd1575d8bf43ad15ccd6c2b8cced02d64f96d5c4fb07deff2424829985fd6f12181031b475447438cb161b0c3fd034ae7e35e5c6b9f828577ce6b9ab13d27b2e6c8f6783e69b443275770b52fc416aa140956056942ce48b38d82025705c024ad24d43a209866b253f71c87f828a93bc0840ced05a479424d5ce84da043727e451c25168ea97b8a76826af5252116bea2a623448323025a19915785c8126d5eb4460f12a7b44022816394e643483c874bae2918356bc8b65b7b40e95d43745bb73a0e0b522a6ffb8a321913ec42c67884d7b3994b673e78a11b86885542d9d4f93f1235219ab2c4cea0e54825c8e49de36a2c7ddb9989678b45058f9590c5cd20ccc7079856692f0ea377d743a93efde53036d40a9702d3a9926eb927e986084602185ea001493f08259f309701fe49014c59f977c3c8533ce1ec61b54153af302a510a18bb5f3041841b03522bccfe991403111505c89a574405449cdd3976ed0c5bb177539f40594851510493003bbbd94099040464a13a3ebaf40d6036e199d427185f2ad19fb642df23155ada17d8684d69ade145ea226c02100fc928db572f628698d4a0063c917170dee3afa2dd9d437c18d22e050d8bc759707581165a1c85f1657aa180b54c9176de0222096d4d4585faf2704df61e36c599b1160aa6943f9a6dd08f9635f3f96e48ed39b1a87aa641d8484e0622e4ca0036b47495181fdea69abd60250d21a04e7897a2902a3705bde5fb5fbf1879d1b5230a8350c6a585ed67b38db2c268fb9a0ab3a6b9d199431429a2bf18a76e9f50187c50000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004e63382e87ba70ea986a044b0cba2eafc3316c1ac95a5f16f6368c210dbeadfae6cf2382ddf5078ad594cde3bd1a837c517b1a20a2099d938df6aa02b6c0e62fe6147c904bcf3ede51ddda60de7887dfeb2866db402d23e5934a74c9ce4852d4b2f53cc9bcdda312964a548f6f7c8320af1d1bdba7fd32ec6c86bc3fcb4205ed3db092fdcad9ac4d2b8575883e13f69d8c16cb18d1b9284b31823ece917c905c5c8b9d180c1bd87975871014f773fb57d402b8fe16ee312692665824cf0bce4509326a31957319364cd421e9b21bbc1dff663ed850858a2450c2ffe64b65e009a3999ce4504ba5313ba0ee4a8843349c30fa6e59fd3aceca130a37c04f9b64722608768973996112684b64d0c87bf95e5dd60661935831a6a1a9575ebcb2f64a15296be788c775d80523d6bb4267d91b0c71ba5f90ddf1933de898e79fc7e39d0a3d146f185214468da50aeb47402ab542e52ceb768a70cb1f749e4164cf20e549b674ce965ffbb98d874d34b5b7851e575e6c1e4de9c170a10dab84940af055a951260b0119f5acba320b55cdce4f16346905a2073cd9fefba95734e4f4dfdb7a33f292d45698831f1d3e9fbf56d9692c14a8f9887265cbb4441ab331d977e3a68a1bc9f406ae0fb1c6e91205670641b9868e2a987baceee2364fdb089a63b53976d600bd7a8ae88a02872e46927269d281cefa385c98ccdfa6609394943fac32237368c6203aafabde072054ab5a14a91391d5a943f4ed4a4407f275ccfd15fd28f1ae0eb6edcc6612e3436572919e4dfb57c049bd77b344d8e04152863efd4fae8fe3a7230aeaaaf82870820085f4b3eb5215111b6b8952cf2ff468b3d10f3af849f16e190e9560f40b05e6e2204591b58a850e2710f7043aee2a44a6d4a108ceedeb2d216e51102dd08751925de6a7f67bca1980f0789b34e2f86729621f2285c5d3a036cd87c76102e9d607c37ccdac8062ceb961053f3195b5abd88bc64fc65f8be34166841683f1eed291938f75dfdb3af4fd2aa98ce95382acfb5d5dfe6ef243c8a0b19b80584fc0cd533e38bd485d1c52e0eb5bff90c0a947d9b9095ac1c0ce9754eabfc860990206b981235c7b612db61c9fdefc0f14dbf68a8a0ea4986cdc4aabad6c218559e11cceecd804eb98446fb33eae47c0388bd8972ddac02ce807b707d6d188cb31a1d76d44323e93dac4f8ecf77e7896c052ef16009ce4d1147df84fd5785d95d77310783f9aeff1dda693f4bed26457ed82a1cea19d9c4919257e3050b25a7d1ce7561740ddac3fd93a607c79875e050e40498bfbcca95bdb3d0fe639dc7cea80e3dab3ad73a4265f012451c1bcc2fda1e1aebb7fb18407f31e7496e2a18d2c686b47120688240a2fb134a3c314d4cb422811e850524684ec485e061f7365494a6403af170da461a3bc32ffaf9143d5e9b17b2285c56977aecaf880cdd34f26120dac4c950198233a50654efaca6ea97333d2bbc024a5e668821d20333df0b712510100aecab6b484ccb7814178f851a3e6ba0b76f16c4685d5ac8ba48558d382abecbdcf0b919c1acae46ebeb5011dd0b3c22b539810720cfbe4cbadb111e100c09c811e724a67c66a1b89eed1e7218861f55a4dc55e236c6e3521dcb374437a14e8000dbebf0f7f9bf409af952888675c11326d9e3e8a8828bf50caecff96075cf29446cada373529d310660cbd60c042c143e1736fe7afaf6fbe42791a8db01ec0475145257fe2df766d4ea972b14ae5110b8f8f42d659383e9bd760000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 37","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e398b05bdca0340fcae2a7281b0b9fde32a8081ff17bdbf172ca0431446e6d41affd805bc6b89af09ccd5aed8cd227ba62e9ebc7d57a2d6ec31b4f3cdfb491fd5979a90787a6ec1c7c0b5c715c843d40ddeb7dfe3b65fcc45d9d03296596af19aaa4095cdf5a5f3b3fe14323f39fcd2c96aa2d5ef1c5f33b51533283f8d61cb227d26b89e37741429e8f6ad85db6fc04e27287c1f0820df296cc587a1a3759d670d159bc520a4d22f5a239a75832f574e54bc0202e1d52a061c59e7fde916c94e86e01216d981828a8c84a557dc551163536c9c6e4ae0459cc8140991900be33bd74ba56ca48b02a0abf9073d84c127236bc93ebb6183fc662b38ff7f32548091de818667334cce59c4c020d3bd458b0ce9efa5c582218a7099553161ceb5452dce917a524ae509f6e64aa2b8370ba7068a49a4ee3c21428d2d2e3d14a979174e76ebc16876bb09c629c8ce50f7877be8465517b2dcf79def6ab74d963815cd2a19ebee64d07d5da3a152f9fb6bd7556a4ec5527346c229f4b84f9c12414e409e0674525d9e83131869e27a1bd2152894ef342b95e2769db169e2418cd639d6dea1a966d819ff25af5da02db2ff62f863e4b1047937cb5db28e9ee350dbe61503d9f0dbec6d4adacc89e664f70ebed2988a8c3684e4cc93a5b9166baffb6a75330442bbd24ffb42d3abd7fc93214b9bd90cea4a733cc202b9c17a86a799757a1236bb177ba4c9ea7b1e8fdf9e7df56e7bf688f365b26b81d174a6c5d99a6b9cbe0998a9ddf392af732da94a4a5faf508698ef5efa13b282bbd006d57ea1f93609cf3efd249d9bd5125ad02ad408ab4fc04918130b9fa3da5e78388eb948f2337e59aa36565548a0c8d67f8ad97c916c6d1f464cc130bc3955cc9c9305d1c688c912fbbc8131e6f599fcba25ba74a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109192d8df5c0202b46f9e839f684272fa51746f3106192755395cc1bfb7c5d384a3843cf71b27af4b12b5363b1cfb3e05c1704d524740f68c2812e9d9077d9a73addc7f4215fe2bef85256f0ad6ca1fe8d092e0b10bb61a153e02aed61769d49546a0c5c2c43b3bc58c7499d7342c0e9415c5ac7f6d12a8816fcaad3d453f7878c6f9b1b45579a9ca3e73f156fa50ac6b91450466659a5c6da070e7be05c5a4c29221375d4d26cc4d95858869bb6639c8ad00dc7b5031a433981ea8d42a33eeda9cbd6afb845b9284b79ae384cdc500585a9667e75e990ed21ec23990ac8d6ad14372d7ee5e0542f4dbcd4507febcf04062c7791db265e117b513247ba004c364b358dd5665936e4cec0fc0149ce524448c0bf08d88080eaac55521f7b1c541e91ecfea8e1cf1c57bc6267bbe438a03d0f691557d66bf92ecae1953c4e022d7aea08854ff8f9e348d405905c37a9f107cbb0700d55a55b0c71a1140675cc61771eacb8bc6046131dbe428110d5175451797ad50517912c89ab17e66e60bd384497939b896fdbad012a87dd94009b21b802b6ba6a2fc8662eacdda945cf48739e46f1859868b17a121068cf9f4b442447a5ac8712e8c8e6da6ef27a894fc21b2c999a99b70610edc294c8e7b44f8f6b6369b33932d2fd963aad2229e58f85657359a3039560512fb9a7c21f309a9f165da730b2485496cbc624915200c8cd2d4c58d509f2c6a0139cea6141fce21fab4cfe03e748c963c6ff8137093c4cf6ebd6fc91d454acd209d5938f8dd1978552e08e8b0a45c903424d795ab2819e410563397ac9a12c19761c7501ba0f537fa5a01bc7920893821558d15c100632e3bba9826898dc3f1b0e1d043e70a4176bc5fd461424f12ce124661ab084c0404d33a1969117454a140e5c48426ec60232e3e3cd66ec45b62b533a145d0e668f98274fc60cc12a23cf8b287d3aaf55638a356e06b266291d7b96085463364f5d97b69f5a7f1af662b22f22fc8aab716918351f0403a3c89b1a4cc7d4513df25a7769ed9ff68905bbe57d0f8cf2b0635c1a10518900cb1e8f17b4d539e894991c156b60af9a635454ee413992cf3b7924216297e301eda6444607ce32063794e18d2a8e9514578543939a15f3e5a46db9610a679850e51f3ff524666eeb396a4d7f81ddcbf366e86ca9da67aa2362dad5ad8a8352294610754e0d81462272f75bdeaa60e4bab1d2320d76ea01d31db40d18d8f41b94e2abccc6b24644fbb2b098849343cb00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000050767109894c579974373ca0054ed5f7c373b7aeb810721c3d9cefa02eb244ef6b17507300370adb24ae0173c6d114c51e05f822a770318033c082b6502f70012283eda2a9dc0a1381f145470e5d3729d201773d2aa63c18885a92c962bcd3628835391d70dc36273dfaa4966f65ad40eb51fb4b416a8d0b1ddf39cb932ec4503bea23e3d9d3b4501db426c6ad99c28d415fb565f62eb5c22bb043c8cafc42ebd1c7190dd32a5b14b571644471453740c081f3e3305f9ae70a5bd505874382ec0f6e2188563e763bb8d1bb8b16587ae25a6252f51e4ad02d0483c4a6e8aa2849c44629cf4b7c6dd6a5fecdab0f9b2f0b35e306c7532b64bd5a3ce67a0247d97024aafe5cbc13e375aa69b8287bba9ddc9aaac2bcf41a71e373ee36b13df9f829bbee8f48802dd9e03be42a5e290251bb130e0e2abcc4e096dd0f264e5d29f8c2388a0c3010e78f2a03f5ba1be13aa5e50f2ba67a031ce3f787754b8276ea1af62bc5fb4dd9a9b9bb84217a37eb9fc7aafb517337b30454200d6aae491e50d5007eac2150f60f640a5c4624ce6d8112119413731322bad9762bcf72349ee38e2a41102bc5461d72033072a90e82d105e6fcdaed9c223a4142cd55920196d7b1b9278c84b67a2e35bde3c9ceebb8e9007ba8758bd35c875dd5fa0a8fdaaaa9a09629b9df69afaab456e105dabf2ac5834b8d223b0a406e0d1295c876c447e8e09c93fb09ed1b3ef6e1f3b7fcb029f576a45a12620567e05f218bc3753109dd29ae0ade1370c0f871ab5ad8a9dbaa277fb869ee552e8733e73886d6dfeace6b35e481f37a516ebe191daa6f83e4ff453cf9cc9ddea8ee507af0e62ef3cb8c22949cb828e21c6aaf3fa9ac301e2257b0a054ff0a237f527d53eb757820af637ffc9f983a2b5aff0b4cc493e610314432c9c2f0ff73c4240d520d1d73721b429ce41807b7424b14f5eb1cd23d5562263fe1d58cb1d52e5175414800cb090242e240c3a7acad4c84dbd8abc2731fa2b1d9820da60fdb6baa7ea849b6a146e07af7fc201b3a98e5194bb5826945faca3690209e5726f070a71ee07ae76adb7e6199fccc81c8af7a463633a58873b4f7e65f522fda409979de41cf54f659e66cd5950a3a3e01570526c46417a00ec2e8821dc380abfa21384d141d259cbb9722f267e46272adc5cc4bce382b554226996f4a6a1605287276c18a48c8ff1a92ecd2815ca5452fd6157fc27532680022993535549bf9ab064052e6db4e9f83b5d0d885b94a90f59e67b9df0c321eb0f95ac07007e4ee33ba89aabeeeea01fd1172eca4e31fb02c507ffe43cd0d6c8570769a180e68a70bd344b4c992e7d3a6bfb96ac4d69c2d4f5efaca1d348dc1988de44b30da76babc307a88124f96f26737a85fe6047e7e485c7e4b6b99b575faedc9baca3e080e2b074cffce1f716c6a1d08234c45706d2883c6e5a001d02596cfe5b260de6134c75df3ac8bcf1919759e15576ca147cebe041d04e369bde70cc64157aeda311c8da520eae907c33e30dd89013e24b7b02e66c9f285bf7d5c3fd65bae24ab20d40addb451ab4bc4b9772d0b9039461bca8d3d2a4d71a2e6bfbe7f02325fd571fcae1fb47f855612f382188a5fa3d61c3e8e59ef016db0149c52e1c7dc84030e6c93c4f32da6ce5f3b8196affde834d2adc26cfa05940055401891519386bcd33d85584d74b2f16d8e19556c272aee8397a1741effc283dbad317740c1b67f8f4b7d2d1edd68d6615eac3f8e3cd26ac4f8058667fb388b19c654711b5b2eda75a9ab55174157cbe08c186a3d0963bb3011a9567bd499ad2a800000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 38","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39e1ca3e4dc881a5c1dd961672a5717a071606b2fe7d9b3039a9c09939881ef3a0b9697f9658cdc84786692967bc9e395b9463b813570b1177d49542e07088124fff7d66e856c3ae703a9ad7f546834d9de38bc556ef24fbb29cc10ee413e4d35cb40c0b0f5bc640e251978742785fcc61c225f04cea98b21f0a771160350927bdb3d926c44da84588662e0f53a2572d127419de643a36e80ac7bc665e632bddcd8f3ce5e4c0a3394c3d43a6eb4ff07871b88c5abd08ec4ba8f566d07bd2e5c351adf1a8a7151ee93e5eae6d07cbf3243acb5e6f84d3c752c3bfbf94273ad6d64f34e95036ba3740fee5b0b5773defc22b96e630612175c62e786a9bf8ee49492f8f8e0bf4f6ee4b7f174995580d29c69fc05dee9ed1d5c73450647cad2edcf9b41b5d5062ea54d8ad72a91d9c10b4f7365665da4fc692fd67ebb05317194d7523f7885aff5cf410e7b5d59022ae8d45078acb212cdd2aa35249c8f972d06218c952823371fc56ad943c5873b39ae291a977e10122fd8ad914db7460e934164ada467304f1f3ca582a260d4ebd3b480e20cbaebe99335af1d9a158cf9e5582e2403d788ccb6db44f65dc4d9cf68b3cb3c7cd66d3c11c50098e95d4debb5ac96a0490ff4a423908e6a38eaf6e0751ca185244cacb2e974e641d37b0fee591ffb5136f0759924dbe3f7901a6e7f0d06bd90f988e1bc8a6b24691948a7fd826b20dfcec54901cffd9e871be060590a2c56d7ce66236621935ba4bba88ccd5e0cb2a8ffb7b0cc9929fb250da56363a761dc98561ab54eaa159f8d649af7322796a2a676e0c52b8d7780e5e4ae1aa927fa46d36211f3b326ece21115971dee95850db4c68d752ad71560131edc66b18e3cbaf71f0d8fc353a3b53fe39fb7fdeb4e95f196d7270efe558528ca130a8ec000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381090eb6de01349bd88188fea4990cf05d39683af2cc47a28e5e85b5c36e47689d2ae60d686f01396ba958d729a2b7ab3f1408bc36ec98bf0455b86d0fb7d6d6ec8269c73011d1a25e65c1350d9924761d1cdb8683656d5151525f54cab04e0c87a0d6da945aafa025c72d336c80e1b62d85050ef7b43d2121746ecda8e086ee395484353da360a086d950c9a93b5f96c5535fcf9cb4be86655b486e0bc6cfd120942a703cb070c2ace1b9b6dec65d58197e7a38320e09beaf45f2103a1c053212f5b22fa25050aa8721a22a8635a8f8c74e6875357ebbdbcda19764a963cad92f0ba30a2570d0476239f5b6f2aeea5d6142c9a2d24d9393f16829bc50a65f7e68392e1efc2e942735f44cfb94354b219ac23f9d2463734c5d3e64fe46bb9a8eaeadfae698b4c49009766180ce49e76099f31964132b1ca59d70fdc6e102ac71fa692ca731ceb8d8335983674113083cedc9127ab5936dcb2db2ba05057b2ca4b9bac3847f5988164cfce5eb89a78174b07710ce506a521c16f4a0d94469f6102193a5407a72576aa4533f36a9458594a76908c2565e4ff72bc5deea7394057d0d35b0ea86cc5ccc26931fa3aabb615307740f65a1893381de1fc23d0d8b057de4d097a881833c85ab018c77565fd50c12cc350749266650acff866dedc72b3cbd071e9255a8c0ef680c4cf408f0ec497cec877ce52749aba8dc3ee021f86312ed8b200ac2d2651c0ca5a9aa5a4f4d7351a7c0b75f8620de2fd3c89ea38a918c694d10273e283122dde875631134963f172a498dd3675a40f38045ef276f8547b96131293fef0da650c9cb8fe433405a59048919770f9572b05917163c00859a9b2266bdc0e7399c8453a0698a752491e1bfe542f33dd7726b72d37787074e55197410b98cba51a0ff704ee672841011c74dc62d3616df438858994ddd1125e2a2383d26612195aa8ebf52371718c60408547a267690445519674a70e4e96a811195b096be278a13d36aa7cb2d5cd026eddb900ca1c87104e6d44544bf37614562210038ba3590cebfc13a75cd46d755ca7222221ba376d6ca863fc8b496fec1a992a242868104693f43ad425108a47a144406658b546c68916ae9e29321436b34528276b684552881b4c3f9c53864122d4a03ef1d34ae7c187aa29f92382de3aa59dc72b800355326b4133cdf332205718dfc3117632a1e1bbc128b6bab7b0e7ee1f5be5fed5631dc4331ac629b15faf7d2a4ac2198d6f1894c4d0c095ab8a54f8f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000528061934748c6758ecdeddf3a2df78574a470621496ce3f12e5e4555febccc1a46a772fcbadeba8b2eb5231b5b15deda5a38076c737e5d091a8ca8482f84ec4a20a51ddda391088f2c3926f8e1d8b77dd0abd606e9ac25a17a86a5c75adc215c5030355c4a1b307c1cc80a3bc4a7d4b4044fd35d173a2c7c081318f707828a3438dabe0836c2d6c14e1643f05ef8405531d5594411ae4dac6f3992279cae379d7c1762b122037301d3ffe8efd1beb4e027e055527d485d0871f2013e7b25cc26531c2ca6ddb98b31f0ac2c3bdf400a0bae942c9d4c4003f9952b67af67e85f572edc3345a84b6dc3cebbaadb7e3c876ab2da16ed0eacf4858033bf5a4f739f9e083a345c2bb5d8611dae90d25ac45d8b3d39b4de584cbeaccc6f5b6e61524349b50e818bb6b03c7e5b86795d49324ce6b1603791f20b3500a1b8ade82359263470d777b35dba38276096445842ba5d5e960fb2ab58730f970a15aa42d9737c33be700127a7ce7cade024d3abca59ca49f9a7edf44db62ccc07a595016868aa97a140178dc92530eff864c24954464ba886db7d74be7b540baaf807f1aebd014680ff4a51e16e1391e32069ee823f3d23db72244d657233578cb7d29a33e6ec31df1fdd43b51742cc30efc54be83149177e7bcde4450dcd142eb2cb745f8865dfd99dc84ab92750f1cfb0f3944e4e4eaa41261a1e8c58d9b230add792dce20d2612823c0ff9f82e04b61e48dbb83f1a6dd5cc7f92bcd0a37ab3053803d1188029aa1fed9ba04f4c961588c9ad2ba7ef1cfbc50fa69b799898eb0dfe9668260ca5680f91a10d2bef8f108ab28fcab693ecdb942070d2b9b8bbb22609c8395c23d7482c31b69b0f555b7c079d3defaa5fb302ed92619c058adf334e845eb1c6edd903c0de2aedd3d9830943f8bcc5954b65df37c901a17ef13fa75b0f2c8c1d2e38681874aebfe90b463f2cc7831958fdc0de0446991eb3c3612cc00188dfc1078fe458d2e5b80efa7bfce800c6b4ca0e570fa5858859633551da28f36f1ff418a9b7ad18aa89b4612f9d676d5fd98bce6f144cd7458ca9f2bc732a36a4d186ea290a009a870da3c1f60617d56ea7554062367121f3e5e569503aa573b172c6278dde5aa4ccda79d9d8faf41c6c9040c1d1d3cb78b41ffa8a0180395439f0d1b72e42471a9100973ab3bc7aec559d94d2d6402374ba5a584de168395a156324e1e4149abd35c72ae0f79863cb59ee6ba22145e36e0d85d3caf8a427d38c96ce489cd0aea20d7960608c074ce3cd0494b6d6d5ec8895f0f03ce78982ad8fd6784bcf16825286c51325662f34726ba66d3a91eeb598124d6755da090ef863fa31ccd5b08909a3279a35cfdce24d2ba16f42ad280b029a0e27137a671c862b0e6f73ff4a1de320c4daffb5cd4ac3522ef1c10e8a918005535f355ce6366b43a757938594366831dbf7ee72f311be4953edd1ea1c598960745d3dbb7f1e2d882cc063bc0791d18c6376a8497f2f91389a13aa96dab78feca081d761479848a5b4cc2e3d015f343b9000583e95e785a45a06842d7c6c0fe9ac4d70f085503d7ac954516953c497635ac8b7698bb784f73fe6e7f9d0ab9473e828168df4ec142cc1fe18fa067525915adf0764e44292a0316ef3c0a443683c92c4661409589eabd7b4dbd43f54317ae0e3d1c69c35a7868991fa0bc2f83430d89821b91a08ddc2d314a717f5bc6f3d89daf163af73e10c61630139e3feda723feb2edffe6c7f364fba22e6aab75e267065b5e7575946c56265743816b2cf12a106ae21921e3e92bfb7ff80e105468f8409d6698e8660b5b05f3f4bb19a0bd4be3569d24f51795752be74c429aeca5be737de8c01000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 39","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d3915174a6765df00cf3e10440556af5fe6c07fd18c63f8a54276c42d431cb302040191fc1f4af55098d7b7b68961986fb4f90fb43e91434ff9e8519b43ceefaf0c9451187e3fcd63e5328474e13198a6a633239d41e74aa42760dea1efa9b5663198342583d04f8efe696ed0ef3eef2d592b67bb5195af0d7f22b46676b3a04ab22b713be82a8ed246e5677979f7aa59342a2db735cbeeacf048f38de585323c565564f6799524b2d2cbcf871e7a96735f6c4bb159abe1f0b3e5ef687ffc8c021c508f861af384d97b30bedd5cd5a09d79f5dc3b3a63058311dc2dad44e2c3e3ad36739544b6d60c964a694ad3c22c33584261de82a633e39cdd60be3a12916f74942abc50c6a2e6d67e9c66e6a8b08ee2e56d66e5a466c813530f7493e7ce38a2ac8a625385681ab5f242b6cce26db166446043a499e92a2a6e0a9757d1db721bd98425e15960a8bd79bbe185697cff36afe5bd59ef451524568f75a0bb1b3bc4420fc4f567aa662fc28025eff6b326e8aa7962a9ebd890ce991996541825a9f1ff294fbb97d0d2f11b9eac2f0456f60c4b638491f67afa8426cc56538a5a1c773be6ca5e64cc5ce4672277cc7b275c9ed6958635a74dfd6d82ae927b22b0191b36a4b003df65c4754ebd73eb79607bbffafc7e593760b34b99b69c25daa98fa12262abf86a7db64acb335eed9c0f23209652abde777289b7f073de9ea0f1bbc44b0aea77687329eae6e140d18e12d248b2f8ce0b1834659edf154e2b913885877fb4c830f6f422d44e14588a2927a4599f09dde700620667397466b4fb5b835aaed4291b2bc674dae853cbf98e320c363a31ea9f2caab6e136fb792694a6da08eff4a8ae71d8f2e7a632a31a42148c9b0f8362cf1211814a7a32783149245415b603942ab22a0ce15086c56000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109ab9ddef4bf16229baa4fb1f211bd6bbec7cb0a580199a0449a79203eb7662d18ee0ac9b894faa9c9eae51cedf4f21cd80049ac1c057327a43d6117a3d3a5915d358263ced2959e72271929612617b186203f16fdac31ba915f06579f3db73a5fd1e061811ad07bdf921f251e2bb266fd2cbaac8336af0b4514bc99730110b46e2ca36ced6b04a8c67bc9edfd15c159c30d6760277eee50e3459307799434eb29ae8cc07270d327648ee2deb759ac8061880091ebda7c659cb8338de93b107e5a48378bfeadad6463d817c944d0a8d9e5997e914054a2b64292061611b376cb9a97c133ab90c9cba231356327dbc83c195d7886c77260c499e041d0432e214b70356c37568221fa5f978e1631f7a44f0fe013a64ff2999d9593a45626526425059e7a7801660765ca9f8b8468903d05e02a498266bb250da5c26a4a20e9289433cf3a94e2e37b5a16644b1d50d584ed3c08397d769ec679b388ca1a5280c4a27629f4ec4f593f465db9bc48ba801600b8f95ce2704a4284ea61858701bf06eeda1bb565b3963705a3a71cb7e60d1a5017adc811c55c2983dda3e17ecb362aa24c14df83fcb7cd6b92a89f986b7645955d84f6b97a4c5834a6983472e11a3d92419de46ed2c8687f42f6e9f3a968df0da66b15e954cf9afaf0b92f88471f96f0cbccca5f23c03391b506a771c53f08f52168143d83a499c85016727ba99a6bb8277da82707d67e110dd2a4469e4764a85fc4cdac5d62e67e5102e459412a3700256f2b8424a0217ad7739521e9461f947708f579632e63b244b5e4713592971f5112257cace73a4d840bfdad3d7feab62811601a00e9e3c32768237d7176553ea2003070707b67e762935e8c8605d7ff29d07f96669d4d969d3e18c21a9f3bcac8ca9b261f7bb8f1846d268708aa512bfbd011628a01088c000eb79da9e12c611c5b85d741aee6da44c03977318fa095e9f0408add8455e6b0d1c25e33321527085b867846967998dc0f65b93a15a7d1eb923bb57d1af805260afcd1491a47786a859eb6289c120b8c5cd6051ff18e2201b6fbe89490c296824fae6eb3c52792d82b1408918799cc44331a71b4db01867abd28f82ad1e1718c9d575be51ef192019e65c798316eedcad88329dcb5f96c6796eff1b4b880924c04996485a11a9a94cb9d4804c5acdccb1770a5c6c39f95b1d13dd76a083996721301fbda0142215ec44e2c3157ba51d88f2a2a496556388a8b02a3ed4d77da8cf240a92f8761d9da000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000549ae2638d944822298959f47b2173de7d1e58aaa622296ad4a4cb67ec7ead8220ac2f171605ba2d08af3d6ff5849566eaf96209e9e00cc28eb9a517cf5061545aad24cce143a2ee1ab7cfa259ad9c01860b33b0036f2cb3a5086861212f408c5f055d226ccc77cc884452b2670d89548ec1c6e98fb311df03979cabf725e78956af185447287bca2517f554e9f25e19d93790318efc5d2602fabf262e5c7fc307e5a991e0122e332a803ac4a91b318b30d79394248521190d2be326037a89fe918d139f763dc8daa2c3bbce53f04809f0d97303f2f1b88b572b3086acaf38eef36b4c0791b4918204b0e1e923bce9e3bb1e7baa07135b176e266af174d5df26c44842ceac4ae4c1cff05557da3db8651261be78d766699b1891cb825fa9a418c45bb9f7f2d347f3f92f9529ca6db94e2ffcc69337fb3690f556c5a44cbbd9d79f60aff063de68b14bd2f4b7e8cdf94f6c2f40219d27f71e8ab3d4d6872a5d4b82eaf8e3943a6d425ed04fbc5c7596ae929ad680b245e3d6a7c5ccd7fdfa1d14ef0f72b9baaef05b7b84adc02913ddbc76d5fe80de30527ffad1825ccba34f8587c5b0291471d6957ad99c5fbcf3669b4ae5930c8af68305c2d3e84e714cb9049a9560a3c94aeb95a252f69b68f755dc0e0aab52dd054b670a275bd2bad7ff8ec0cde6224e9a0eb537e95dab992c382d6b03fa045da402ce7c5b55138fb400d9e86afe30923afee82c4528d1b38ce16d33beb47a96c18428d919ba98c9782806d6f4a40b52f7f0989337c724be24e9a5430cfea470d02ea36ca479faead94a74049898d1f1be53d5ab8cc0cdd5438a7c55827131de264aecd18e5f5f2f9fd60e8d2d6f55beb27eb77aeeac2a15432a5f1467483be6073243d0165a6c242fe1bd7b7aa701a0827f286ecb51e4c2626dcbe95466bc94a7e2a09ab334fee3959ca31974b6286e2a2051653341623cf3aca65637df657280b6025db0c0377ec09e6e32010f0f59711a30496695d23728319dfd0ab5f3aa69025276e68808130659d912a53693584188e310b1cacc41af4b19fad8da95d4b35e2569053f553a9dfcbb8fdee1455dfa0e4f5e94324c86a24288ae27f3576ae15fbc8bed49bfd8521d77a61fb523badf0e3cee53799016c6ee4e1e5defc19c7717a5c41ed8fa6bf0e5811baea76676de03767a607735c2a48bede511012eaf1f79e4d2c3566042ff2c63bb82fbb399ce20e1f268d3844bb473ad7366ef86d064c5ba080fc0c01bdd2ad343c5367d80d2a058cf40725268cd34123c219d9109780335611b008ee3f8848ea9d174d7b96bd2fd9a04fa2b550dcf0b301d64c0764299d317dcd0ca05718a1ac008d86fea330095e81567e83bde31a0d635098d7b86176ce6cc4025e8628c73b394d9a45b09b64bfd3a424162b16e1adaa1ab60006847c6d5ca5733237a330147cfe6b9170d7b88834bb79f1fddefcc0ebb1d4fef326e28c41c919607bf12ad112807bf8582933ddb096f1f3e2bcd6bcbd844da317cea2a7688a5fbba14d84c537814ec2b171ade28acf83ea481631b968c26f8d2bf2c5af7d61a93378e1e23fc756e2f0ee79199475ab4ba1fbc55d9adc2b05888b2910049bca98defefe96cdcb67ca9d4aa5bbfc6ca0ecbb78bf29035d158de2a1708d98beb85c70ad1c64b39b387516073e2fe85bd9efa25cb048c224e0ef76547dca67fd66485a97eb5e56c06c78ffa08ec1c9c6f2380912a2585cbcba2cd702cd2b51022f63ec920412989bd743a8a8beb07241e3e8eb38ca14cd400c83dbfa6fc8e04f58529007a1477e9613291af877692e4ca9ae118a1902ae7b4ae7dc2e992a6495cd19df32ce64131a8d8c41969a8bae1d870dd5f1360ba9278d5b76e746faf99d526199e87a4b1d3a5c48a33989f103cfb20000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 40","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002913920f9a581bc978196ed0306712a1b468354c88066e29a7314e6c4d9412076f753fd3f36466b43be8f1bb3c354218b69f28aec52dedd47e3c9eb7ab19f03db4c95f55a23c8d84c7c472167891f5fa2e2c0988457368620f666098ebae80ebaf2e299befddf61ff2589197be74db308f7011b6cd0f40ea6813a35aa742bb169645aaeadd60c9c16ac2e121b915cac6562e7cb72e1cb96afd393cfbd3ddf343214f9e91d2703f32c81b202b4c826b7bc1baba154d3c53a558f485aed1f8bb18375f4c5090c68a311156270a95bcd85151f5775cea414d0df955d8cd28873579b121260452bfdf2aa51dea9a3ef827cafcaaf1d6c5f607c0ae3ba4c6af6ae24524703f2420d3761c0c311f5eb535dd6125c1f5f192d72d024c60db3cd33f1f5c7603bd6cb8e776b1cc17df0ef356fa0739b026309d14bac0f6c9e4b1df36768ad7e759acccaee7c164dbbcda4d0f5cba9ed7cc65da595146337d194dc74b2135a62a8662d122358e539d4e1f3ab3879445f32c62332b72a726c928deaab519908571e038d26ad523f0f3c4638a35a2e9744c735666d9988d546c8294753df8fec22163dbb0683c2d9620277a0966e2b39765a356ce78d01816b934a2e930ddcbc9e63ff8fc4c6d38322478a1e3fd3b652e01ef8a60cb1460ad6c956a5faac0577d6b86221cac97c5622b1a70d9d1646acbbaad7e77e6d29e720eb536b2feea35c7615257d78beb5ed43450baef14b8e49d2d87b33866c2db06d659dbb30640918e0c9f66656291f78b6ac9253eca3a767a7fca211684b54cc372f290fb237ddd7a6911450a4d89b37b612dd105eb34460793b924681d8995b23653a519daaac5aecd97222c996fe52d2b56bae5d9c39c641ec9418b2cfa2a8a5f3aca36b925cf530856c971892653e525f2623f5c1c64210780000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381095f8e5716b16bc4b346c9a3338107659c35d3aed0e104a1a878f0cd557909ea669190e21e922d11c685b486253ea8b4c8595d0adfe3e2884570c6f2172d8dba1c0c51769f81f9bffebc9ae5e7a43f3dbf8a72af261e090546035b5f5b48d068c5ef0d49de5a499e54a1a9922b7bead05379a45d454f8e9176e649e9c1849c92ed0ae6bbe4afb1794f5ad25d419420673a90055801945c3b928f85675806c9b189e4924e1dc307dc0936a88a6be025fd320d5c2383db1f3c98e5e3a6aecdb091a3d8725d446f89cfc354c1193ba887ab60aa4b6dc05aa4aba6fdaf35e6d6c164cd4790ef3ab592bb05990604a386a861623c17d092ed5dea97b419cea7a6e5f37979d2466a38a1577bd3e5b5bda1e0d61f3b5ca429c90e1e4daeb4a58b4b670da4d93e82a6c49aabace33b881fd900bc516ba1802f97d2c29497429589f43d78ffecb7ba152c53406c7f560ef534c1a5e73d615230d759039c401615d4a22a5f9590163fd7d7bb7c67cb5e157344f6fd9a8ec18536597c9a20a4d0172a593b92dd9778c81cd96c64db1cf2dd4bd5d087abd8b7abb56e2971b88e824bcf5d096dfe86552c26b216fed93e1e8b469ab368d9809597496758c751531d9eaaba0999ba94dd9820c2257d6bfd57276117303245bb965a860b5f94687295e0f822c9e3b8111d086c18d511f49f812f7d4b39849f7c4332f34957edda91d28ae9b50a051730ed627ac4223f94f594ff59d22e20a923dadb0db0158c7b87ed24a9a9c77b59835c1a3527e073803f6a496aea3aaebf670681e3594082afe65b793225630894e7c0d58d0c42344e4ad149d3902c8c5b7e501ca1591939b580ef604dfb2b650dee05fedd65ddcadebde40379239be34c8ef4aacb4aee95e0da2416dcbe190c0480a22c5296068df3ff5ded59466409bc4a79b12855e30f1910665549a7ea591f91525002ca584359b88ee9a913c953493437aa23035509108a2c5b36412163eb5e620dabd0f987ab8ab45ec0e759d7ade876c92900f7e367968c87fb1e63874e8a358580280452eda6f67f6ca36554a010d4254a4f3a4fa2c6951373b190858e63f797b460204b01123a724f58a2958468b94047c607215e3e21ea626fe423765d49be6a581bb239871cc43f8b58f906b2cdb21484fd5619e82900f9b5633ccddab86201d1dc568e78c1d5e6fa6772bfd0d7c126aef00cfe60d44d6dd849ea9e860e674774a9b9ea54e7ec443ef3db785cb2a4861a81aed1f544b2d734996bd500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000056a9d84e1dd28c513987d5587a4427853762b7d7af668ff9ec2e90211d6cf5c0de6c7e54b298c1a6c67ea9a693cedc4fca1a6adc2c6dd0e5bbcee7266b9c6ac8fa8af5e50078a6151f938161f1feacde4d8079b5a9d563423258cf3ae9e47d8e75740314f2ffa63865a8b30743f773a53e1aedeac45caae01993b75c8116fb0b431631ac001aa8bd02e5b83de627af0ccb3a3d86f66a7e5fb658f9226df31095780a6e8262a247d70f4e7c971d108567ffbd7fed0e16b7ffddd93f5764c3e02a61998c32146564d46589538b2e071af86a26321a3523354f4f0c396b863fc8e9e2e3a173901d0d178a9d2828d0e0974b72cedfb17937d6054f185a81d4f853787e6c3681a74fe25faa6c256a9f9e9a9253f98b9ae4b8fa0068dc28bc7e8d5785cfad20f7ddd643dae6a2ddb02713c9cafc2eb2fd18efdeced05cc24913061bdc38e932db5e8181fc0d3de26a94e2138800b3c01e07e83b3b0be187edc75da576af1cc7b7122367effd6ebf05f4c2eeb0ab6e9f91201a4237910a87de9fef777981d48fba28ab8d64d76380911f2a6621335dfa96b331ae8b3242ea1f2a260260244196b0b9596c411218a17d0a58d3b5735b9ad7b6259655cf6e2d0fe5b37d0a0b02e67951f5d3fb277b6e1ec87528b08229ab0ebd895cba2d075a47cc8100e9dd17de7d951bf0a68d710aac21c8226d8ca95ac49fcbe9d493a8d3c7f93fa61685be57ff422fad036304f317a3dbcfee7a4610c8c1ddaa79e37c19d6414f47230e01ef1cd5c7c2ffc319a29ae6a9c95b06c603f2cfc1d1fc914b036cda6cf9a876946983b06123c2e5c7d09bc190647cdc0512f35db9e214c77d3d7d0234c3f2590941236a367700f9c04d3afb949dca2067571bf28e78ed35fc026bd801c4afee9bf31c97580953950d2e81ee6426e78d6f8134ed19707473f0874367c86c9be170be63405a9bf7c46a420724b6ccff9c21b015e21bb02c5a7aeabca873b46571530de56e47288c3424da398517abb6502a9a6a65d4983d97e479941c44cf0136d225991226f70837e2a7d1e9cb1226f40bf59d52c66549bf8e360096954f5875c466160a0c75a252e5fe6b8f1841fe210bf08520ce74d77b69692086ef50bb64732f19d1a49e5800f077700553290635d418168a6b9e3ae980112afb9d58a18b94f972845c309e86fec7e456191d8760a1c2106036e44c5c9a5f2cfbc67d741e8e937e99ed7820ab0787e39c385356ef0f05cd3e31c44115a8892224197b1d1f554d5098b72058fad49c665f716a266cb4db6204666e1dc07b6cfde0ea00345661e0f94a5025d2ec98483cf482058d2eddb018cec11d91eb46b63971ab29367db46137cd7690d5782e3a3ddc8cabd545fc1aad8a9a0a39542aec55cc3d58a5bb5e4a559db1fcd2932eff6e81c8b8e5ad5b4e0424a444bc55d96df63c8971a5890310fe19dff8acba72d96fd3f32d67d41a2f3d0b343489c7fdee7556012c2d88e2ba9d512b71e7d04f92e6be3a9386565271d755bed752c853e4539f95c3287a275004f76b9a93837c6efc6760be4a39b8aa92c7605ac369472fb29e11acad98fc91b1b9bb3505638d4d46a3ae3c10c8dc115c35725f06649bfb00ba1ef214b9f2fe98be2da99ab23e7b9f014f5c5d0248a9e0e088ac175c8048c6beb5108da59dc234e9edfbe603ba912bea22505c2a9eaae766ff55aac8392aea5c722df25bc6c9fcf9b0275df71206a4e5290fc5e71d79928e357400dcb04efd7cc9bd0b86e04bfed9bdbce5787e40fcd6041adda615b5ecf03c30ab9b2809e3514e9ac87226c55f259c5f157945b0073431715e1740dcb319edddd1b5f2763f0439cc0d6ed5867d9d98c227ca3008f30d1b2aea40dc73ff8289e4a21586eff519520f888e7e2f6d29a269c12607d13d398f437cd7f0a07c94ee1e1e3d8518d0c97be1e250d79c5ae1709ad8a638f5500000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 41","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000290391715ba0f6ad0c69307ca003c8e19efbc02970725861c69a39a86562c22fbe2483303b09f8a6a9f9c71257159c663cde2114749d8541708e5831765c44a044a478beb14299af5c5b9c8a0d922d3cb1cd46905411fcff7fbbd0047bfdf89c3eec5bf742b8c1d57d8c31036d13712b44148323ded33728e44defb7e698a94d550660cc732af26429f1d7c8d07e2d57386d3b3e619d58370b48daf95f7af2b77a567b1e9936fbd2aecee99f35b39293a2cf65328acd717c7dacaf96f1e14d995ea44ae7e6654d4274cde749f1deef262f3202731c646a08e7627b1ea862072a300b6cef078a6ddae28bf1f9c6a169ee96ccd66fbb5ad431a5e0279af54c59e5fdcd3db0c96bd0aad217669544922e272f1950ebaf105651597d22edec059c47a0f26f2309065df87b6a3addbf721d178af4a0c1e74b841f64acac8bf4369fbc4ccbe4a2806cd06d775299891ae8119d645af9b2cda17c24fd2e14588d1717d4abfc26fce6cfb3678e91b5510a4aa4d2d46082992cac7959c81b68ff6087921812c4fea691021d562c30fc6a29ce773a2c6464ff44dbbe225f72aab6f0d4aa00cd665bbc3b4bb1fd6430b7ac0ce0eb51abeb7f0ca405c614829a99036f08a934bdbb6580bd1a8450b9d359d916bb6ed69ac413c51fae291714b70bd8ac4cb7c665063accf3695eb495bdd1816bb669ec00e577e0ee516499412549939cf1c6177fd46da0f5feeffb8d05a5a089ad1ebeedb334b28ca482c90524aa2110710ca2690246519d8eb51427d7e8feb933e3e3b8184cfbd2a5de9b53ee9ca129966dcf6097a933dc77e6efe1c957df4ba39a8b9e790e56ed12d4c4e918cb57633ce9e95cd445bc434afe893f6688d94c71e64c995c6ef611b273216118e713835b41e526094d6b94cd4655aeebc6caac572aa96fa000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381098b44fdf4fbc81d1bfeb82a898f536031c675a266a950caff647b241a9eca4ac2e0eacd86444ba25986483b9ccdc11a43462dd204a8bc6fef376022e7b3270b5cb17724964fbf69cd20e06a000e52182da92c497a5254dedbbaaecb65f8da30619e4a9c747812b2c26aa090a594765ac11892607217073127025ec1a249ac7851dcab16881aa4347b918b6c0a5f40be129b28ff0d5888654b5d99aba9f013bd5511a8367b408263d319f2d6d85bd6613e8001baf24b9d3646cae6f09555014a01b811cd27ae86ffbba4cb20bfcebb8983d81386b81b2a0bcd8595a5d3a8ad9506b3de8bca5d44132b58a1853dab4290020052671387ab14de3b480d0709a68bd7e0108aa3c0a30327aa8f898c0452014aa12f2abe45dcd90e02842340936b938614b5d8eb01be448a427132518212580010f4da71b8ddbc9779acbf45f0b3b03b279eba01c1755d9926b08162b62e849f68d41803c998c9463aef9959036ea1f0bb509a901c3d28feaad2215d0b311176eca14b7cae6d34d20e3186c020f9865e3aa1fd0872d086d776e2a5a38ad0c291e0ee5b2d5b3c8e76a30943d8e220688c68e8db56618cff6b25636c761669a0acd6354f81f466fde0d66efa146315c9d7b710d7caab863835a47dd5a358d891fdee1456c7ed35a57070a3855f3b1d3b63f15bc0a078369ab8dfec3fa2f8014f14dcbde0d69886a304433cf9c6a4a358a752a606aa6d325ba67c880dafdd1eacd782d5278c0ea5c5b59412925fad811961a7bf169cb9d99b58a3332da6d9fb86e58eee1835cfcff753d892d6722c28b66192d9355fae09a146934f53d0536e44670edf6507b91af38fea713f78436a05e25109d4322bb5c4a101a2e7263e41767cfea0e39adec3460dee885346529871c6eb7987c88664d7d6ea6dad0eb4d5005bac169ba56d85bfc00eb23ae6334dc1b2a35419e2ed8277751a45302c94b09e9953935f4a2f8a2e7b302f9c98844ec3d4d312a7006d8561d7acf5af2c9850b164146c10a540bdc33a34b252a376142f0766890ba9d2552929ed03a7484997483326ac8cdb3b81c2e46f239aac99a7c17155432e66d2a44c25719aa46eb082dd2e83d6659679174f8d7059b1be6e9468b5ce1b511c0d9119a0981195ca9a46c354bc2027578eaea75195b892667e3370e30649109df40ad020a8505d5ba4866f9962c76ab8a49a58e059f6842d2c78419a4bc7808691bafccbd122a03290771285c0530582d247c00a7a0dde5f59d7230100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000058baf2860129c08a1a9c7a7bb3120b3e40afa1a4a09050c8483e7511fabf3285544d4ce3f41401dab8c17da547f6777a72519f6eeaac83016fa0e0fb0b33329dd02ab8eb1f291758074ebb5b7c4c102b75ba422821e6755b37b914d689d84808a89cf88f69a446f489a260ba03ca52a4aa14e8bcf4bfe5134dd2918a88d67329b9badc6ada4a3071fd21cfc45235fa0a1b82d91c5877f10ae087464251c8899732aa7fc8f6c0a5beaf4fa41e64ca97932925a06e218272500249577705804c6dd9f0f61dee6aae096be0ae5e67923137933fe4d61e9a88dfd5b3bd75aeeaf5018a5153985e2837ad1aad5eed91620d935eb9982dd2364b5413f490bf251fc783503fa146300e6adae0682e0597c3839c645dbe855919bb1cb80c3dc6e233909017bb31f5adaee05ce442eef594fc15fec3a2b4b81ecaad1340b0677f27009290ab3ab8788556389047f63c2ce9390658e151ca85baae45ed2fe12b6667967f6b772ee683ac2e7347c7b0efa332b3354b5043cb86200f8e4249f68030844d00a86faa7b79a4129ad676d1e9d58828a1af4c6bd68c29cc23002e0a0313500ba717b8756d4a18e41e381df8d7a999a153876db876ca4a508486a4f331cac9cb3e7c416c6329713cab76e1c8b63a8cad46f8eb1e65116f89a3b4eb8faa14a73097ca71aea3220be7fb7fe64919893930445d962c309e23332e4b3ed8ca768ef0ed46eaab199827ad628a1bc20ccd9f61bef67f7fcb017300ebc7493a7ccdaedbfca5f91e80b80decbfd9ead9bf22fe16b563512c7383d34801c504202d7a0e19821ec8495016362edac165904d2bbac484de1d4112c3a3e6ea56a78785b7caf2a44b5bc8becbc50bf4b521c1d086086feb009c06acb8fa0f53e7654fb02ad7898e35e5f3a7dcfc50124ba1f30178c707f4d36e4e7758c4cf82747753cc30a836311794a6a9017f53abd17a1c9647ab38ba56aac83c1812dee8a5a75c5cc958780a3e9c3c1f39729bd365948f7fcd8104cf09660060fbad2be9b8d8e5bdd22286eb0bfd4010681ae7928d0fc008e21c8f877d97b5b9c7a06c02530fbc6a9d6fcedfedf68a9682177757cdddffa6cb9086b8330e61851e2761d84da37635ea8441e3b23fd165ccea562b0a3616b30ee5fae00f76d6801b22f2215d80829e01db2c0743e3074cf26c96b0eddf97d79fb9c7ffe9b5cdb891f9e61fefe7e1cbd28fe25b7858921c8c99c45a84b50a8233037dacc20beeebb9b22089ddaf2ebf0698498da694f75ed2463d09ba2c757a986b8ca556cdf46cbcdf288c078041d497242f66411f47f35a21918855f105f24686076fa21bc1283f17245a7122a848b4bc10d996b2c5161fce0336b2ec747a4a07fa9851ac5423d1efc4b524e795b2e4bffd1c5cd21f5fec954824dcc53bc3883a7f571a9323dfdd2682c4a4c54e8862f347c9a8897779170b257ad26d90121dde722a3f214a44cf6c5a5ddb2452a2471ebe7fc8d0ef7f1edc7920cb42a71e4db49a0168d51843f47d17bade50dcb340e5f7b7e5b6a6c3afe0fb26b5ea172a4011eee838e5634e521483c6edbe9994b0658406ed8f4998c7b4e869845cd16cc4368da3bc1b025a6ffafbf540133c372d452dd831dcad39d61cced0a0ad193fa9886eac749001e3bead5a7962275fc62298a1bd054f4bd97acab2bbfdc355c73509d98b6de5b4cd774bdcaf1398532bb3db56524cc047abde6880c3b282fce0fb2ad7e4c5f7bc138b48d194e8c8036df4b9f3949e912afe5d2734662f27583193d0fba2b73c1a0d012db853bbbe4383f6c391f3220e1b5761c337a054fc9fdf09c01864b87324a90c776efbf5d34a68dee38ebaaccbb61b4c79a58cc848184f605d43cf9d40be90c1fbcf6735270132b59a636b16ed28111246270af32ea2cb7a42a084005aebb6161002e65b37217361bc269f5ed12f7d50613c82934a6d1d98d1308ac82827b7504f3fd351e0aca1c62843c9219023fd092692ba4b83be198ea000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 42","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000291398eee9a1420f891ac25675966e448e6ad97c0c4e55ef0a40af3e2f918395d86215e944bbd2e270f016fc1a08e2a3df1e2743d9659064666dec62f6f7509386e2509561ce024d04433126572ad44bd10a2b7e8e37126e233ae7ebce7bd5bbdbdaeb36aa23685b3aed81ff899c2c68d85652aacfd34f6a470894804a524261bca3d61ec629152ece0a288f7d1aee1bf8aa2ad668165bdf02614a15561b32eca86b5ff857a87ea4a17ae9f395032ab075eca60d8434b89a53c2691cb48b6f4eff60642aecf6994ce07d9679f2eb3a42b791b867a24534ce3968721790d241d1a52192787698440e72638ffc5d9d66548b9d7fd28a54ebd9a42f0caae11d3a4715536c8d0913c822929338a0645e5622b9a75945ad1eeac93c71fff75d8a612af3f7731d5da5b96ffac1a132483a55c5872c79c34508302704a6318527dfca409bd249972bcc5376f135cbe761a7523be7cf6bc39bac9af6525b93f9a0937db609edc96fcb8287f0ae33691ae16ac83622ee6525fb589e8d61953d6dd54bd7036dca6f1b1723fdfe568e4ea308fd41fa4f73b2b4b3996504834e5cb130cfd9b5fd159ad2c3987444b9e77e088ced314ca2e75087985bdbc18ae230cc0d7734d6c6f59bbb5f564d298fc07134ac32e4d21606310f41f4fb7cfe37b5acd37522d262497873a82fad531d987e78659a39022612463b2d1afcecf96a5b40ec4da6b85297997a9a3fbb5fad8b533d530f41f38392e6334c88312bbce57c6559a85ad1c477592f8f1e8179669d1dc5c2510a78d44cf54db497dc38edc511926a16d256a9c15346d0e4bc96fa5c55b58d67a60f5f56c70a395fc5f380d0aba909526b88b39ebc11f2e85d50466749d6140751bea2fbc81379ab2f695db0c3a2fe56936894333807d729b2fa78a473bc0a2f4fc54442000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810998dd712976999b3e0e5798c093e04c7ad7a0a125f303e56470adafa26248bec73faa6283518c606305560ca2ea8b46691b7f1e2e9aff01dd660a63c8bfc27078a2f9b089eca92a52855a076c2e51f2daf2988cb65b22ae11720afb02d6f2e70a248607b11c324f1d9471381c01349e330ea4dbdbcbe6a4243e288821da75bc5ee094d70593297ec3d7ac6ed5524dc9a83c563e4ec5f02225e7ac5a74a41b76ca9c69d474d8e70c9444ba8c85f0a8d444ece795e4599b27da58507857c60a25fc58900796045531527ba92e280e5915e48dd78b8c0fa678db12432256911da24f150c060a40260452ad317bb8a2c3908ef067a1e63b8f14849219a2a7a57a356871ec1b53cc01b610e340274c920712409e435417807a08642faa891b51618b256efacab2c70624417a50786ab0ae4c58f88814463728c7787a544891e46b741268e85dddc8080d9e76a9e17c1bbd02cf4f3522faaf23ffa902bdc5b00ff72f22e64376895e128a2f466aa5a97d648834a7af7fb94ad8a721a867bc4ce465b68f890d250a0442a44417b88cea40c90a4464b1bb6b4d1359c102b87a8a5a61210950bb69fe24b2df2b7c6b8054722ff5ef91f5126049a901a45f670e86a431914139d9dbb9b0d47927c5f28ba48f457fbe83a330edf8a7c65a050a57ec900814757eee81b570b181671d9f4e3c38fb96e88ba9e902a02328d68872d346b49e2d55698417229c0195adbf4a558f42a7480e4abe20c68d309e7b7de56b8bf8943907413e0925e7703bc65a7c00b669c6690d7a48c6307fa0525e7aebc70c5d4b9fb1259adb1c0d0d21ed28418ad3801826c6b60a8a597c14f718c44b6f351db615dde738926aa58b896b9950432b9344d48f09c54786011836f915fa46d6a896fda3b553579144c6f5d67e01b2984d34f2f5e31009ce6291d42cc73dd2a3770d2b5b5de10d25246abcaf309c38ef461ba17096352b600c1479fc7129e857ab91d86b6494ddb07c1c0b3f497273985a22ff11bc69f13ac4048e19479869740b9be67cc4681645d84e1fec140424d398929aded092d557020002f1646f91af42c743e9d8ad09829b34732c5409dd03fac8953fbf2460284c9d8e753afe99ee2040025548894b55614de4585725ec8c2ab6f7528c9ec64fe00af65aad051b8a18ea5b09174291a1552a8da10d24b524eacab5166d49c4d314e14039b4553ba22f2400333a74667a8aa0215b301db0a975d69745949c0ed9c3268fcf523c2ce318f958e40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005aceca4505d43235f274d902464f4e763312bd11060f908621a063409eb42faa6bb5e20facd87b8ff41767c20f69b1f7e05d5f3a957f48dea57dcc91824fa48da6ddbde7e3327a0a8d46a47606eda01e67cea1f29bdc5fba446de60541dbed6f73d1fc5f49bd77d45285d3d8ca93f6df25aeef9324bedb40e800acb49794ab05e6d0aeb11a5994fba36dabb9559cd93cf522174061c116cf31874a18c46689fb8c075079dfaf73ea0ea7faadd47ad8ef68c06af9738b41be771020fedb79ca3d0165427b58e547105fcf82a12b67579d1d3aab29968817068732cdbc5a2e9e8d55d17468d03f38d564f5ac6efe1538e4a680e9e15e35ab54d07b6b58ec9ea7815ccf29f4f880cbf1946f39556bdc2bbc78a5134fa7a086ddc146ad9d503a4ca837e0823bf0728453f6b053788c69eff8d11acdf5f07282a75cbd17f2aed58e39d862ff056df17178625234ca7e03d22aaafc4c07e3fb08f4297b511b10579934d2761fbb600c9454ac05fff80cfb93de3b9e0ddd0ab1e494de477da2b5635e48d5bed5ce359e66a3ac845826be2b4bbfa6d825373bb2a4e93aa417648d1cea755aa4978784d6d9489f6738b4da03faedc659408d9395c934af774749a498b1406522351f86838865f53cb0157247484fd37ea59ba72ff3226aff1eee353abd34ddd63fcc89387b947027e04a6f4ecca1ee5f6bd1ca758aa4f796fe839338164b58d8e5d71e6d5cdeef6b279ef15a7bad873b12f7c5b3e2817c37bf00802d2534d425d52d0bd5935bf8658e5bd39b5268cc45d0f27cee5a57300f497e77af5268970782030e6928281379cb14bb56d2acd963d189c078c7a60e98a782f9483ece7b4871a061277186a01e878087381704bd72c63c32cbf2470a561c22a5dd3a1988b7ed0d274182e1b075af277920b362d612dc7ed82057ebfe51a3ca5a9a9a45de015c460be6a48cf67c820813048a1cea0fc3d7307f802b4fb7e523e7c8555fa56dcf66237f176d3d973c47f55af93fc4bc92b98b7de89829b1471dff53b649cb03b719db58daf824daa2de570df6314dcaf5b705557f9d783559277a754f3cd5b783d5a577ebe4a065d320284b01f71540f1986bcd443cf4fd480dbe06ef7710387cb5185deacb5c2a612bca275950b8988f247c4b773d8983d87f47d60f5bf80e6e7baedeb14b5ffbc46893a81c63f99f511d3e24fa8f7b1ba66a7db0c1d9acc6b5010ad725bdc2282d8a24018c975c8b12ed3326f48194d4ff93ebf051204cd224ea39f27d63fe07cfd0162358b412dbfd4715ad049ee5a31638d3111af2db7952f3a973646612712a607ea35826249d14cbde4380d8bc986067b1cc27503449fb128767986a406585c3d40daca75c27bd36117d2487bae82cf639ed1fa016add279d109b8cdae59eb31e1f006cb7af000a267e8582e55375cf6f06d1a47be9bfa21c8428045b9df96808ad74d054820a4d0873257eb318a3dc9b6d9585d973e26d435345b4d699a952c3092eeddd975fb59474212080d03ec489c695f19cba4d1cab1ae8d2e2c730b06e657d33722d24222ff7b613b6e8608e8a6003e11c80239ff431b5d8fa52b84b867a581798833590524c7b84eaf6cda9ca94c5ab8ef55a1262eec5c37467807c89ff7d075606a3902e7247e9c6646839c18493584d33db65d6dfc0f23e68c9d13fd57faf4836c28926693dc3ee372de27a9d3e4ab4229425ef48cc410f1792a51c9f6fa5316a1d9a7c99979884ef350b4882f6045921ca88d4e44b435c69c1aac11660971c2a3f6480c79e6e146c0b5cd2371bf5e7486ad7d0be88d62a2ae8f0d73c17cbac86ff6bda55a880b182a5237498e9cb343a9cd82d7784b72473d222e688d13cb81b2908bba854b9624a11dbe8cee9c3825c1bfba476b4d23d0b0c325f1c498a65a3589ea8e8df8dd9030b279ede30443cf80367ceea4a122dc8329e5ad42491cf57ef47ae2b15f9c54120966b95acd727a4a2b686b00626bc808f43d82d20deebca79b074a7bff38d2531ab2f726ac7087236eb3fb4bec8a2d4207dc84c0000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 43","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39ff96836b9dde5e1f7467b4ed990dbe9b1ae647cd9330fcb9861989e0606021ecb0a0e81966905669d59ae2298a03c92b53a68d62942ddb3238cd5e1727bd8278d3481b0ffea6ac8952873471d41914e191e69d234dc5b0b3b666225be79b9e681d10d64e5b9e259abfbf63ce72d1f7477234c7d9574051e26557242c6b2d883598b5534702b2dc3e9c0ae2099d1d1e6c1f4096580dd3a7ef881eee9e3169c37469f32204d5b228c7130cc52bad7e773910f633064ba2428c4433752b824274aaaf7f31ced827f286a28ba5a0b176540c9cc09edfcb7be74076bc56e8cba79b0abfb10ccf78e356272d2a5defcc889cb7b3bb1751d017d66e942dfddde53615d5727c9aa61934b8b608df2ef8daecb6335d2be970a5ea46dc4294a3415357bc6a05bb217bcf7b7c051fc5df317d1aeaf531597e136f250a42efa730257b61be63fdadaa42ea2eba4dd731393af5321d92d09c756f43a6c0d57ffcdb2acbcef365f0c43c4b59df560533a87e3e9cde312a3f728cbf978b99c72edab3cfceb4ea854500d1c30f46f11a868a69de4995ec2c0aa346da98d9d2e0864971d21a544328d04fb6158eda9f7882e59a1af9c743eeb87f943b77f6cae27e78b4e21cd29bbd9c995b644c2b7349cce895430fe1d8b47e0551b8e7208a937a7eb49d58d7d12b78e2324670afd4e03d1e23b3b9caa91a6cefcdb42aea5241018926fa869757b853fa0de58945de67acbe2a97c35c81f546817a9da608c48452f11673f39bc5a8b02b2306d2dbd36755d8c969953c71c55fdea63f73cdc1b7de3450dca1e69aab9b3b568d752e40de66252efa187ff611b45a7528462cfa696249f84fb9f45f160c6df934b6afc45a4b7a23d2d426a8bc1ffb66850f81dedfba314d4a41377be7116e343cc86fe279c9d34747200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381096a2243b6c6e3444b6eff96c0ceee038da453e7dcac5c157333b4ef8ba8559b346352813e542f49c060fb5fa509ab4fc84c3858b94b6bcda4a45d5fa2b05b3557d66c938688a1928a02abc8ccaa452ae5391349e0bd613f58b148b25c10ede53b2a8ba83de951d66ecb3dd52019506b2d5f3524e73e2b7a11c17507aac168af34dbd1a38618a8f9fe62068410662950778d222db4bd12e1091df50caa4997b1c8714c19e2d92c55a0514a7aa7b20abf3515f038fde4bb1e2cc4a18d51361729b3222825d7606682bbc6ddd96a4488d983a4445750771043d719854189219adc0955960b4ba0eb7e3b715ad63a41fe1c40d888f5995247b681585ae3b3256e4fa7b32b499a4e6334ae42527ae8b365e1044c8b75549a3d54f64a5ceceb82c928703278b602dffb7a50f1505bcb4897350aa58a91c7789ddde26d84f3315eae83b293cf13e81f8b5f56af3384e502169077b16548e526067c967a3fb779a7988f553526d948ab0fcee86813c7549f3d381742d15317eccfc7dd541d333619aadd44e57fc055039716d3a5ae6287d563a23a5e41e64f06a5b3d2e625d11dfc8c10782a9d8c404a8082f55a27336785de94850f6423ceeb8305434c16506ed4fbcdbe32b93168e263c92d51fada5b0e812deac4f74a898c52c239848e51146fec4d528cd76d0bfaa124c88b1530e535d7e76dbf7be068b060ecde661c8902a4d47a033d834332955e963047c08629b680f46c6bc4669e40724354e5410905994b3375edaf719464f71dc7aa464c25e8c7512a0dd5de27faa5ef410d8775384f21b7ce23b7f2aa793f352561c4ec6d1730e447876c30b769ca63a168fb5e0ed6a0e5d9a8be48fe756ba9ea09a61a711945a2096ecb821adb1892359dc1b0e10d7708ebc2d4d715619d2c75445ec378758138f9d88e5d1a18221594973c91a436594a339a3266d864601b471c6810256ed61694dab7082fecac7cde7418ea18966634cbe4dfafa6fe25a5762deca60e7447a706b95ffe0e35c8e4d84a068767696f440932dfb894e7911eb1f44837dc8a29ee48767d1a6ba816b7f2e303ca1e5803aa6da4f5bec4569533dbcc80d82fb7350dcc829de8039d8cc372c4f6b81e48dd52f92211efd76d583521ca14e015479a7ac93641e7507d585365211b24f41a04008b267a5c5cbbeae13029889d001c95c4b4fcd1f4bb85ea7de2df5aacd1a33a6a5a66a7c57e860a1891b4d78e77c017aa7090572d09d4d7741f086e34db80f76f670000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005cd96e2865a0e602ea4e3c5657a7f761a6f771007989ff885261f5638c14c1bf80aade34cb956d2b5fa1ce38fde831423201d3692e8e6f40e68a68c085dbe3c4cd8e35394f74072f44de98a74e42c9176a86ac06bed8c0ca937db4c3bf92371106b7a68ea8fde1d1e082ccf522a397401ad0f8da6c82bf76eab8afe101c7ff023a0fcf015b40ada0073363e7cb25260c18662d651222a4ccf1b290ee6f7b111b9a963211d67d7674b499449f760352feeb9fb7265a5f2f7f20c0174802c7f48226d92620d3e009e85b104230c21ba2fb0012dac4bdf9fd184e09cb3e593eb1f3eeb418a8bf3173e6cb91fd8080c7e80dbe6730833a4a9f22c52716731c7cea4f70cde0f81d2d9aafb6b60820598a7f6aa1b963b7686528e6e7885ae085c3d26c4acbf9fc15080d972ca841175b343e59fed79ae3cb4dbb4f0d7d463bd3e0c4b2090139145b8d7db5db10abfa51dc909c5cf7809030d72a5090cdc765eecade2b365f719127548ca601ae0d21e402e18050acaed30ee13cddadacc9373a87a218787b585319a7e66fbb13851f7ad0d2bbc1efe6efe4f7ed248d844f58b6a5a21fa9295e0044982af6286de296550f72b5e416373f1dac006687ded1e7d40961e5177c207579f25e77be808a6ba33dce8a2a6f88e97ae98ecfbee5296d4a170e3574d9ba592a384cb0545bcfc32b3831c0b736ab77440722299f192dcad519523995f71f2983ba87aad2261e6e01c19dccae00f8d6914501d1ac3d4aff0c12fa125ecdca34dcdd8407f0045f8e8be0763e19eb007ed4dae36e30afb07f8daa7431b72f4a0a8017b3fde27123ac3e8ee575f8be310f68f81b696db1fe63ccb8d32b899b209b2205956d209bd6e48166bbb4372a607e83c47698db5ac8f9b40d05f38efc4a4a1309d999d5ce1e1a5828d56eda4666995897c8e6362d0b5054f04bccf79d03852d1003c80ccd55e9f4578d8bb2c8e220a4d7a4e2190024c85c718654ccf174ac96c1bc50ea49f961ee7697c88e6bb718679f1d1f1118376b31a4b8c0471f6d7aefc5ab426515d1b2cf0eae66246b3c4132a63c63d7e33eb9df8d8807215d58f46ee832ad3ec893d74e00c73510b9625f62d4eb5b500eecdbc7d088d3d318077a4a0f7d64adb13220232c08da75d23ca7b20cb109c972b7c159863991c32508339558b9383ddfe7e7dda740e5bed0ebd14ed300c634db01f359f81a7133669183eb187c17a2c8ab855bfce73e34a1f59adb0ec39ec0c7573ad3620a819333ee79d5e09cb8449f91923ef4c5e21549eb7f56075c014e1c3ad2805e682f07ba8aa265745cb600a460069678745fb9638f6709d62d2dad8defdd5a4d0c2ae7401292bd1da5f40d4cf5d59a403932ffb677237ad74691cae29fa31b955172efc5e83c225f2dc0430ab0c909a97bfb468ae182ecf91e9026de819f3440fbe69b9de26f812ff3f3ce8037f124ab368b1153c1cc127d140f754c525d4799e1a19d93b90460e6518f0b6936dc6310b7e9e6534b595e00225978214ee5aeb12a6f45b5c73fe86771818843ff7a6b88379c37165d9dad48affd6fbabd11b1fb90aa5a78918b317c5f9b2ced6b9647f130da9f91e1b1ceb84f6e1618248f06d654e159f71033072f1517064bd96a5c138402771abe7f39f53a798c2423b748eb7f310485d6376722e204fa33b9740e7fa68364289a677c5c78a19a7707d2549bf9329334478c64351fea1634388acd4be57e4abe9374a0e999b770cd81b1bf4a8ff300c297b116ceda1a4a1c1bd5a2275581a0589a46142139fc596a1406d16293076527cdf9aea2d0919f9678423b7d95b153dd1d9d62b72a12f6491a36604d19e7bb83c476d232769425557d3480623d40b7ac27c0f67d4ed5ca4d487be915a68352dcb03a3929a4bb795248ebe2fbe0612833d9305a0a31d195718bac193fc59b880042a7f61358104a919c7e7c210f02a856b8b1057dd8527fd4ae1ea81f9e1bf7c614ed8a312c95154873f86632cbd60c65176f13cac695bb4c23675331058397d6e96e4f9deeb859e3937553d94bede3c2b9a5ebf00964a49ab294bccee09e5a97381d2375941aa775a47f726e900000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 44","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39bd6e6021669a6e817c52541844ba27f615830e801f444f6e9485576c4d11cccb744c0c620a6259562862d3b97fca9198551f09fe5d3cd8c3a4b5f6d1d37030ed7545a4ad15847e61507298e6ab4c717074834357a5becfcd591cf0c070796b84e39bdd60c47d8b3d587c66ef6b1679e135f7137f62522a19ff977eaf506bca79b2f8885aceb965e0a91bb1e6c31d231b92225b520ca4b3eb67eba2d722c5149efbb9c907b50c91be4e0b7f8278d1ee426379f110b521b4c0212f648e971c51bd7448d0da3bc84561e1d7d6640de772c1075c5cc862d0cd1f5766bea9dca984f6952141abfd1ab762a129d1c091e628cc7325a686c107a0a5ac1f5a328c8e4d6372949bbb64c1be8eb8f0adb4f0e6f49cd8bec64f78c61e5a42e7f1c8268f02e47db3ec3f421daf458778d7645ef8ff7778c6c9a5af119b4c4cfae552ea3b3c2e1214fcd1bab78995fd3b7b7a99a24f8e21ea4e1d164a317aa7f68b05562c0fde7ac0af609663738480b4f26b5117a0f3f0b1259f21046aea70988cde09816b8c1e8fe365ed98ba57b564e0092a7cd96abe940824f1698925be6e761a4fdd8b6092ceecc064e250886dcb3ae1cbce9bd358a108e67e33318ee26a4474b34e9013cae2b2f245239dd58f6a0bf49d84460bfbc481cc13f53d99fe5613ceec21e2fe41ceffebbac86f3f122215aa3258117d45b6f91b409af438b896c3ded0d3dac639b1a8eef8927f4a1354836411368a1acbfbd08eb5d34bc86c271b018afdcf3b0fa6abb38ecaf774364fd2878f4c89cf3667b7e4b1a9bbc9dea131cb9e996487a55854ed2aefce9475b68af7407bc64d8565d86684bb6de96e02332ed8ded61e774f28fe1136848f14ce363b5374e4119dee5b0860b72ffd2adef3c2b34681b64ad9b31344ee5a554428c72ec40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381094cb918f77b628e3cc1a793fe55a97f7a5053a0ea6348c814982960cb69dc57cbafa358b2aaf4696e94d4612de259576f715c81e909310528640c27b2a95a934c8e2fc04b822e3ca2a433844acc6c1602510ec9ac13f1ad1423a31e6df1d7b5209b0aab607667951e6d1b30e665146bf4b1c619f7f30293bc6ea9717403dc3272eef3e95e4b824cfbf909cd10b5da1771c48c6c0db44b46e55ee11f356c466b1445951209a730026d23e8506a325d219578ff8b73833e4acc5ef82ad971b63145b2f6e2ffbb199e3a8f0c204f5224645d4b077cbeb79a3426f51e55a24ac197258f4e9fc31d520c1da2b2628adb49982060bbb8169d36d650f8ce84c930f97728a6e001103cc1d919ec2a064ac1631ccd0560c547306156c6befd95485bcc2bbd8de2978fee34806a4c71b1c5dcb7086be0162182363c55fb052181b778cdc2b621ffba7efff60291d44566fb120e621969627816a4e27a6164ade4a9921217955ab7dd0bde673d84b9bbe33fa7d86534ba6244584e5af9bd6da16f301aa67babb70be24e271727f9bfc04f716b92a6526ecd03a61c883f26c2a4d9d71c375a88a496e49e46f9bcc0f1425b94e84dc401d938766974b17c0ac0616c8d9aee1b6820d2453a6161314b316f611997fcba96fe999a979d4610db67cd534f0335ffc3db478542fa0e6b8698ef0e89af722a802ca3f28d96b94eac1fb927bb008bf39855d410b809c7693e44d9a55ec96426cea789286ba6e9de742e9eab5d29e447c2167c8dad21d1bf420c3b80750be94c593c80d8f1824fe134e1efd1af1b73646dbac281458f67bc8ab3a0cd36ac3d2e4a0006746c9d7d9a7b20421db5c1c2b756839472c7800d21d69d065de002ca6b26fdf4f046c2086056edeb9e17d195986d56d4d962a6468665c551f97e4cbb41c5dd48b1648e87ef434726e951db642e2f934a85f659a81d01b8d071249f78bd660ab3a00a677b58ccf820e8027f748d88dd596d0e9a2381ff473135c61042e7c8012eca88b042a5c09128f284c2c64d7d5ae909c0dff16ae4521243259918e96da50a592dada95fb9fe562899a6c01bb752ec44a4cff27801842ada26e2ca8e3838c27c93a744056f551010ef863d5b025db704cd8201e5db2a4fef0eafbe2e8aa80ed28780635b54c8715d4897e106443a8d386c51728583235273e7556eb69d3208047a95c629cae192be9e68813ae01a7462bc7382bbab775a65053911e95acec8b8a8c98861214c4caddb96be43f10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005ee047e2d484d798b3829ca6037d6c1588a2349de09c5ddfbec987652cfda01454ed791dbffa3d9da13a35230adbe1b39b042e3c70589658a03f75447c1cf3970dc10fe5a4a9e980f2a33b642b42e5e66e9ac4e7a56888fcd72913a79489b5b163bd37b8c3c8d242ffeb37d0c1ece21034be9e3685798c2ebc6b809defc02c6f0c2a3ad70ec0bad12d57add63ec3584ca98e680267fa514b34de4147c9d901b59914d49ce9e0f885855ed0ce7973f3307b675408f90b51c6a4d38a414d970eec989cc7900d7723e19acc4ef743f6d39eb1b563b8c13d42c0056b6c49732854925b606467f7bc662d17b924fc65e9c3cdc2ae73ff73040011a152b05ed7f96b2ff4cc39a22484af72812ef02b08ef4dcb64c8936e74549afdd5d876027fe2b431e61e52e8793888473f4c1e5c1bed2c4aef8e5e300a735b302474fc6f54869984f1a62dae29c7c9a0ccdecaa55fe137ba14b5c5c121e0c5eb33b035e01f3415529e0826b27498d7a71b0c086bacd140c02a5948aa54799d0dd0ffd384c7e68578247fa28d205b18adac94f7d3c8acb7daf71aee347b577d97ee8e7e865cf4fc1c16640ad1e9d0192aa13ae81a71118408e145b6121abb75b4bffd1d403057d4ad5cc730452475a7f067690bb81e81e17ba8dbc31059969b20d387ba59ca8ce499e59a65c8583f29cd539f4f75ddcc68c7bbbc43c849802d8347143e2fe78c1ab6d7ab6ba9917301c88386b294aac995c24ad680a8c3bdd7aebef21e84f5a1909a2d83a8dfe46a75f4b2b47614cd39bf3ca3460de9bb5c37eb7349a17ab32214d031ce927806fa394470f407673b0cdc3d9a7e3749f09ca895d464a4269682ce6ddcb8fa0ec2f05372c73dc3d06fa6f58090efbbc6d619a7a565d4efe441ad7e018a7f5e1384b88eb4506fc54e0ab0a8b9ee3641760ffc08f6bda78c12396473d1243baaf6ae10316213115441c0b65c7e475b4e1578d066a47d9c6e92fa32d0f2c365fd15f5a2e88a81691f039dc642ecedb6652d08acbe64625b46083ce758fa96c142eb34477e065aea04a45ff4fcc3e3d146acd7041f5f7e4c6b26c8205be7b66db46da55556ce02b48af55a4710bb28b8ce102cb15c1a4af59d9a17a2dda6e2d1e96987f6aa9f4216d8d5e5cbff7e2cb775e83a776063a4aaf937bf0ec84149ec1a7ee21f735d21625e85831b80dc11ebf04f30b13e3a7e4d4784c5f8c61c679e0b6863958f42ed31deaffb4c272a3731c1407445ca7673d225eb6509469dc6c1f0af43eb00f18b3a210aa57d51169f2a9fc251bb338ed4e9ddb19282dce871211d26482e13a8d533dee00d36ff5cea98dea72d9f0b32dc398a3d5537a3373058faaa3926c127a1ec739faf3d57cc1a05d578074a3a72c3f2b1692c2ba1f1ffed943e7bfcbf1e664c4f52f7bf8d86174ca8910c290c06804a7748db21008ac43e653d7fd7e0c982eda9356f68ddec26473956dff281f7b767010c57f4ad09a05063a6b3ce078dd32f3de1f40526c06a2d60e36e2c70502d5bebfd2f3bfcacf8720cde1657b9892406baa3df01e59313eb655b6a545331eba01bcdb9c99e4ad7fef7438ae8715fbe589a2f99cb9ca34b9610b3ce5be38fcf979240698174348417420aab069b8ad5f646f82958a136dc9f2f81e601056bb4ab5e10f4ebc4a00e18924c51d0fd104078471c6805c49d92c78c832ec3f10d8966e19add3d3b4516e12daf4f63fe6bbd228062db743d1f867800854f7bb7ffc2caa0d01a0bb683e368673a8e664bbaa17a8c0c04bcff05246f9c4f3020510a992ef26fd0933bbfde9d042862dffd33a6465f590a2287d8154777a89724fc3df9f2f1b1ed8765e7c7b761ca4781006822065703ade07a6e874e70928e1aba29ee490690d24f6e73d96b85fb53abfd1c1fde439279e08fa232043b2344b267cfe5901c60e7ca14b0c85edcfa2ab90f341821d2b4e25fe23129f2432db932f23b5957706a433b308fb918d1c8d81eeb399babe95e7229ad41f30460cf28671a4508b0bd1c61f48cdc23587bb9bdc6f565e76c86547cb71396661bec8c7fc2223751f765c91c45c674c36b49aedef3df2537f888904b507edcd89155d40cb81dda74376bc9cdcaff8a368f1086c99ede25526bc53f95f4017000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 45","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000291392b81249b15bec856423c0f967ef642c3b27d6e06574442411a793873e948c283614f9f568319d4098a7524ed5945668cd5b0f4ff1b18da4f1597af0d2fb979f829ce067f79237ce2ee1ba0d938cc4d092e28759bcbaa8fb0e61bae8f41cff73de088a1b12f2b48634eb6d7bfcb89d3fedbafdc1d92e3313f8cbf6e95b6a44712043cb9acdb058ba515cbea60491956a9672b244e367b4db666331a62d883036d947375fe4482db51487dcc92db90428852c339d162ad4604e43ccdce053155b5785271849d6004b76ae95d90964952f34299c2ed5ac8f3584a412c91f5f87d79a2591f4520750ecca9b821d23294d0320c3371dbcf33e421f893b13ab70ad688b3090c8a526cda47634ccde1aae8e22eff726978e3034bf4ddf36402fed1ea99a9a4f532bc48a0135e3755e19830e5490634567214c452686ead3f3b166944f7be60ebb01d77891cb0d7cdfee4e5dbe0a499fe7e23e9da3ea5d96b89c10cf4c507da111ff749282f71c7a7c3bd98322049cc2ca92d44b5945f51af65e1dac0eb6c2f6d034d7d65c926f8b94e4babd4214f13a1c8c574cc9cbbcd4e31715461116fb19d26c939e440b1d9469e0ea36a22ccf9f030b07ad6aa4fe1c9437fd9fc68afeb98ae6b078ae1a150b9554297214b38ef166ea2faa378992353c64b302843c9814c7d31a1a6ced63fe40db98e3c2951c5b83537815cc929fc48db80d7b949835102959cbd2d676c4a264c29e09d06a2ebe38ac3f28dfa6de44fa62bbce88f2610f0db5baa1d25489bfaedc6d9f7c6fddc4ccc9d3390f7e472143fce582c46077a997bb459261629974e505de441c0c21e7e3c15b1f3d2fb8d390fe9e84d6a5b024cd07615f4a57facf10f459a3f3ad7644c23b912ffbf9edf921cc8c5f00ade0570c73168f27b2f971b040e1bf2800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381098d692bdaec68cf339ab00a0d6e93b8d1c691abd5948f947f2be50b617a44de55e6a2b22d0844722e87ee82153ae963c96114e4ce59639cd450ed7f4a59e2bd09c0d1f20c4b463f6caa976884323a395ee6330148587cfd11d347e73aa4f244bf03fc98d501339cc8da7c444b349150e94069dee067e73d23de7382276ce91761fb0313406ba3d578f06bdf0105c8b715de951dbe4881674d1bfe19f1e12463c6d0aa10d3c9d98c005e12bd71da4a23936d6f06eedc9b2ec1d7508a8d56a301ffe37ee0c5b3a188f78253f10d1a6201c3993f2c40697aa9afdc09d2d905b8ef8423f50197801cdd5a9edf7b2f983a27b1621a98244e204017046f4c5c24963179b2ea6a036427b5a642d7285aef08deab061ede7d4415da452bd244229c2602524406c375c0bd5dd47a6095a533396163c40399deb38a075991901680048faa3491ac1694552855aa67440678f082e168942cc490cae17471b9c8904fe77d5622b9b8c3ebb0b6be8b2b1a580516ee08b54ce84318856fdb365e1374c5cc42401efa822285cb8c138112e261954d01d5938a57e365821d1fac020ba98ec714659b680a0c292d8c5392dc448192cd1ff9ed09467c50e6fa72a72f51a41fc43886014a0c4677939b9657bcc3081361058156043b7f8155046564121245093a618c827a566d41a5ed219e42700f2d0a876709a776605e882aa00558c6e7ea2bdcfa72f0fef47b2d3ab4803473a0ed8f3770a7999b22294d1067314e81147e3c20d966e768a75522a69c095e6a269f6620cda21a8efa43acdd4d65d98b219b4d49903a1850d5877b6bfc8373c85b538ccd037530c1a8794e8bbb440d640a9d44e925465311c0286a95eda5222d20f0a6ad631414c4290ddcc3174121a0c8088f2c26b4969e5e4f7cd65568d4d3946796e5d78628fd28968d5217184c7d7cabfbc5507d5818eee203ce8140f26ffa8e121c83ba4fd604edda4a8643939966220b606742b4193377ea847af11e889ada33474f11b4105815f693ccd1a6dd140767c4e61cd9a0f38fa3594d79e4129a9ed19c9eb900c18f172a7ef05b5b8380b028faa9bad43726ea2567e9087d09b6a27aa261a86d94ab4423a273563402a355cfae50a880b2b48a5fa924b4028a443d1b75f6d14961f5b4923dc41a26917210acc949df5730557f19b36485a4c16856e7e78b7fd9a8687dc8c49a4ca688efd9b4a78ccac139942137399fca42dabf769acd198322269666e17363cf5aaf9a931803270e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060f6a58aa820275a2f43d0f05dd0ee484af42b665ffb8f21db322abd256a5c753bc8ff6a2c71467922e09726655f1a7218e736752065c871221c0b9dee6a9d56b78a1c3b7357774396f6980226dca1f91ba828e06bbf324d5cce8d584d9d298261c7149899fc9f74d501e920f22aa34706a79213e35914dbf57b9642a42ef0d8226e31adf89d18c5f3163adecc79172c95650d764e3729edaa08c207d930c26df8ee1291c1cf889283b70af00c0489175f799273c837b281a5d1284e4447ed72598efae23b523274644da19bc0359ba59e5be9e5828ff587c335e136c1d789257864d2648ef9c03d1c4b9809dd07ceabd865254d3d8d597587d71e374fc2dde89c22c2330e8904f6b53f637348434a21aceab9892d5df8ff84cc58229782bed739bfb13448896f7b1064b499087f7547cfc0a49272c2a670a9431b1b5a07284b6749ef834510a3ec0c61a43d5d0eb48c8f487947c4fccefcc49deccb6111d617407c76a1b4a849c9a190310711b102f142f9e9cbb29f46447265e2c8ddb9174b780eb4a51003fb68483a265f2475d5bf6ece18af0cf31bf24cdd56583e777c4340086917b78068dfd380466f43d020e285ceed97a467db96bfaec22d80b4a6ec0dbb98cfc44436a41cadc85a90b214f00990d7b7010bbe4ac94809a0450c9abee5aa4037a44b0b4debd264120e762086b8d6f17afd37086c93a8a368be97e0f7546af16d731c21878063e38df3dcf3ade6dd2daa43c198f49b5d9ff5362333f29ec2f13cbb90dbe4e703edae9a4f7334a1c5ac60d5972c4af2ba61b63c93bf719854e615d16ba4f704c55260a8838679815fa59be08c4243cacc1a584cc1b4e777fcdc6e5a167c4cc9093749ace4836ae058be89cca3221a3f63f07089006e4c44e40653bf262945a640d8c2a24e7cc3529e4be76286c86ca2089cb8d4684508d1fab81eae7d8c731b65a22700bf9009a3190f5ed837ec22f9112383422027aed838f16a7740cf79ec101865d320e380d4aba745acc8eed376dc5b3aabe58debc35f8e983c92906aa2e3d8fbbe237325302e2a23cb1312ea7f532d64e79b9815996d28e0183eb728a37e19cb219987576c142f4b2f66ac6c7c77028ed59a8df27f78acd3910ddfceb88888b4a604e5d07ae1b53ea6df6ec2163ddc4bab422d2438ffa543b22441e50e4087fde4bee6d79d90a2f72548ddc41c5ae07dcc87666ea3c4b89a0b14afe03b585e7ca507e5f29997f2368b0c68c6ab6e344c082bd06ae922cd8089634918d9132df9cbd665a4149c59bf76b0e94f66481766fd79054aa80c02e0ae04a6e2be090582171b2a9af455cd9fc302ca9d1ec837ee26e0e4d0ac8f0692cb9abac979b58ca92e5194ebe46b520125bd0b3ed1ac2bd817d3510e33cfd17058f865dbc64e9b99352b6caf10f0a5a47449bf927a8eba06d34c80d77a0b00b88b25a4c8747aadbb11ba15adf9c959b05c4371cd8439fe5028e004a2e1d2f21190466fc7fd56e9ba0599a0eedd98246aeb4b85994787b7604cb52f5515b42c2fbd4b5e9e372a36cc4e66483dd884dfe42aaa5ee7fab200d8ec6e3556dde0f9e9c7346f9967f8f3cebe1e4d1cd8e6046e5e94bbc74ad3d51db0dc704f4a4025383f0391b9da37bca8ec59e807593a4f040fbb186607280967e5048cab92215dc783d9045f7a0922008628c771778661e97e9f88ea84bdaa8ba61126f71d193a2a564e3acde7adf2c0b3d5b022eb6e0c629782b0025c9079d4545d88aa2ba27d10c5dcbcfb7cf648939155066518878cc54a4f611aac21bd3a1ec628d3352f049915fca55234b9146ece5f78fbe7cffb35695363202edb9ec3501a93b4b6fc81b3dfdb5245feec8aa54195262c2467e15506b7d42a7ff61d75998722d0208bbfea05ce7d2e66900a9b34f44c2a21257c220c03f9d6d7f0312a36f5c12da20fb5290d5cfbc1dec7d05c44820885c479063ca88783c5aa128829417ec4dd41cf83a1d991df2efdfefe375e93f0371695e353ef737f4a75106211a5f70c82b4f360abcd078c9e829c82a6b7a36d22b8d1f6e3101ba009c759fc83999d52e29b387a8dc1658a43ec4c4d9330a4ed2138e035ebeae6343a76a82849e37141fce34e9a41eb5ef88bbb9257017ad8696c3847fd77ae103a082ed1a05de9420984c147aff927e1950244912079bdbe5cc070000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 46","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d396061e4a48be98df42f5f01e108a9720881ba2ab7af5bbb39f4d02bac7395c2dee65656b1f16cf74085cd094229b613d4837f857b7ebde23d5dc1106232f250f315b79ce2f1623854e1f6ba37dc660983d34694e5c127d3224f951d409dd66291b8cddb8acac3aeb69b49b8b27597c91c7691c16acb661c61261dfd630350eca2d06450ccb71bc88d6ac918525c65bdabdf72fbf0aeeec6db6baa7ee5784a555fd3b3b39bf63f79054bb379d7b88fe8fa494b42811739576e2f3fbf32b11cb6c932a9926c1586dac45e48d8ce23bd141c49d9783c6e13bb48187e4924787c93d5fd606a759476c7244272b954b191f2888db548420f746f5125e3e91fbfd9ba7ce004034798e5271c9dab13ebce5c1a85c1d48badb55442fb5fc26c955dbcf48e7f4d8e58d225bc550a89a9bb6c8d2b6129beab54d8ab4334b03c12af64b2b544c474dfb8ab4f31fcf2972a1599ac39fdf10286121c0c795e8b14f52583e6be59d8dad382e1a6cd6e651c34f966672307ab155ac6edc9667355c12ffdc5dd55051979d26d92b9292e850b6b3dd3535887b65e7b2bddb372c4c753c922fb9e5d74a845a707b55918f9a1b4dc12988ff241db6317abbd4ffcbd34e59e5abc406cf50d06c330654c8eeb5224440e9a9d9be8448acbfee9c1f27f8ec097b6a7dc6aac527a4cb27170ccfa608c5c8aef999de9ec4e72854a8f7395c350a7562df07ab2509c736391e6c30ed0902e2405acb6de90c27cc589ac8db0a0cf3d1b19ddf1c2839a7887c3cd4cd3962ba7fbbf098eb5b439fd8e5b061c6461464f875f8f6fa679d1d90b43ca681245725ba4414e3f9996967d1c54f4c1e37de8766875a735ba0a46470cca8178ebf52cb37c5edd9faae9bd18c182c454fff074a731059ba42d5b8890a968b86dac75ffc6d500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109446ad5694387a212483239e56738b2a6aed03610b2202ce1537a8cd0390964121765a395f95d33f461a788944b3b4fadff5de938f0519485259e31f0942c846e9a52db839279168a94e3149fb810fe4f3b16c104aa4d3ca93f4f973b8596115a09bd0ecd9d0a4403103aaa91867667fd6de8dd51cc0a44200e59ca19505408807a0616ceabbecd7fd6e91b84bbcdbcb4fb5de35920908b6f521117e05a715895340a341b89450e03569a73f2f9287853c004e66227fb715c0509b8543ca9954b378988ef432914536b2296a0542414c8a0f019a4abd820e1e3a4b48ed05e1645901a92844414ce9c5130928222b615c6b400491e9189ee0eda4d195e36c1e21bfca54c98e08870bad09e61f1f959ba0371682aed6510587248d5e735de423444a05601689e99bb704687e71ca88ab4fa34ff604bbdc8f3fb24981d99a4578a8b9269a6a2002a3b60358e686616c291cc7c7ed7b9d51abe7fcee3a1e9d4dc6456f0eb789687b5c1eecbb062ed6592156431d6d624dc1cd3a6a40f71f4c7e34119397bd1d87b6e099ab57e67070c5372b5869429be572a8c506882a19eb4b580d6b769aadc84f928eb5ca82fbabea9d3d562bc0560ec442c2eae72e030b0479b62243a3e166edfaa5d62cea96497248d94d9c51a9a409d21490297147cac6647e1c4aeff6bed714127eb14bee9aa7368cc3214f4f9378eec043af42799ecc707bc2523b591aac3b61c72d2b898781b883815631e58b1b0d0b8b64e7127a1c8e13e090d58f406ba379de422468753fe9daa12201c7a0d41a017903fbafb551609a072411801fd1c16a6054c0b9d579213b23554a06d310d288712cbaca98c683890ab566c22e71f88c7b72eab964f9cceb1e4c1a4fd4ea454e5c9485d9e680e25dfb21e5b39270a20b45894da8d00a61a956ab91585a3d834d504bbcac39b9aa7f44801451af998df1ac850a87b5007bdd2f8c1b9e3e522a66868a7a19e6e468982dfd5734c46dd213527096d48f316f6a5290aad13f725a4b278749fb7070aa89b960d485cd729a7ee2d4af3a2144619cc04736a199c01f4d4ccce36729c1f5712878f093d43133300260d61b284d585344c5d44f761e0133c45db07f386701684fd984783550e8e84f473e47ca7896a020dd2a526012c149526e350adb4d838477704688fe0ff51076158f9d4e6ec1698b43d19b1c4abacbd62f92d1d6ab4f25cc12cd9c3926e65c5570a136bdd50f292024ba51070b5c2559a94681a38c21a5e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000630139ba17ed7b476dbb1cdfe3c42b3a57af5bbcb3be19ed04d6c3072fdfe917ecb9272d59ee89ef83522531d83aff8b9934a8423315c350d1481a4b02980dc29e1cb83b76623869649ac40ef297b153b679c327bb251c6e6bc169c48aba2a439f9ea24ef94656a415c3e86d7bcb43cb3717d54d773f1937dc8b0e02d4e6abbb1c83fe73f1b221c9a359e454c19de5e71ea4cb8c560eabf1da133ff20d81785d2ecd935b99f24840761446c324df81484c5c05045c0949df8d0f10f942e1b5b79074b358c25b6ec2b0b42df65d998b666cf1bc568e7d737f22ff541807be95ed85a9980e940e24d2c506bb0f9bee32effd85a2017de694f61bcc2b292595c97ff4c2145e48af8f0f3d71763b4db433ed7bdb8dbf8643475fb2b9155f0cc6a0048c5546900792bc01eba4b06c83a0c447ea0cf05410de55acb8e5521829c89bfbc084cd86e7ca3d701283b70f78e1ce9c3888ad2689e0ef5593d656285066f319e155f86c0a71256484f42a0c40e7cf13af0cf77c6d1cc7231a48538e9060a7863b774c9cc65e321e45aacc002c0170eddd18cc1424159d46bf99d08a28d2dea8917d28d91a1d6c409d945a5eea19413a1adca40de9458fa6bdf1e5308ef9e67e1e90e9d92bf19b5351fc49dff0a31e035038aaec651c0f20f276e4ef0ee35c14bb625eb34205516d95abeaa06a7a3bb3af2f12236406689bfab11e65fc63ebc5b944818dd1d53c0e7b88ce7aebae581d995ae7d8423778dfe20d6cea7ac0b1b4efe2b9d571de77bd8f71e89d9f6a2dc89103b73625887ab376bd12ce89a65e6280515a44a80d6c32799669260167da0a214ad0fb803930ab1952d93360b54433ce8220b29339dcf2702581e88952a5a1549dba11f4ccdb6fefd6d24522f3207796c8d5ba9d1582f888f2500964f2b975aed5d5af83409ff9720edcf5ce3fe9b6b586b08de21956e7970d8dc28f6208a80f5378ecbc506333a1d98c58eb0e2eb0cdece0f5d16a069ffd742d1e589f546c4f2ea3da0a56f984cfd93f5f2912fb1d068f2bd7c1b5e979abcc62e3a0164445398f5c0208e82b99aed1200d36289b1fdbbf03e43995341aed3ad712cc7c7530c751b40b765073ee4e4cdd411ae543ad5e2793f294320e9791ab35ae1697f23ebfa0280b8041859909b0089c101d7cc429408fabd2e073fca7f2c2886031e9f6a32f2b596a799967ba8a47e87dcc8854d45ddb6de39160600eb4235f4e3424d75ddc8ccf041aa05b25b5a3811540ea5b77cd8d7d611a63bef5c26d57475b28e961645aee0b9c8d47954faf634017787a21a671493e7c5f1a4c553e0a68ddd726db1ded4321dc735332fefdf2a84c22097ab3552f878e304598ec40eb349e1c1ae416f94112a2cf8e8702a4c3bde2f58245166550fc238e153d10f90652518b1d84ccd3ed836f150f1ff103976e743137da5a97a61276dfb0c11d071b240069582265a9cae4987b6c6b017dcd1594024d7b1336ff141e59936ec4ce5410e1b73ba6fb42d35f8999225cb1a135260967f4f6ef2172d53fa6ab6d1a2e3174b46c24bc103baf69c2128f093aeceebe8753eb352e2804ee64ae5140df1acdacd8f225b3c9a61264245b8e5cf759cddd75e25e2d790ffae8421515e0cd6f279d0080a3f80bb2e0729c0d2626b6ace31ce20bcda490c7660d04d1d82e6403000578926c52d8f9a4be7103d64e0f03e8f148bb2236781ec30f6d8bc827c107fcc40f26ddad485e6135bdc3bb331be139a07891717b692e23312d0e5b1c41f30c3b4b4700effb481a835ab54340269fff365ff87f58245621acfd83b7fcc6ff108132d8966f9836544354f7e216fbbb851f390dce8a72362f0454730b90d35ab3859763aee35668310fd501c7501f4599563006aaee9b636b676f3dbb6787317885b0f4a64171bf19cbf2ea7a625e1563032c196e1292d82c7484817dbf78d8e9e478fdc4c92cbef48d4cb4f0e6dcdca6682dc0a56c3e45ea0350d9ff88073748305fd7df3a3be8c055cb1c55167560d5c99345ba80c21ce791c4a511e384a02833b78e8aa02b1b877a9b8d806978519d716c611df54ae8ea2691540e87c6e79eb006569e02745021bdc7852e1fa4177e2c3ec89257618b38719cb07b0ba68f600236167f019694959c2ab6fb39d5890cb176f6acc3b9656e495c07027e3d4de781f48c1f1a8aa1b41449689e191e495ff3f263ddaaa8de0df6f1a4aa3ef1f5edfe437bb74ba00000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 47","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f39c6bcdeb030f76fbcd57a6303782c61559358f482d89d73daf9b08fbc1894bfd92892ccfad8e2c974cf99c10f142df3acf91b6685c0776c8b19c05890f9f4cdb4934dd55d66b2b127e24df0336a6da3c0f272bb57fe46c58b7ba0db3852026c508a54f63f117ff5996a154e2bf149ceaa3fa3462886b7fa7364ac4c16d98d4ccede86ac998459789c23145c5599e1eccd38e8727ae5eb1d09c47083366bee138fa478975e43ba23c29d90def19095d9efb0e132bdb92271b7cb9a9a208b5bc95296887626678fa0eca950d369b38ad02231c47e39bd11e985df22b6f1f86aa764c34cec362e9adca59f91c1630c7c35598511349d267cf4c235ef96c4595f3614916f5367b16c405ac2a751ca99b5e7c687247b5c415a6556d621dec023782da707cb2d9e9856d900306144a539087a7089e67bbfd4ba74ebf2dd7cff41f315683be4b09ebce91232153806ada8bbac5fbd8f852e8972fadca987b9bc7ce7b908150d8923cb5bcfe6f9373233b3c6dbe8918f5a05e7713287627d0a7c3aa8c16aa6b60cc6e5b177e9d795a7c3ad478c2a5557c1344c2d9078b79d9ea0c44b441d39e322267464644d2a65e56b52ba69db95e2f24a6c5d7822995206ee557fd0f47a31d0861f5abeeb7b90656866fdbca61036ab192d679658138ff9f66c7a05db2fc556d7f882398a9adaef2cf6a5247a354bf715ba5a91c759469b223a8a0b9311ce6f53660eff7293b8089f955556305649ac9594bac56f9a59556ff5f9d7d123393fccfea0fc65ccb3f154461be6d57a441ed898c6e7752d2ac3b1e15af5cccbf134e14152f2e6423d36dd569bf144c576ba3ae43570c9992b8ef32697641e76188ee1eeb71ef26954a8112d869c82abbc8aa9995838fc337158824b67151e65ab10e0eba4eb940081a5323824000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810939594078da8aa803a89085c18fbb275a1cf553c67e80cea6f2d5dac8b0aea9c7824083050899dbe8a625b1a27455f5e6316ead08a80925024d5e60a22a85f2284268988647d0b4b1d655c75221ad9407c2f16a84401e6d0be150e9189e63000c441b1bfec9590d9b26a8e207c43ba22a902ae192505dc033a063699b9c0870125dd9e8e0e690d434553e1f8526f52c6b869aea2ccd01b4a421453a221277178032b96dd640b0dc0b882ee772b0883f803628f173de559ae65c822027679a5efbb2cd8dcd0f6c4119d567249a8dfc2765c7869fae92447f26bcabee1b133541d12e2cab21269fa309e515a3b2eafd3c80c255008ed022bc6ee96d64420a183ee2669edb04500138208c23010c4933045194bd8590f11e005112bc765a145d812a2d6482afa042b2058b823fac6e92812e2696e594b96c12e074806e7ad58da71ad3cf4fc49360a592b270262364d3db4d1b660e220a03f944e8a599e4676da2b53c7b682113258e2962b5446badd1bcfbcd2ef1b4f8165178c859a98ed5806b484b18a90653026d4851c1493b7cd8835be9512558859085322f40210b73b95ef98b645c3e97304692cc66d50f2e28a2dfceda2d3a1cebc7a3bf5391f751672b75b7fc1d16caa1895072896746e3dd0ad16bc0fd2911488d51293dd38241650e50f554149a944320d4938fbaf51070b29f70a6498e02bc51130ad58550ff46f24be8f4d49a89cf6e2d9e1bbbe65e0ef9f1e08c4c117d81512a0a27603f31fb913a57475f0d44c3d55b6a8fd6cd8bb7a43cb4d2cec7e3af9b8dddb2bbe6cf87a8b885218ec62c4f821824a352004d0e938aceaffe178d6884990f3081fd45b99501514778a641ba283b32d5230b6a1e5e09dcd2aae64e5f3d623da2afad1a81ec1bba02dfaf6ed0bbc12465933d82c4d9508867abfed2e614ea733582d3a39f6f9f919d59c7780d10423eaf898cc19f34c00e868bdbe965a684551397ff4e80995675e2bf06c5ac48af09e5be28c9e8a3e1d736509700b1422b49a98106af252b0ed26d13eec2d701056fc64e963e2eec9aa8e75e583844bff3ab1ae559c1c8332444404c5dd7cb63598732f2c7d3f3e214b05e18e1cbd4ed2489b27b248facbd74d3564564e33a2248f7b6a0273e85556a6bc93489d6d4d24687b4508978c84a57a792f153318192fa35916881d589d93f5236db1827b10ce1f988522a81292dcbb77a93f4756012732924de0dca1eb7935db98d267735c26f8f651c9caadca4bb000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000651edd4da833528b0511534f77857ffd16eafb1a2ac87e6844612dbb104b9f32025b7f54e993d65ce85a061b6ac6d70a15bb42bbbbb6e2e21aea55bb8a556120eb15ef35fd9774fc7b5c2894b747d3e4965b77dd8d5b26f38d413662783dcd332765b4de534d08d6514ca9dc6ed7f2bdb4b5c437178710b04491708836cf2cca08f28582107d27ac305ede6030b1f8aadc4a1d29ad16cb4d739d8f813d47da715cad6b5cde24ea95dff4415b527dd900442d9ed1ca712c58b206d6e79f8aefb882013358bc578638225be79b58fb677277f072aebcf8ccd6ab61a9d98a3b260e60aa625d78058fae6028e4c5562a0f3473c3ad530bc4471228f27502a8f8fe2d1f72022103c3a2dea363e68248ed8693b3b066b495561cf4468e8ebf32b454e54df1766468ad3831d56ef7eb9c231e999c4cc3a6b0ebbf2c4f22820e256f67497427f53ad22d42c9293dc8682d0be3517b63c6e871910adbb3406b6b3b1cad980aae47bf9686e80b6e5df2daccceaf9506b4667271779d00b4c1065951e21f2acf6cf3cccb8a633d1114ce9d531d94420e4ae496086638f031c0baab5722a41a66788d3885efc7fe1c3db54bc69e35b7489a0237a37afe5194b5f424f792cc1d696098bcf327d87ebc50429a95ed82105c4328d0095a9775589fdb6c262fa51ffee4d99c6d1a68fa661d1b6a0a2e0693d73b39218a6895bd83fc1d54831b7df146fe7bd2a91b979018787b9904285a35922e22a7f1761bea541eaf21d74e3a2f3c6f2247b042379ca4c553fd9256dd0c63e4c9dea60912d02fbe4ce7762069a86cde02a4e1e311b2afde435da0816aca659bd8c0650c1f118c0ea3622d72a5e96132f8b0ff8458c757648bd46e58195faa0fc4ff8fa44238e35a25c9807b6229000ee560d8e085f27375c2f659baa5fde302b9529bf4699505c28de33ab5dc2b8c02967947cd24c6a599acb5c2d1e7d6bf3bccea0253fbe11d8043fed532aafc9ee1151243bb80b92be239bc4fd1d1caff502951205f2e6393b704e67141e1218963f664fe0759c15e6c0a1b40602a73990f040502867a9eddbd4db0e554aea4bb9597949d5fb32c2e3af92cf7816bedad5ede1b769c823cabdefca1d1b85213c79eb03e065146b58e3bfbe80b4d4683b65ad1e0611372729b99a0b93934d52dde40c19fed5a2b3dc3030e0b5f26b66474a5cca6d741ab294bbba6be516105c08bdbabc97bdec2141d035bf6c3a71553d6f6350229ca2626b8b0b56a24f2d6eece436ecb77a70d747b6a6f830578b4792de533879b174353424e7d0eadf6bd5a74b36a4e6ea7e39a4215559557bce7a00faaf0d1f81016f913a10f3c9f406c7cb53282ca8fd5fe4f5fabb96f891583e0507912ba02709764694296a5248c340a1b9ec3db0f926f438ca96fecd40c4ad8daed9b8a29691601835fe14283762236ef2135443307e5f0082d1c2180ae96ed0dd99a6e9172088e8b94aa2952ba5e128b202b2cbc1966e69b6e6384820d9ab624bc71788ea84b4adfcfaa2efa1ddaa8855d1db3f58eef2d54fe11a8a5d78ed46b58460e6f2fba6cb70640700a4520aa1a2a9b336aefb17cde8ac78d67f194662642a0107ce38b74d731380a72ad4a0a068f09e0878e521f15ce8134780c3fd0cab2dc2473448654f88bf1fe2020901b90c0ed670866b1bc337881292fba885fe2bfef6fe74765ca12372c8cbd698ac41a4c337374587db15affb511d8c224f1743498d7173897ff5b8d070b89592bebe053d5c10dce67ca8542781ae749f3a42fad7e4a2004a565f81d5faecf11115c270155fb8af6aeda138b9c71458d6d2ff63441130ee9107c39260469521e020d2b42cb5a51098027f23890dae8b28bf722af9aba6224e02feb47e40112ccb164e8cf174bc9ac4c11af9b482df9c9f7f5f1b826428c21be395eb1f07de511e8258c84f5f035f4787ace18c190808efe99fcb455a54d366dde2e230b575ed5a4a75d57c9a38dde3d91d0d1a1c4de7f277caf23e0c5dd8e3b693dbc66b6bf1679b0af74a2b9065b64cf0978115cc456af685b22d85135727a8aad96338611dc109b36c85a92e4a0180aadd1d25c5b3d4c681a44bacb953e50f994fcf5281366cdec0cc50976074d91840b5079180cf643184adcf9e4ccb44328e7bb9eb2bd06dbb7a757c35ec3dcf795a5e05ed250159ec453a1692426f624cc0737f691e475804f155e44293151e42d3c0f115ecee53c6eeef69788f7e8e5c422bb102237499f2638244c0c080b3639a49ffc1730ebb0cfd8a46000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 48","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000293396cb65026c66350e40abc7bb71360f69efc0fb9d63fb5c9bd887ab9f204863bbaa83eea260e934a591663777aecdbfd1275fdefee36a102d69b27b361d3df3b3c36eee1fea635283420929cd924484150e23a822c84399a80e15d8afc8d414ba11c4be4b764cd688d0a29cb1639734b10ba49d13c6ab5a868cf44aaebcda0b2f65dd3ed08c2257c032bfe69dd0fff1a833748ae6fceafa908c19e95f9bcdadeb6eee65d8045145e709330c1227e57f200bf755ca5f16545c722ecb496deeb0073fcee0b04b191f670ea3fe4ab1efb467096190c5b744522f5fce7293983e1868e02b5960c688d6f5f37025e65d46bc213b876af13a886133d5165e12752d15bad3b89ebcddb344cc6cfbbacca14b279cab62d4caa9abedc991c1a584d5eab6ccfc8e446d81a9367402647bd125d98f5bf53797b1fad2f1a88d1c9ac9ee8711e4b749abbbbd79e88231996dac8c65b58fa80a323a83300f4a9159d44cdd9dc7f8947662516b934ed638e60ccbab698a148ccbab22209145b7f5d68e1b3743528cda5aa17e90d8110331365a65c3729e4e4bfc363ab7f5697308f66d76f57eaff8d45924a83635477520c0e6ebb6ed59c451d20ea6f3a6e0494c5e63337acf3abb8f0efd038b4b66ea6c1495f7a0495d1545c7f163363a37f72b3c42183c9aa188539858f364b0ce8ac61b785bb6f029543b0b904248e4adb96d1255caab193a269deacd5e7c69c5f9608bd18b564d7ec431fc6d5a3062597d2e7de43bfad16260ed1ae68bcebef6a12dadede8300857c59cdb3eb85a398590befbb3b6c931b933111c531157961694972e4d553a6ec675c28cc0d6ad22572241ac55aa51f49d28cd5c9a638e89429993fa58d43dc6c324dcc60dc465e261bc96060bb6ec27dc7f7c6690d099a322736bdf14348d90825070080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381096a818b273407c01c8249213a0b565b80b5c49366c618c81ed9dd96ab610919a99e036536eca7f5a44901349af1f20f285c014cd2fa9de06217be1da30a2352a5aa34b5f5a80c3796901871611888219c13e9522f15057eeb490844098a1492bd5d739361bee34c93f85bb581204dc922b1897c869b688eb40d78447fe9d46db16744558c220111c68397e78f36ecb3739fd79d450587d7098cce7c659fc158cdb2524d044716847f99ad9ff0e29ac16116fcfadc5dca3ce5a1a666a4097a055f2a796ad912209360f64f92b6d50470734fed6c3df3663de81f2336d9d6c917ae4f461e25dfaec16f68a81450661243f478547c298293017480f5662362e91d797baaa184c548bb522141372199c4df9e78527c1dd0fce7369f1a3169829a7715ba6ec5d2dfd23cfcc8fa6e87e26cf9c076b5132b5a5522062557d8274a97b9746c618640d1f283262a58c6a11200e61c918e5366f1de9b68c4e478f156904698b4c7c249286a34446bbe0de69a0deaf9d860a03b0803f79dd954b0e9e9bb34952e054650138d6bd8478e4a7941cbe5641acab52b62605cfd2b000c911078154fb96346242769aa33c7835414d61d3047566d2d59df694c286103bec352eee1f99bf5b9c2438ec2a73ccc120fc6b70756a4419e69f2b8ad27064587fb3ccace7975096556e05a27ce9f421262accb88cfc4820688550341f59a922499cf04fd582c98668067d75871be44b1c556347a49371e91655b2afc206dc393a35e8625218d1f2fd8134027880895ae8cb3b55663b1de466b196fec76700980a51d3d19d20b91ced725740c6b15685bb70162ba042a4d090c806bd171176f68b222a845881a21521d85e98776baa0b94707ead62d3177482f063884560b336e017e893a328891ea99a9664d57bb8b2f965978a43b27eb5e757c79460708176dbcb65ea71221e906aa71ef1597408ff4875dd846dd23a18e5ae3b4995435806fb08ab5e049b6253b1c18cf0b8026894ea9636a73641c4ed98ef0c2462f3e9e8db088dda9a77524a3d39b26b418045b195e3ea4b58d81d310209c297941068a23b1c11a77198b4c8154b7868c1a8b25c4d5186fd346337e58caa02329a278e00a25a1211c250fc9b72a5a01224172a10230ad910b9111404b4fd515f2a5c603afa98cb91c2ef42b629647eee3950f28bbd036696d4d8eb788842cec3f7abd78b04df561ae78a5ef681a2916bee22d09652151d672ff5c4b5832f35ae41afaba2d8bebc35c11000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000672d868ec985f946f3c31b6cfe4811ba530eacd0ed061ec383c203b2481ac697b8b88bc0f72b635027e443ab1f54478440de16e596d30a0f1252e0af54c0f382bbf5655bea8c6b9a2f6382d003cc7e4d4f223f8e35ec87cc543ead52e0e1ed956cfb32e8075715c07ca4817c4b8dace68c8b0da459271746be41d6102b3fa5e49aee8d443e78ad3246d0b9bccf6ab7cb7cf72b8a847ca16b435f0618594400037179441f3bf524231f747d920e86506e84c61d4d038d42e82d52d97abff896c1db1c646807156324f7b68db620ee435c7b8c9ac8b193b7c892565c3631e297495bd3b59293f9a9cea5e29e23a242b81dd05c8dc9dd669424573298c85870b109c7b593bf864b56895d81386466ca5cb6071005781fb214f1eae9672d0d16351a627a3faac49be4e13d552340328323cdcb4703bbe07c2a39d75d7737d5c1bd04355b8694432dfb7cb4f1901550c7d6f41080c0f6a2cc49d63a69243d137a78260c06e7a53aaf4f4b086e0220ebc5361a6a78c9b2ec09c2ea4ec45a41065b4b2daa866d9babd71c8e6cb378595f068edb258b2ad1f420b304e5924ebe273ad6d00684f75b6a31dc5290a37d0f9a848b1fc4a67dd9a4fb1f9b4c6cd45e87fab4a09129c9ab95c44703b75b54c9ef9e825928aca56527d79b338c5ac639d0265010f3c085d2b09aef0e4f55d080fb5ff79f13e8e4e8db020f4c095140d46a93f2e4811bfbc1393ec24f6b7ef31f13623df0360b1e335fc42098ca1efcd0306c5fecce942f6e299ac9ed81054fe452d3f63991da42d5680eef749c02fcba78db5f4f7c734c6b4d99af79711a0bab723c24364ac85700242878cca93465f286d5f7adad7f68f1d38cd6c6e0575a36f1e5521e420d348d947e745c2355fb5fb0f12dc6fb5e9435cf8e552c174a617151af8d5e7d469ad5cd741e16eb88ea6d7c5806b08571697d22a525c2e30dff608c921b955d2a990d9466829385de0a81875be564942ae740d15ac0af46a876426ebbe481738be19be06f174d975ae8dfb52a94af9a77e56267c0bb62169165ace155041406caf507146a02fb760629cc4c0e7d29108cb7c779455a3ef359bb6198ac75e16148998c16c9410dff2dae5f3c79da61d371992d4a151ba91dae8814c81eea4f78d23871326bafaa349c8eb57231b590f1ac13f599df5b39df36455f05e53cdc4d025410e8f8f8bb74854fefe0c4f790f58434309d36c1e7f3935d4f896368c91af95ec2df292ae3166b83976abd95089b05b461d4e9171cbb4747f3cd9bab04e5a3b98095754021229b4b820ebde63e463f2ee479fbfd83cacc61878773b129cd4b3e9afbaedb27c7fedec2f2d405b99933fe2c203d9949c567a7752aef8a7788d2375900e70315823daccd4f2a674196835c35ef813826b310346abb16b0145cd70fd0a04611ed5ad0b8ddfca6eba6b93445038c3dd23d3d15e8899f9c889af417e5662d538e466447e514a8897c21fe0be2ef18948b66eb04051c0bc961fa485422a66d649dfa86d4b3dd504a89919a9928ef96fd467713dccc1f19ee69ce3935f0416d9c5752b7dcf9272d2db86c3eb6f4897d94ddbef7c483fcc66232e535a8b0a5aa4bd443493fe539a32d433d9e89f7758db5b0606a96455b39f92aa788fbbe43cec8f1d36fea3adfd0353ea5532b49a7286381d985e018e6534005f605bf67ab4aaafdcc499ac0882fcd9d90bd88053cfdadaf466e536f2ffa7f18b3dc254e42fffc777e0339181473e2b7fc844b687eccc0eb543a54211084b1ec06b0d9eb0a0c96b88d6585f414873c13ef7002af2d47d5859a23d12a7d401ffd4bcf642db96c70fdad0cb03a6098437795bc9c7c6c804a26225eaa53f52747f01db4e62471a21dbc1ded9c4de2508812ab11f61f6364fcfeed445ffba549e45e641a80fb4b58ee20677c7d6cf0526dbf4e26d9e5afac5429b4474dffe709d09d766542d65e668d59c836bdfd0f78b846bc412f29da00291871d94bb5e6557d833c8db3d9beb37888c3a70684adc6b063fec3d847c42e0ce20e05482db165ffac5d1f2c661b9db6d19fb3e8909587351b25f2c225cb26bb137bc52d04ad8157f7d634f29a3623b4eb53b4ef9a78945280bca8c5e1882fae373eac69ea366e2f13a9fea75a6b7eb5cd4d9eb14f68a231bac780f84200146ce7795282952382e2393f0c2a99de830d3aa517dac4ac97f2aad3f7f8e3b49b22b078e3708c9cdd1b2a2a129656066c0030d747edd646384611d4eccc5b0b9df4852af7bfa94f6dd7584f6285ca2ea7ed3f8decb534e6d31d7165c609fd9ad235f5af8e4e8e58fd3d248d822c2020000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 49","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000290392e522b9ecf8f50f6ecdf24a6f8767a4176e0789d261de37daa719f688d4a36e71892a36426c2bdc6d7d9c32d6b55db6e410d3fd75844a52bf98ffccab5048f1f77609fdab4bd018693ab288e28fe7cc7d23ce6a1233191d8dbb2079654dff6e65ecfbe75ba6e34b07ea52daa5952563d153cd1719bfc480c137c4613c489c1613bdf6f57ed5c8bcec8366d059f6ff0d49a79cac3a03ce7d84567b337c19cecebd5951dfc58aebcecdafdaf38b622390bc27256cfecb618566355d23aaa5f72729eb51d96dbef13e983e2a9214701de760959945118b3354ec595c76e808b677f1efabe3107e7eef9b088ab7741afcfe9e96645438497f749b025cd1e6e3d201dcf2cbcdac95342fac56f256ef7fe1109369ebb4e81df503559b549ff762a6f5a244dac869d68da39cb69552af89ca484465e06163275d531b97c2f2b866217c29a6ba4048caea3cf3c0789c3c591e22acc26f4792e5a7a87977bfaaff4f9a2c99e412c73231fac98abcfffd06c8a09dd6869a9e91b217a2ece6a1ce3e4db5731b1a7e1256c312f993f3f0bba2516667104df46df483677c76780bfceaa066f4bb09bc1b7fcbf7a1f91ad72d3633691e0ba6fe389aaadd155f865b21f0d375005ed7ed4d75d7a744cd06bf18b791e89c29d18edca9bf491cf716e66be7a6fa4978c50ca52e77bbd9477536d385fa41acef2220b7225ae5eedd1f53a44c3a2390e29e5bb77a823966db91fd932e08dce8e4b7af2becd0347ca413cacd3f128c62c1114db9bc56efb9af7dc93150b9f3726bf794a8a373ce327286b1ed74652b459c4697d3c5a241332cba40627739dd536bd06f7778b79bcec6eaaac9355c425a3ae2ef58dcc0b1ee7d9f632d9ea9df1686b9bacebe94997a35ac504ac423a090b0a47190def26acadf09fe4319bc6a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109b3aea920d9adb9b9169b68eed40229adb7045ba67f403cb8f1e24842ab2c493177db5f893634e0081a5e8db24143f102107588bebad4521237b449a3a8547a935a029a7010c132edd7141c1dec97c905864d09f47d3cf3685a15631b84bb1b24c58f226e6142d29c425e7ac32193a0521080ea83f8df9186a120507969fb7a9dda6bb52c7870f4f14b82ddcb2bbc9fa7abcbeb6839366aa01f4cae7ef321682a912e5e3124a1952e7c88bb958f594705ba4ca5fda37c0f9e802405a171788935169fc7665a748209978830a63869175d0d36af40b508d64d3eab79e227d2a4082d6ddff6c785803a327e763501539f09d8c083dcd613bd71709900173a7686f598122d78f09c118c1c5ea7a50bc9e8989765f00cab0093eb28bef90553ac5e707d9bb0b78d32847129f02944aa54593e2b7050be865d6002cbd8913c040c441e13c327ac2ff746407f36898931358783602a0f302584060f70ea07d996bc5c260ae2e1aa55722857e013d853a22d31f249014607a58657dee5af2229d7953f9fe10a409722f9555f0c31b4a25428fd1709c3c9229dc02886a27378ccdeaca40f676faea48091043783603d224a91436a69be87fef39bfbaa5209de4eb09c910e2a4c19f3509b0c4addad1664580e0bc45506d961042c82da79825d9e82dc4d19a4ce5e34be581571a45c717477ebe669882c75cad47126a23362255167de619f66ca5675d87105e48500da661c5ba44c1512c82868f0df47b0ca0d9a9ace28dd0e2b2589882a60dd11486e5e50a6047b2f05d8388760b61bb52888cc89653e823a2aab80f248d2ef2018c91b04681e3a989c08a449767aa31b8a51c83490b389be2591b7076c18bf9d3852dbd46c6956ad8d11e8ab6c54f00980db27c867d84dd2d4cfa7589c3b300459febd54acb95b13c9338047e9845c7a4fd958c979ae6dab38db551ddc3d2e60d3e984a92197c0f61b275f6b93da0db55385739e303946c5250c4872fd683badc2783811d647a7095caa5e8498e0772611c2a7fd83a6bff867e0114c4abb5aa73adea9427d76c1f12952070bde43b4aa43762c9541e295d62e2af251d9d425f35788ac13d32665bd809c493911aeaf11b079532b66aff6b89a7549e16a216e86b06fb75a81e64a57d68903783f8879a2512a1a9400e0818d8aa662e05d2d306b5927e1cf2ae14fb9d8c70155c98901a29152a99d86eaca27d8049d67a5c7c63325e3794935599f87409ce91291f9c177b19e4852588e970000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006934beaf8cc3a7c393932cd37a2cd8ed790f05e4038adf1287e2acdcc0bed9bdbf92ce44aae95caf4eb142b858e1421610eafc47de566182835bdacd4c836f19bd686d53c3834efd928487a2ab3402c2e3ab3af97aa802b05223ca6927722c3bd1fe3f8c20f93c3951f907314896cd21cb99306fd7e5b6176945c2898b10c1df62fbb2680752cabc8980b5a0430be39d34bb7de9544bcccbfabab709c11bfff5c958c8763d8d5830235b49ead26c834e63c3f3f2d6ba944fd2688f6350ec99daf4cccc42c6be1cb19dd46514d71cb6e887dba80edb580b27f1142a20ea0d497e0336d55f1ffd4bb3d4b3521f0a01c7bb09258971d1ed4a98ec052b24776623d7b9a83c818795e3989eaeba8c9142a97afce855cc6ac0aba15f0546684ab5c2f48b23bb72a88b6af2ba9c73881103cb6fa99e3b03119eab03bc3b9bc365efcd7b9f49a8bab6a34a00aa8f2c88d7bebba808bd97111ebb192d82ad244e18bca732fe6f72fde5bd533e4bccd3f50332dad3a4169ea85c324d165413f10888ac3b21b91de09fcbb9b636ed00faaa669abf6429b78c3c04f239722f31fb0b1a20cb1a6b553908070ac13521df66772a6036e6695cf66b9a90e2111e499bcbf5dcd19744f43deb943445248a5e84f168e7bfea2dc4e1d0a87fb4140eb7c72d2dfcc27923206054cec870888a79938dacbaacf1f122b22ab5c9701d777bcf9809cebc9b7aac52468134fc4a92c2baa9b8c0f6249130a50337f460a42cb5364a5e7408caef8d12ba6934ab645de9832818f9db71f5eb0b158de6a76619e75245b56020e1664d8faf1c1782de4a688d4055e07d842410600e9454e28676d44357853ffa7740200c91eafa16bca21d0006f47fe8159a733e0e91549df434ef316e1df9bb97da6a2c2e2f20a65b3c00041a903270cbb55ae2432aee25c71ce73bc2322ccb8e5bd0e24820616a890b0851d825d79411c14948dcdf48776d72565422056fe75765e50736c82f71270bbcf229a7b7a45dc88aadf4f84238c896dab889e16c17db7be551ab24873fda82f102d0fcfc139c9febe9fa99819cef0e2684dfc5c843a6d496d8a595d33c51e1fde9a84059c7bc596d32d53e2fe046f23fefa51d13f9c28e227f5e24429b851addbf578922aeb0c5a61bbb666d11d127ba45c9e6378c70d75643de776483582e034e81fae0a3f029c47fb192cfa018ce1f68261d77cfc9e05ef19438e47f3de9a68c8dc09d07b1bdc6ced69592623750f72ec2fb8c5ca981dfb84b4bf0734377ee9dd8ef5ddcd96f438d30ab78f402ebff2163d43345ee8ca119f3208e21aa3a2185de967b475b9abfbc86465275f9a634fc22015e94a298e9c204e9786cb1ff14a5e99f942d42ab5df51ad09654083df0259aa1c26a760ccfdf4a276600c5fd3a54f210b20731941eb48a79435f1f86c45f8181d9758a1835721b87d36c725878375febcb8d48ed2ce8892db50965753a98f4e7110281db40ed64dd8eb51ab9ce41042589152d8cd5876ff30536f8955172a7a8f5c3f5ffd22c9954903136f781f0574f45f909bdf1657fc1cdcb9c4689f41e462c8d39108b10d78b6892c8775fdeb139258f8130bd1d2a1c72b5026506409f9862aa8729b35c652074494feb84a553cefbeed19d6ee94758e800f5fcbcaec19b6a00f33eb237aaa6fc0b3a08c1d8829c180bf95e7d05f919a929933b7a032cd20ace82aa5a45e5b2fb09812f36974b5eda1b387feb13bd49ac374f821341282c8fe2fb0cc5c075356833ff8cc6b648729a4298ecd73bd0ec73957077ac65722d0be23c1536b8db7b0506dae47c0070564e7d7f9444f47b22c679eb8aca4826f974a42043863e498e5301ea162c4e96684acc5ca26ccd083541bc4c1d2fd690e51f07fb08337450a204b0f4f2c17785e037424fd6e78746764584d5f19255496df1e524bff0aac31bde9254429565278a39ece4627c023edf18bc21bb523d44efc259742dee9ff7159d5f700d957ccbb505a88c2037629402c2a322d17647e430777b184ff7b4e8d6b94724abc36a5ccfac08e2479e8310bcb7a617a25fac6efd10d0a07248f7d4597f14309b8064fe3bc4a4479f905e832210d49363d1e5d58176dec9abcc0c5132fd6eccead2b05b56c96ecbbeb0b803e43db2f982ad9efe1e2a49649ed8e42707970c93615d54a3e673559b996e48a3b73143ba0884e918888156ca78f793dff990fd721de0c0b7916a5ced736e31292c5af062d7ccd83fe653294fac8c50cf6ba37b37d5a9bfd1e3b92d1825c1be0795f9b257cdab91ce99c0c51bdfcd6c0ab5a3bc6e30f884ecb4f1f61a3259cd279205b2c21cddb196360061758e67b1c3724f5cb6311eb4fb92e6c0d71e6d1ea4500000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 50","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028c391eaa6ab73fb23784957316b60078b5923b9c4575f6a88c5f5d0a79ae5566575f10008a55146ed70e8cd946a805ce788fe00d7a52ec6a77aeb35af66a886f860a40d87f7c319e5f21c59ae547cc2530c13bf17f1cb2f281a2308c262f14b5d99c9bedebf19fbf5a65466ca8ffeac92258e1509a496faed086575e9c1abbb0bca5cfe510827cb54802f3a648d1ce7b2eb84fddba2c6189cb7dad1439b357f663637c49b62e0db8b63a78245e4aae62d99d158627ac456c09d686930f8d4890935aa521bdff3ce8a7a7cdafca8ee8f53151bad4a112ae9b57e38dfd60884ac8e8d309799d6e607282c44854243486615bb44236ba57e37ac75bc179538a4a2f4cdbdc2bd72e06c9009bfe0f0e1973e32094082a9c8462699662b33762ec4e1c53b578721dc5e55fef79a0189dcc132669cdcc152490468953774db57f21ac120cda4195fd62d2e05030c4bd3e660d2b273380eb22d82cbd7255347aa45ca9f2db748bdee6af7732e2c87c5b6734b2351868f1333ab87b7dca8bf968d0d7653f8070745295a14e5012c65b955169dc7abd8b3720df15ae8b049950c439404f26a9cc5904dbd3b542cd501127f2b39543281d5816b1012117879234ea7d7e19bbfe70b5a83a8f748d3ea0a0db3b3d0517a1fb543f0cc0ed7e21dbf2cf56f3cb9d03a9c0c44715a24942254c26d52c6199c8bdadbf33866e615ed9e7787c8127cd0b6ccf05af8f18f95278b1e0594b064ab9915fa1fef5ead1fa22f1751b3c42f04ed1deefaae9da03c0aba8b8176f5b4e8f453e6dfb53c9cc92e677259bd37257f925bafd1d4f0e327d73d4ca2a0f7d872ac4c5fa9959852acad3df65d2af0ad6705e79bc6f60b5e0e898bb31313afe86ba74b3f261bd1387f06a73cc0d52016245f0d0cf592628a8c3eda2c6400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a00147a46301ebba0c09ab93070a7fe19ca2e20a96bd2e0e32292074066d4af47d8ec32b78d7d66c98d859960507181dcd468136078f0a2c9154c876a751f1953a3c047e2f0185689f54979ced5dd0c15a795602486e11913446d14c59eca257466db48c46638f1ba0491a0194dbdb8e578c54002ba26b8ff6c5828f6a382bf86e52dec9da1106e41143db9922b002eab88b5229700b0a43c85ea0c8915431c5e54d4d7d540a6ad27cfd1e8143485b2ebce3c34ead1d4f2e23cb371d2a81e6b5baca94c51f89f613d0460c819c18c4d7df026a549f130a5adb04d93cf636263d2d1c0b335752fa6ee09488d481dc959478781089d384e46ad74b8a6773b257e10ad56b0d35bc0bf007d3648c481a6257de2a35c535e12fea795ed0e4e883fa89444d9a4ed8382b390b65179ea4bc285987e70f6549d27ed242d0c3237e1365b85f882f7c2cd9c68c6f49da8ee56d5e2d5e5ddabb8b50e08e198807ae0f229fbe1868a180075cae9dcb3c93b25886b9d096a3658e3c21a846e04a7a189ea0e28d1c0f2e4507d8e8301d9cd564e69a61b18aeef1c402e7634a1165c5a7b65315207ad707e61d8517146ca7b72cf8bea8440996b4f2399a6b28556e347c3304680c2a8ef890f768275be1aae589da642389e089c51a54477a36f3f6c8b746685872ae58c445a4d08a372e696b70a8f9c94ae146ccad63378f0a3f9d6e4963648123a130dbc6063d4581e55b9104979f6a25f215a27b871ab6a5ab68fb1cd58b23a35789151ce25a394c980af28f96271422320c9577130b3b527a75e72d950aafec351b9f8b8933f6b211c260fb71301754e699541cec6dd80d2b95425ec2b475e9744bf173c7de8554beedba06886c5217806025198a8273021f9be6959025cd60299720e6a0a6caf5e6d3e439fa0a912604f8512084e6b0e5d4340cffdb6340e28dda847be097a33dca1e9048055a5820fd36976c595f64c8a437a40660982f493b53943180acb487c9896d54d71be6433b6f584513e3208879bdb44bfa58524d9e402283096f109a0bc9ef5ce65d0e1bf5ba20e5a6b41dab444a02b8ca41725da8d19d348f612a89a828c1a2881bd66613a1c3f20fef591285db6486c2791adcfbd0584d2175217734c38bb6824d1a220e66a934d950500a01ef0a313d9bc0edf5ad2d68a2ee0b967d0a25812586e27646b4743bd7ee778652321acad1099c2c203456517ceaef339cc52508d63cb9fbc552629c0f1b80525621750913e51e4a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006b40bf9a7c0f63cdcf3f850ed7c5db6191eeefe29e498a19f9d89be4698821abd72edc34317b4f8ec2736dc83c24ac195bd55aff00e797a83dffadc7970fe53304f16f5dd92e6ec362b9e283e41ebf121fb2fa2a3f60124ef3ebf836ae51fdd55ca9f59b085ddd660724c072b86041b50a3a446cdb20a45ba65380adf007e005df2d9aa16a9d22b11dcf6f0b1964f04f45441a923691a15d80dc85003b9ae281f2b5983dd1a04d80a4d9c4372d9820bbfae3af7735e7c71e9f085c0a6e4bc107d9e4ba222b38fb236b2cc3a19dd6067beac460383ff2bcc771a7f1aaf092fc72c292fc1d5c6fc6b9715f1e1272eb22f8e0b33a2830e31bd6c531677902f6a95cabc3e9c1ae36f77037a785fea355137a581fc14e6bd5f1f7ad1a5dd19dedd448b47b558c22dd0fcbf296a812a726e7d1b57f4688d3f577104cfb15fc63c27f7b6051c7aed7d645186fca63ad9c2d68bff442466eff76bcf0e398d2bf54c2ca4cc614839e9bca48ab2cc53865803710a98d313aff1ddd06a65680eb83c640052db807eb2f38ed0cc211128044d331fec3e6b0b2f3b675c631fdade62c16d1719278413ea3f8e54ba34ede7e73f3d94802d2f9cb9794d257c46679a3f00015945903190b97071f8fb55f8696253aa3f39b3fad344fb88224f5313b43889b768171895f7aabeff25e21e525ea01a996c764a3acf12bffed08f3f751f5cc094b50b325f8b62c7a5b3256964d48543690538e634e5730354358534b65eddd44a526bb4b15e2042b6210f503eee06d00d615ccad10d73cdcbf5264b526674d85c0ed31ba5ee584f21fe6d13f883ace4b094768865e43099e54671240e8e2af8a7d7d22335b3974ce860e7238a7c1ca8a009eb51c8636f0659189ac8ef01c871e9008957cece0a367b63bd2852bde8690bd74c6d956435d0ab82f94a90cd00fc840dfc7036b84d51f1ff5076ca0974db6cf25af42ef7dc8c30c2b04ceb2510e86ffc510bf4c931639478fd1520ad571fa17958ccf8e37f5f6360030300ede3a33871e9582808bda2233996c5005fd0c23d99261f570ad9027767f6fc96d18ba98e8ddfc2b79ac12cda5f2367b4bb6b99a3e07b59882e49a92aece85339bbb18ab9644d20a3b2a795240492ce4eaf09d9ef728fb82b1de7b64b5d391251ffb0699335ced8c7ce642ff1a79f04c3ea0dc37ea101188361afad236eb218cfbd1d0ebd784ce27dcba0266ddeb87b59b66a4f75bb44665643fa358dd3d0b69b49f45a752b5c410e2299a62be4b57b32b0924a069a8e8c15d754cc34debb0d967e70693a6ffa58cf7099c2c2458b437c7b205cc7e815f6cb494080f9eaf3017e5ff918558dde415ff72e954ebc2ed4c20c8ece38cc916060d22e582d54f74c6c181c2601400110a683f4a365e45ff1387bce4e152a740136bb762b03a99fb68f6ab42620b2e3c00fa8d150944230a6330409b27e4aad1693e2c3dd12216c4e2ddbc5e9cba68b8b5417a7b2edae7eb67d25f4edecbb087f93dc9c927c33076b1c71a2b83b33870d602562ed378805a690dd2a427d86c2c46ba4741f3defeb91a05eace975c836e52868cffe52ca92f97de94768161a3e953bab6a28016782909ec53c02f35184aa9ccbd5b793b525204b72deb63e104376893b9452c3f2c492f423cbef1ec87c85788cf3073ffbbcd67ff79bd038672943ae4bc68da131dba8d7b41c83b4e9cfb6931987b270c74919bbd40612f823114e4bb148671f1aa62bd2bdfcc8b0b24010ec112e883aec9746d0f5de467addaf51f8c070a359108b1f91643071438f098233ad9a94d0faa665a39291a98d14a861905ecde4755d00e690429c57580dcb6d51bb6186ce72ebb1fa8413892cafb8713e89775013e546fda30aeb8af9f7155c08b25810c80ccaa5e700c124cff59fa32e0293adadbcc7b1a99f67e66b28da614c5a4ccd706afd05388c65ebce07a543d3dc1e5a5d1f307f675728d4c629a04e9e455b4da35236c677f26edc622c1fbf29568d509ea0690af4cb5dbb4e418b6162888e43b458774a31324bfd5ee8d2152e4ad43a3007d7d4af5fda172c2779837ad3a09e135de953ce966727a7183bf77adfc76430666b526692991d3c9db5bb377552a7801c548aa63f6931d3ee91b875cdbcbb7441a4ff81f86762332d7192fbc2f7b69a58db6ccd3558047f1940a1cacd6fa28a000b9795a2860394bf05f0120e6d85f96b1fe9de14e3ed66a31d747924b6ff2620778e0714aeb34b79a5d935a0306e55c36506a292c5dc568403551907e49a43a6263d2915108916f1e27cf3529d1b7bd1544af83a7cbe58547f192a93ce5c5bc6d652405ffcb95345f522b2d34e8ee0960bb85537a46121bd9a408d283a125eaa745bbab04e2231c19ae95e13901c69e5c9c4d70b104478f4a70d64f81269a8000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 51","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029139d84e7223256efe74e873db962173e30471dc8af2ae4716d552a4e1040de365200f150c8a5244d05fa9d72329d4b58a225071306b4b5da50c469a42b1bb876514d41e08ceed24cdb973bcbdce1a21ffd620e63f732a5bdd59070aa84c520736e07c15ddecb7c038303b8a21847771aef94bffb9293cec4bcda2aac1b8fae23e8aeb90475e6665bb7d557a6bfe53c84a41b728d7ecd4d992d0c59c0fe2472c8eeeac249eb6eda1f4e58fe193bbcda3ccde94f178db428d13f2eb7f708ae2e4dffd39e886facdb0881e4ba4b1c0c8a21b263b4123cf18e21fbe2bb05a52688df7f67afd143e877fde54300bfc6f06e5e3719956b1b872fbf1fb7ed615c45670f86ceb0020b6c67ad3945cf398e3f12e4bb54c1a4b01515af34a4e2a3e225e16f801955715899b2bacf22eff74d9843b690d94be1ead658e7c84da7008fccd1f9c53a74cbc04af5e1455a7ea2088b736b13ef43d643721f8cfe1220c1c3869aac9791092e60894c48340880aaf9e124db2d5fbd6abbe0e91e833ca631fb147c6edd19a6cd8c59b6d4ce8ad2d94cecafc1999cf3f9d6ac820d2735fa1b11b149313a14854b5a9f6c839eb7c3bab0c671d9c1448cec3f58d1292655889da045a635084a08a9aa6ef53a342dae6b74e85f6b4f5df08c3b6f569fe461c40b32272fa6132587a9c153e319ddc2b9ec74ce3b1db94cd2b69d65cb447b3d952f70219bfebb29883b4e65371d961557fac151ad76fb3cbda1c37e70272d9c7174065df688b0fd1485c5515e341b2ccb7ba9d664ee13f9cdfe0617ef3fe6739a1ed042dc677a22d9b9cdd755ddd9924dfdcb1957bec922622b7dcae5899a4591f39ddeb347e67d3fda89761235b79c237b290c3a087121491e764ef84d59f9f41f30d0e6579c3b0d68f7b9b67c0ed1215e68705420c12000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109bc3573c92d98a180e9a943468c0090049c6b7d0f1c3dcdf9a560a5e1790573c8b18ceb929a2c95045ebe243c19b2d30d385294f96a5d9559bf06ae727f5a8b2f164a59e324cab93c4966f3471d9f403b04914baf0e5e26d3d79e1481d298189d4f8d8579aad6b35ecba1a4f4dae35388bdd44f85e6c37a5678035197e01634554ff03f57fc27da6977d89dcd37fe00512327352ac95a22ea2ccb7b4116428ae820a2899fc1b41ea58dee9a3b28a70f9559e1d37761642c2a0ad83d42ab89f920a6b6c58678b1ddeb3b62d084e0ec000c8af94404637a6a502b5ccca89ae308e28f3e7af1cb2be41002269b442e0326d8d7412846869f51d9a247c91196dcfaf2835bbabadd02c6bea7185f6e9ba7f6dc50bf79e350f3047f5b96ae64099c8c8d6c90946faaa73eb86759f8c07216714a872dc65ba190b8985feff71d89a53b005129560a650806ec0304f171ebaf8de49deabb982ed6da0d101837b8a67faaeabc6391493332fd50020246cc41125336750e043b662c771f675f1b3db378a34fb779e1e359be856713142e16e3aad7404c01948c9db51a3e97031298b65b0c7119386058003c1280b70670927c73730320b813521d49e965635c46562b7045f67581215abf17a4585957c0966c66402a7668b35d54a255ce04fd8dd29a56ce462f523698e8f093fecd7731dc75ead22e4f24bc43b7ebd584111e368bd066c77775d9676281cdbf5a1164ceeb8f127408970dd90634198c4ae965d3057ecbd73ae69a4c000d4511097c74818669802a0e7371b58012c6f25564c8a7b61df094a01b288756a1438908e21a672da20a9271231b9f553133935b4bdb1119a09b4d6f8104261ba0a1912f611e48f36766b4aad15b8385a9d0ad6ab463f3632b0808f1d43591f0461ed683145f500914748192dfc87da65e95684d9f89062029cc9de8a8ec37d54c80c77daa0985ef553058c21636b9afe89069bc317885689bcd0fe51384463c0cf0e5852e5c6adac53905506b7d2598ab2f990c2f21f7f573abaa6e2d0c61d5eb8d70adaff02be0140441b090b4db9677c0ea2bd392d318a5b0a1b39b1f08026e415d5e0e09556c2a50d1cb9046891423d4a7599a0e98a0ae3a952a9df557c3c658e999c77517e8ac6e6b8b71596a2db8da6446d8808f50dbeb1419319f748d1afed3b3652133dace8613b675beb5685db82765a3a27b6f5c0bd53388ae625b923196a229dd17aba86122c446e600296a6a10ab1908a66df5e628e30000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006d5dbfc582ae98d8fd326fae96a1849efe729a1173339d90c48c3a2b867135f1dff5b497d05fd55130694b5f9c62d136647d767ae682a0f05c670ceecc03475ffd39e0bd4e45b720d9d7e8dd04e69c969627682ad83f48609f6e66d0be99064988e4654e3913b7caf1475622e211bc247b98e5baba1b804e2bf651713197d8a610cc111ba5fd98a053408ad155dcb756d28a283bf3b20e6f3785dd5f105f8d7d9f2956064860b097c675630edee1f17e2eb0b26b6c20e260f9a5915d63f1be2c74fb0b37013244481a2d0c581c4ee12516e0fd4701e9835c8526a490cb39e99fae07c40236808f9605a63a5106c19517c3711ca4b9e8eddc77b242575d904dbe64223cf14a8e39feeda9d6c5f9cd0d0719a7eb5efa71453636f78cab8262636ff1e136c787e38a43faf02699c1f260ec45b068edbeebbb8a0e08ce282bf47d27a33216856f0c59e743deb13397656ff17fc4b3c694b189c35e516be719cda6542260d1301df93a5d93ee118f7cb0ac94d0364c9ea66718a4bc7f3d7acffa60afb7100f7d97e98dffe167d1d8e46c912d41ea057362c13b078cb1d9c443c1a57ac18c4566f5f5388f47a40ca49cdaaf34bd4c9a597ffbf7ab20d7ce88dd76a639e09ada323c588b08140e9350268c1ff76079093a05ccf5e1613a70e6e37cd257875049a767332e5f7420f319f9ac78f97c0c4fa40b1eef8c8b48045c78f73584590fe41f9f274dea838de75dade66d04e9d9308cb0a9948320d28d9ca8f1f51e39ff3de20fd5a2a267d127c317acd51fb779e597a8dc7359d920548b8bcad761c6b8012304e12628a2652d12a8161e538c20d582bf567e9c2b46b4cfe2d2da31120c6df50df45c80513aa9eee9f2613a221aa1d23f861c7f26aac7813b7ed7278eb420a5c44f2a5879a2f1f9f11e14602762e3389b152c014ea9ddc9ddde9ed1d6f74e7526f690ef37e71d448342c012e032c00e480a699ade617434c12da0e69139d0d9036743b9e2b9134b5086fcb96b193330ace8e4f77148ad0f532e72e1792795080b54d7172fb9af1972d00ae24d0b3d86528675b3bc8c7b80598d855b95a77667ad0f671f00039c08cc99f5644bb006ba9356b9c02bc935212c43490c741b0845cd7b4247592374aeaa1b589e670ac62777293870963b5132dcc27088f5da5b831fa570766fa81c2a07b88bbd45b81992edfd2a7fe934219b1f648dd8a414fa03eafcd39e72bdf7d4f6b9c1f31a0a67df03f6709f2be0e7d1b1690c92ce7b8c6b1054270d796b16d6e445d24cb11229cb0f92dd81190a37838951ad28be2aeee6c5f63da60a911ae0a24b1d05ef2f814fb30aae8ca3bd9f01d4fabe5b279142af948b0e6bbccf7560107c161c816a0d8e61dd908445079baafb78c14f68b8b2bb241fb03c237a4cb250911142d0b460acc75e6b0f58bf28546a4779ea7342238826f636a510cc9cffee8bb0292a58a07694c05672b560b26158a8566d01d0eea0773e81f3f84376b29ce375fc56a0689a7ca5ce94b91814b62cbb61ea2efca0ce6712a941d612b0f700c56b46d464c2aaab3f64a89caa8561a1dab2869d79da1720274d031946c4c7715fb9c243dc95cca7aecff55eba4044467eb922e93f57e3e39b93876a03936dffdd2af48d055c6c188f2f229812ec94f3fbdf7d7db62e4274dc91718710eec2ce034aef266207c5ccba21552d6fb8ddbee8e931067010594a9e0cb37250f67281c0a369965367424d454cdd05d3c8f35a15f76b4c8c3fee42f4c9cad68849837ded3be58730b94ae3a5f9146f90e03b4c0836381b3f9ccb5de6bd2455d241be9132eb6d4937ff27663f4cadaa9cda193919f4cb0d0f727f6c7b26e831c3ac8decc234d79d1b3bd28305e3012a3733ad718fdab7dd1a6400bc47f47d20f627d2449dbff10e37a62299e22e408a28a806d403cbee19aff6fa9b1814b35b9573adc86f829a08893cfae4a0212293447d3086e21bba28049f3ed383519917b169e8a1b7dd64cefe0da643a97950a205cbff6bd9334180556e84199f0b60738715cd69aad7c882430578f6fba4579d908f863ca54d0b9862eea6abed31301d183cf465b1a256cbd597a629307a8a890f11c23dbff895b932e9cd2f5f06a4183d6f2d61117126fcd2ce2b86bb44a9a5b402e3eedbe4ed1df11716e91a2302cb72d8f0dae132e16311c80dca041694af1ef63f659959fcaa133d9e5668f94d0489311af3bad379de17793bb3ee8a284529a72cdec474b3a82d92c6cb21c63017f262e0d7dd47aa5c58f5e23f8a37f00d5438717f05bb974f18a5d3e1ca054ea053c30b34fbfaee88bc0195f061ac32f5b71b2a8a3ed4b8bc4edab40a6396c052dce72e10768526c00610e96df38aa70938cf844cf445d8e2bf73c4f32a742812d8c1db53afc6b6c0a4bc67c3cf7579702312d6c89bf14e9585d2c624d07feb4b5b57f8e4c5cfda69a5e922cc1e90000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 52","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39f66d8816092be48b7b5671164c056c8fc2a63ae8a966842adf7f2e8094730b258024ad78f144b0a72def33c4848746351b892fdb11ca57bb5ee817cd3dcd448a340bf0490ec4a79db1a820a64e85ac70373ebf945c85dfe058780a42dc4b66fb220bb6e83b78af7a3eb2cd6246cd8c532c8c760ff96023f2942b26e8f264483a4d079ecbdec587adf8e2d02988dc3a3a1a09ed02526e4f6d2a56891b373770804cd2862e2eca899b6dbf8af460ea012bb4c3706f5b894e66b535f7cbb5c178365bda9b3feedb4aab886dbf55e4a4281feb1d154933362f74b642e060d6874a7cc4169b2ce71790826ffd6ff6c1428bc3e97d52d170ec4e1eae8246a258f6dcfd7d4e02886f39781195dca15015e200acf5d74c86aa8d866161b272bdc4257b06cb3540a2a64d15eb49f975e18cdb9c92aad8445114341a640141e4397b6ddefc655c4f8e9879d4e62bfd8de1aa77c2d5dcb1db1905714e6f1d1905a0d05cd27736693b28fcbb677762b1449f442d134b99b8c9103e3c067b3cc7b7e8ce848c621d4d3b098f26f4a6948c7614a779d6696658b51d0947bfc3bae4587ece4ab578e950ee7575f6fe7c673066dbd06745a359a9402d5a8d9e98c0b239260e330b7fa02c99584e08761f55b771a4126234b757e36fec04a97ff61ae3b7729e772a123afe80a46a3677c9e99ae0e3e312c424757076d898ddf56972edda3f209631dff8cba56d48c9d9f38e990acbe0b8ca49f1f3cb2932362f09334850fc160f03dfa42968ffa58e8e427da43861b5e606379dc1466d733bec159c5fbff694521ddec52db515df4724c9671b169b4dad5ffa1f62bab8fe69f3194f96cdef505d42e050e9f2432ab2938a921e39112a01ab4a769847e66fa6e27a95783993d47ca934e303899c2466dd32aacd50f40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810953597755ef4befa2567ed3892f3d0ee9779bc99a0363d1bc75ea58f54dced2a5ab23434f38b0d3ab8af596320cca7c579415aac3f4eda19a05527667db503ca552cb88f39f972aa4f57b2890c06a7ebc65e5dcff5ee2fd43136c6a0a7ae6a3bdc3c709243107f869741539e90981c5857daddaa56228c250d461c2d3d3f38241f94ab9afcf4d22be48d1efc38bf1936441104ca6c4d5a8db17f11ff8d90ae2eaef37f202499fadeb9f8d60ca42c70095c674d2f4c7d2484e8b12790d944812a97317eef72b1a2880055f5419b68b89524e941378b614cb5d2b882d740a9c0337a2018ec61622903eb6ca6445eed971d9be2b61ddbc7fe629f27c94eaadaeb763e68c5c034ec7f11895a382ba788302ec1866d519a511933b023a3c9b5e0c999a91659a288b7d3e91efb5649fcc61f2e88b3106804e1e5a2abf96c96c75093b24d0207c0169fad4a4c07bba34407d15f5541631f28e8f4f59b6a5e8e392e021ac27e01363eea2641e07c54ed62c0cb51530287710c88669db9b487ff22e59a7df8d7fe10a572c853143812393da4832378ab0228768204125f20380868b22915e725027200c5dc540ab150b3ab68e3a43444054b4b18b54c8c529e6be1aff1e589c929e495193a9bb4238c8de0a0675558e21cc152198d8bb781e62257e61427b878a62752e28e56ba34d0cb9b82488a763379d3015faa4f2a3340806a345ba913efd5374c6620b7dccb9e4116dadb844c3b74f42141cc4f50d26b69f622d0297d7b71f28451ad42ac63f6ef3973ea457176e9e303c95ef09e976522727f26b90d030815ba387c6c35860074b4ab1c644741cde49166458db1e165de9eb338f228610e2b8312b121163c2d380a705b06f4474d00029fe888169c9fedab5932899fa3e846546d618f149caada2598f23e0125c92680e602dee4c694132e53ba2af0e041e344f9a933a82ef18845cdb424ad3b816c1b08ab639a1690ed453c69c8a6e87d73e4519d07a049aaa7c2d02494438bc51f54ab09aca3cfef9a12d4b9c54c140486a048933f43737f5522b5062915a324ec9516698e486192d4920e1f58d4fdc9a30fde3779b88b601826801ab02affea199c19e7f28b084b8f4286b30a01b8ac62cc2b9e23913e1116427a85a15a0d888a6568be315a44d8c30d9389d67ff6d68a2073268488f720e684e56527275a8453a9f0886503eb7ab17c38a80a38a3d930267c11f80e70670806dc3609e9ebbb50477755c65f983e29cf084dd1c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006f66103e5b22f934203b5ca87337095c9a19267afb9695d309beb8a557bb7cc90332c4a03e1d416d397b945b607268f545928104cffd71b02864e010b666cfcb68b762fa5ec839b5aefd0407419441b38e6d881bd5218df73c675df101bf2c53d90ff86d4a3c7db19ec9cac044e0467a36337aaeec32217faf86cbd7bc2b663421754cff1200a8a66e18f812868bc8d1c8ca495e6462da4b8b96d4167f040f04927a7c27ad35cf174d42684ed55ac80d14cbe4cc2570642ddec4f44880d967e9af77ee27d0d3dbaec9067fb6fc957ac4a136c1d564e17f59ac4938d43fb9050d810989907125c47fcea6c162c723e79f68339cd1b3bf596988bd6e215271385cd50616868c6bf40fdc34bd30e5a00773e2c039723f2ac3a3fa45f4ce870841762d7435bd6ccc5fd3d58fe059ee455a806fde89155c84797fbb73691a1fc6921859e99066a3239e31f28d1a46100db1917621d9e61473cf1e71f9850b584b459d5690941e676a7dd56796313ed9abdbe03dc75afc1430dba27fe0f8df48ef7c339f462af1a6d30a5f8b480dfbbe860c4c0bc136393c8fa0875af454273c3cfdba7eea44eef1a4060136948cd98b9d2c19aea4934f3455f31dd15be6545134f17a195b6bc409159c0975e592a15e86ca4943ccacf4b46719a072db8c629b67768f1956f8158f179a0b645320489dee404c8d0c4e786cff39b324053f102c118e7d51173cec0fdd017f213b2b07ac6b2c7dec04172dd5396a020edfb74ed86fc31952d241a7c3d139def543d90976aa70599792e73cf73ad0bd4a359bf60dfb2ce96a784d8de5e23a95e831ca6ffba6b187bc5f29a7757185ec06ac882572ec6283a1875b54fe4f295e1970bf311dbabaf9f894d3364d68f529c4ef9030ab934bcb09459d5aac61919946fd28df1ac85876f979e8b8528e9bbe69f03deef136eea6a8fc86f31bd64285c8c9f49adf53a8baa7867ce52e72dc4a63929df3ba2662dc77d71f88d8af42b8d67ad54884ee11f5a6b3b794f7d5610909b0b740937587cf475da903159994a262b6f32a3d1723fdaae65e636b71cb0ef0a744f359bf08ac8231ed2970ce8c451266f703da3b57f85aceed4c1c174c50d9c226f028e972ac124faa6f60518699cb4c499220ea51a538f9ede67d0e98e1bf8fb4b24b1d8ef50a28a93e20076f8fb812cdab04871d331ff434ba66dd4577b18dc3f471b3e96a174b58a7ac2470eb8463a71ffcba2d064470fd2d4e15f9491db09df3e3ba376a3ddcc437312be5848db3b9079f2ae046798473bb970d725e1d7c6fdf405ae387dd7cc1735a7fc27d1a476592a514b87c9017e1e5d37e338f37916f3c72c5f2af75185b88694d4e8e0a93fbf20ce81a7a0c10d55737b6473fbd92bbb39febc6167336beb9c235997796b9c0dc18c353e80305175bb412acc29e647813d0003f727ed0577a7c14bcf67173da569320e887bdc8f5ad27fd8864261e802a6753c6f9bac844b5900ed0d4274c0e6ede42367079188b10bed5999501164fa4c5a818ed6ee229c3e0e0f7804b19eaf5d1132be1d7fc18be834c842b21f8ddb11f8cfaac10d2e124981ed698ee7caca211c5624f09c62e1d451429048b55ed0f8a714bb77a0d4b40f0a446eddfb27602b7bf894805c4aad9252658f6b21a05dc0cf6a3acdc227fa867a4e5b1db63a14de26a79aacf1900a7b7d867c15cfd1daa712f2a1e2a6c7b31b121465539cd0164e3ccf79a978b543ae9602996448c6f68069d044fc958911ef40b0b9afc78ed014d94571f6771ea5e2306a7cac32c135fec0bbf1dca3cb0b57daa239c01671718017c907048e0d19515cbf430d4b3b4ff4fc9a391d15a38b39c4e528fac04ebd3dc69144c98afa75102d21ff961bad2e1f25562af92554814405c4ec08dae4a0cd28be592c9c9bf997cc0fe31502dd541000d4640d59654d26ca2a17ba4cab0518ee097c05b2984ffc56e8182368e216768e0d07e17fb64003e95194d04c6e00e08386084febb6cbc841e8f3fe2a069c45554bc502c27591ca3c1dc9e6b1694ba2c1bc0713c1cf738db22ffeeb7443d72d5bdb975d192976a58ab33db58f5dae497a0b24011e15e3256ff124dd99af6fc300d1fecdcee18dd4fbf25e901125d4e80efa8e2a211701b74fd992e63376996994e054cc00e7e1de7db8e7d2898a735ec4920dbefaaea66b456cf6a12324c5d56762313a627b3523ab1e2c1c82e4fbab136ae4395fcf2672a58011d96bbdcf2a7478305756d66b30a4ac44e48b18a5964aa89f14187ea114084d52b4ba77755ba04c34777409bdb782b7b645e93b4db284525e2f9c9c38d73b475dde2251277a2e6c3183d5dea78414e22cc8fb4b2c7efa797cd4a87ac81d3242ec8d2c2efd6bcfd69c39f14b0b365f3151a96f75454a3a1400c76a4390fe9f2e7a22a0cfa687a5bef1c905d3a893b0dfd35bda184f25e62fddc2a52b6a67e76f550abe4cc8d1d63cc8631e4cc315e46d3015c3b8636b92b8d07075d401c654fb4a00000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 53","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e397521de03da845cc38800822d3290ab28ef5e12dcc184eedd6250f4d0cd9675b225661e403ea8dd4f0792da0ad5d3c1b311b2c3c985a9ed9c1a10dd9a058e3e62cbdf7ac596dd3fa55dcf84caa1288331b180200eaea908445bca2fb7573a51708190c3162b54023b536af818559a593bf06ce9aa04dabed11367f33b02f560d34edab9438a47ee656a2303502c3833377e5acd12c12acc42ff76a5befdcd5b2c10c26cb85e39b2c512af5d855c7cd2a725cf632d3c034b0a37571f26fbc12d82a9b19e4993ba6cebd0bdad713abc57b0a44e6f52d9e5ae48eaa54342dab1856c8c5791115a18430b066acc367dd990506168e31f9ebc892c5c9b20ca099efda15f8d06231c8998efd247a1d3cf1356c61178a8c520ba7cece502a0613708f98516b6e5637550ee467f80c5236830c6d2dc4e1f40a2d692cf7e0b9eb223f84ddb2744febf92c67c8e400426c47b7756475a26f9c7a04740cab47caf3babad838d9e27ada4822c1bc1923f356aac82c091a0e9290edc54b41951f4abf3ef39c9a4d681b57bc9065605e56275f3de7aa5d2e0c1bf1a2905ad3d8294bb14b4818d1a274788ea96c4d9c863730b741993e5186ca6ed55c929868cdfc71015cbc5fc689b24d67f2bc5cdd09e0721d4af2a798faf0f9440db82c1ea42f51a981c748bb5b891acaceaedbfa3eb72d32fcd24aba6e165b32e963a70daaafecf20c61535f947cc31b4ca24058c8e1af8536db64450a91c8eb7621852208a1f483b7ca91ecd063f39e63148f13745a088f6fc49da8e03008c634f04222f0aaccc23e7335f0498cb76ddd55b94a7212c8f22076123481a0f7cb4605d4601a9e044667406d48fda770e0cd3bf47e596dfa35893c5ed1004af1987f224fc79161143dbdc331cc5de40ffd64b8db2c4db79bc70a8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109501d44c55351056f56e6cb5356251c7a2a17ec22d3753d94a7e70ff71bdae0e88c237f1a7405f312abf7b8cc3e335c6b471d4548944c1dc2a0b6120084a7957749414a430077422e6c259b80b54d51d8f62fab3e56cad24b8947ba4e4e2680cd871f58aaf4a463ef6b52f90e3b7fc50e576a93a94f44b101ed88ab0a980e86f4b3e3cdebf1931c2ad76289ba817e59a3d1a29a3592db572d8b6763010df92ba11451faf15b2592532e581ffa6f0597783079300fe6b64ed0e2115dc5e2785434b1188f3557c1add755919a65fa8fdae35a271ed1dad8fba0db260d36e7dca5396d8cf43155cb102dc623e836020b61f5cc8a41472170aecd62b854566eddca71d8d3d6a200b7cbbd844754a864f80544591ab475ea91862f9dc635f82e902f286effd41f18a86f1c9f38c1c846b2e4f2133f5f379ca9304808e67a134d9e0386af3a957c79806a9643925036204d9f5c2eecb070dfad3c6dbd845205e401bcb290a6eadca59bad3fd0f222ddb68405a02455f5485ab18089ef2534061d87efe360078de7b1595bdc29f24b64ce5dff680e4708fa4b328440da1a236cb9469132fb1da8754fba67c767ac2070aa2f666a8918297d66d41f53be2270c3b0baad4e37609869bcd92e3b566f76d45bb62078277985565f93396647a74b5f9a69559482059fa9a95b85dfd24c5e208f15900236b052bfc665cd7dbabc5c40f78908abc181886710128314df5b1cddc87a514d4684a1c710644d53cccb577a02a67936cbdb0b2c1879e3eedc25117ad59fe8f19c7cf8f5d999005229944a29ee349ae8e6bb85131910c4a3857b4111945110e7a298b15b599f6a8e9c31310aea43b6927b1455ac52259f259cca2e8205a219bfe16f9107284954b28cbbac4f1620c6a473bf8f084e124bb219cb42731e0403562f5027c9765572e06828bd95a1c45afbbe957afa7e2a11304eb6992e8ce7bef196328698b722c45bc3b6ece3180930a56b21f970b2af9acc9cc5425a83c1c184aa9364a4a5cf0ff83d3200ebbc183e1f4ea2e29bd9bf1ca4a3706b2a0d461ad357861097625c8f1b7ba13d4dc05ed021d4e3326dab07bf99778c2e0b49bc8b2e865869665e93b94fadfa673c8b1aabe5485435acd7507aa4e81263eda382c52213894e9c923f74b625d6a424817963a1029cee2888df1fd175868ff7821a4526f957c7f55a8d32c599b7b32d56a62489141c69c372bd44c2af290a9dd9f869bd1951ab112e7619e141598e4ff849ab880000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007173eac87b3d642ceaa3dc904ac3c4245cb2a260e4b74d0394d33d4b71024144180a727f80b092305f31b2526998edf6f98e46933fdaf0e8709e98d54f13c2701c58bbe35292fd3334c5e03d345a9a2ea1e01b2c4573567ff1ff3ba7406a16f5a5805edd760ac78a3ab8602e415f67c7cea5b36421c79f83cbb14fa775448a832a4b28851ce215c11dcbaee652cdd7342b6b1204727479e6208fb556cf08bf7ee230f32659e829ce4fbce0955d01d36624bbac18c1d25a3e187722f8f74c88b56e518cf0e78b3b0eac56d8f13c4afc4da3613a41ccc2b0b0e2ebbfe5799e479f81335360d483596e9ae926751ec9b956555f271c2ccd85f0f6c1bbb2c326c29b5ddf6b5c4c11f8eed15c0143993feb626543e92ce4d66c0bd28c79ed1ecb793a3091d6b9ab510b0d41aa42d70c2d8f26ea0b826c8c375e1dd89b3e2a48fe5d88a462deac33bac35aa32ebc010af7e47b77ad23653d747760914e0ca12864cd401787efd96f30d82d8907dc68578067703dd19b2377df319eb540e8ae78b2be86bee1c915ff3b2f4b25c0ac22ccf89bd85371961944d8a4e6d20e2d3e9df3a07d3bf6986898786f0667545275fac3eb0f069b457d8ebbe5f60125f94756db04ea203451a0de160cbce2a34650d92f200448b097691a61361ac487fbc3c82b2bd7c1acca02031311971c3cf69ba459a0b640a702db4467973713a6f2466560ffac0592d64ff1d4a935220826eb559cfe0144ea4b8e54eaf67ddf91988dd4b3749c865008c0c1cf98bbf76d929b85c8c426c15fa56706984e0f2e90658fa3cc33ec9fc700976870c94035ecf9a0534b18d07f55923663835416e40235cc2550bd9822f0912cf101f86039830ad9102aa4a3b6777edec5ebe621082fcf81a1c6a528f0324ec9d39fa80b6e87d6366e7edaa0e14337d6708f7c3d2fb1978f4f5cd594fd35b267f9cd09370d3366dce286ccb9647a1944f8d8be63e5ef8f6108cc5e9afe9127da84e1913439ec35a4e17f7782df042dc2f7c5cad8a659db282e61763539b56c2afa0f2b507d549ec8c9e76c7db306380cd7b46c9699b6db8be06cca15e8e83763137b06bff02de2738a46c61b70edf4f394d54d0453dabf689fb6ba41616bc589cb9847224e74f919b6e03672ec6a52584fe81456d6e648dd6f0f9b068eb72241f067bf6b891a498a9a59356c735e10efb37b3ecf47cc5620a35442dd81e25d2c6db0e9e871301add193d628b30e3b4345751bc17e0b5b05af758a653de7bed3763303ffe1af05e407f296c736ca6f4c348b25718c7a814bd0730affc057842af3d9b9adb12fccd740add16218aa57e43835821a2bcd70f1027f3042d4a92f10d0a1fb8323e87869bfa8da24da75f8743fa3038c24fedc0c987065421bf4b300be3ed3f6d6d590968d3ee32a8f5e20ea6168756aa18bb78b6aa48c299c36d0e78b6f84cacab5946c69179e461f4c2dd201d8032a29ec6c52942ac37d9c76ab4a401c9aff96284e1e9e39bff6d912ca33b6118067605ea65d7f611dd963f4f75f97346fffd1df84c79ccba06804b3017775d8c0bf614fcf4d824709557937b22e1805a0a961ecf226f26e3706362bf6d8d1dd30be7eeda481a64961641dc57b9f0211f8ee43578e4c2b6507114dfff3c3f884586bfd1278d117f7c6014fd5980cdf1e2fd1f34ccad170842b9e819c22fab9890ae265c3bb6946fccfe218544d00a6ba5bef5224eae24002b6e83e0b35e98c2322be2eb3d8234be8b048c54e40782c9a24d7a8b461ec05f38a94aaef3da3b46d0d85b0d949cf1089408189ff97c56c7dee50a004aead82c15c7c0d0965f3c65a9a715a65d29cd3614954ebd91eeb4e74f862fbc944c56f2edec4d344f92e8154708ad0f5575880503ef0f107a9a9db99bae82357c16578f3e6cbdf9b427da88dc322d11c6ab2a6ae6f5179c94454e09df5caa6a519a4c1903c8f2925639e12af793695f256bf0e55e0d45b73880358f09719ed89a4a1a07868bfbf16095a20035d5d4f99fda19ddae3e21cb98308f4508b5cee706c27898f03a2bf14f29acbf055e4ab0713a7b6fc1a7853efd36e1290e69587fec15d492a66b9a4fea6e2bcde61e02fe18e06f59a2f4e06f177b14ce4c1cf1a8d1f49c554a8a4c68b9937b4c230320c80753d4b071bab2deda89c9181820336f1e766e447ea1c44e15cbb7c002c1813d2c1726db0e4de289466077da9610e5f3aa313b1b01dd79a4056a8bbe9d843ce5b0439325ffdfe91fdaddec6cb86d5cebb68d8f9c0ed237a4648c412780acff48fd9ce817ea70d950dcb989ea6b11fd87ea4f30347a27488c5c15be7fd6d1280fea3a7c022f8d9881fac93176db2025b4c7914a51099893a791bf5be851f325347484ca6ed51b2ba71548a6046ea7ec85b31a9967e7d119d2ca3a51c1e14d5a3eef0d41bdd615da01d45979007a1997de281bc340c3203d5bc0075b1aa38873a9dbb9d18e6e26971e70b54e41e2c8c91d2e60fbf85435c1ebc4893c45a201b1d2391549f52a1ca3e0440adfb746fbbf0d9933f9fa0220b3e04ebebb29d2a9ac1000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 54","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029239aa49697d2c3cd7f903ed28a71d847768b9dceb9db330b3fb18409ce609bb965c35874e6ac169f6a90d9b7550b9b61304c82354b734bd1a14c473717c7533211f242d013ca3f622af135bd7917495ae0b58ad93c40649e3f77fba8e7ae15ccdba103844c21b9ee8eaa40cda999f63b0ba223980277af4ffab74b77355f2c6e91a4a16ee30d73b08c1f3911229344063cb76177c8bd04a452354926cec14e4f6e77b72a553fedd6219cac927ac6a02ceb25ab5a26efaa10c4f6d4a692e15a3a6fceba069150d8dcbdfb4a4096bc027bd99654ba48e3302a2f365b06acd6ac0f747498dcb9a8fd2d1ceacfb489719e4b5be5979edcc79d7ec9c467d47e0e0d2feafa1e73c4ce1d81fda1c70d1bff0a6b6c0be65b13fdb7b2d7f935b70a41b32a069c8f3793bac28b7f4c235d34ac649cacde6ef89830ebf7696095d6bc3d584ee9f1fc648e542524fbc5ec51bd3acd3d5f9e859a1dfb6cfc95ec9ba3e58de3abf1ba6eb284ceb8cd47e5185f167861eb5bbbaa9ee2b0f436a435ff6b7fd5b78a789f5c36f32e91286d48f328b9969cd4750283328a4747326688ba6f801cada4972305c7a85ecd2337502e1d69652bb84ab26da3247207d9d0a9366b774ad84aa12ce776d0692274737cde53ababc419d41d72c2cf8cb277c247ce1c72e9b86184090084b3dc08649a30e5134d1afa2133c4b4a7388522dc98fe58e6854678c85f31d51c9b6402ed228a511eb9faa9106da951a4fd25292b11deb545b828399490bd2cbc965697d720880ee9d39dd93b125e87877d7cf1fd36b4d741529f377dae238ecb5d7bb6f7e1b5170e629bf1f84212c489936f54972b350dbae090a38a5211091bbe91cc9819d3bad87be82fb25066f9331891339be5f3f138720dab868c62b0c2625bfc7c457a695e2408e9cf9d34000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381095c457eb82586534ec04bfb92022b08f4fe099e6da408e1b394dd8cfa2e0dad1b405c01513e9e07604ed6808c765951e0745cc09810d5ed6c984816545c43032721ddb89e9335213e3d60f845594ec64403e8ab3f381c15503a469f9e508c46b841228aa67eebf924e6b1783567fa5acf70d0f949d5e9c567954d14d2e4ab5ddd53d430518e877699c8d427e9a592526bee62cc4b822082d406759a026d1471ec36068eedd83ec33779ce6d9a8adb0b98a1d84979dced4accbea0b5200f61a45e5bc65dc403894f9589c1be5e36a6c9a78abb2accfb3bebede132380e78bfeee929253b78fb922b5289b163dc179089b9084bff2e9d1ae0cd56aaa9ed1249be1b332ddb2c26512ba7d4abb2e0321b370680b69957e58c67bba6d81466c998d4a368ec071e1c43b0eab029d14cf98ddd0833b86e2393b27445e8611f150a3681e022822df88e1a26ccbd52817316cded7c308c435b8d6459910565fbc8c3d01b784b8ad12f6f0e219f1a57d1839bacc8133248396ce9f104eacd3f32c538f82eaef752ce50a04a1bbaa0e6c531f023d95dce8360199ad417d518a3eb2e521f41ee9af31c9c84953f2164a08492591365f4c0737c49d4b849503e5f897ad512a8ccb282792657e3125146c6971a68752e9e0232e398a8866ade57508c03884cccb611070f0baa4644acc82c821d78331b05911d01ac581f661f65f6f1823c2fe912313f7830da4186d012834ac6854355289465d24991dd3232e5cf8c4c70b408fb9bc006160d38de09d16b7080ea7d407f9a147c2744a3e79bd22ef9fe9e7863784f19b959da90469c54584c7cace41473ccd6b03fc2d172e21632a6568ddac1dff212625814daea609e5500badb177c8cb0c24118eb7f3b96164626ddd1a4e9bfa9471e1a92f86cc37644115856aee33d192074d90084f840fc6744e818235ff785e08ad40924fc6491a166a057c05f86cb856adfec7c42242aa6d2797a797e01470b0c645d60949fe98bb07d81fa18268c3de610bbc6d6827b2193bb16295755d069b75f6fb41f9409c8cb96383891b9e5f6e98484a8a7134a8893a43a64c7ce243793d1efda9b8d0399f10da6b787e5142d0f45eeaf530449929067d2b0ae5d6f9bff5d1393411720ceec394092a8b87f8acc3d6dc216bd211d41397599341cb885c034aa264bb8ab88e1974a29bfb1066a59eb131c435a6aa4655b273c988b254ce053797d71b8d70edb71de40499e17939a906d146869841501b7092b6354000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000738baa4a41e4b68fe333ffa5ee97fd3de18f0eece8eb83e46a8e3505e2ef8aea2c4040ba3809a764b681ec7449f41a2463651a8cc6def0e4a058eb843ef016e5cba8d55f925e66524be55cb98fc3169082e52e0d6cc3600c4e8a560b6d448a72ccc95620101323f98b43e28d6357414185ecb0263c7bb94e7f86146661fc897844cf52873114d39123260893def13516f982783b927864b61b56d3a8e5b4705da3a95f6d12a6637c9ced02f07b4aa0b08b4924103036c2a93b31c91ebb6c5b77de090ebf60a04191eb6ce9cc9b550f5b0c9104b74d15358854181c0c5640fc74caee14fed6577fd75eeca14070b6d02a9a421247a5bb262d6e62b04649e75bbd3ed8e72752289fa7c1a68096dd96a4bac8a2dc27c44881dd2416387d74a005680a3d229d562d3daaf8dc37b4c87cc86a8c991e9327cdd43ba930cdd8d1e44aefb084b51111965c5dfb0ee2f09112b070cbfc545119aba823eb3f65f26bcc025b39f79be42c0396c5fc9fc924ef1b7ee9ddb71b6e69b579c0a64c5b020206cd3515b8d5f4ff29378b9580d282f7e5eceeb5ce9c09a7b334e62151100cd658dfffa66f4091231bea6c9de8129ec4f5fbe8be0ff4bc93367dc69d9e38c177b23afba5c27fee3e2b73c0037dd7c419c854df7c2412349bab43869469e80527c3ad3a7103152f9e0b03353a596002ff54aba8b14ac393ee52eb5564d63bc2738d571fa3c255abd20102bb299441b00eb988f3a5cfb238ef8c49963b4ae8877e6b317e208821510bf446ce6b06c33717c91c460924248382159198f09d0f5a25c1611b2d39cc6d2ed149fdf0e09a0b0b2bb77067182e386f5f6a55b68808dad98e5ceb0fdfae6a0315845acc7b9c172b0e82190a5eb7c58de4f86d883292a883045c62d6a1b3c886c345aa6158276efa6b93ab2188e47abdd25d332146e980e1b1e043cf63ee35a5aa01ab6cc62f77699dca16fa30e3632dc5ccd3253d01e547746c78021ac307f0ef1a0119ad11504803edad933150981c4d9fd181835c507651dc92a86737e3afd0eb4ddef6182872fbd31bfc6d8427c2f4d3a39bcbe6b5120b8cf2af5dc59949c92d10b1c6a96810564dd335e0755f9de25ec26c102355688c38250df8f96e105136855c8de4bdcd86df03f92977da16908caeeb4056f4a5f751a57ba057ac0309f1c107e594cf3c31544e4f1d93fb9ae7e1a2451e7082cf0c850990ee71ade0498f6a3852dc4fc128bfdb8abdda3d759c8d4f83fed8509cde5eed38410fb9f0a5f30ea45c9270ba2395df645aaee03f56158685a0ba65de3d2c5209a7ef4bdd4bbe0cdc966dd1bdf1fe0be06c7115f7ccd80f8012e5d17955ae0c9e4220076882f30dc5e391295994b9f809c09dbed8ccdfc89669f40492944ff20948080a4ed66ad8166b613ab2f4414762ae493ea6661950e8e56b3758a77cdbcfbf24fbbbf20eacd5cbf8815899a1c3fd20b1d04920025885388012d9c58ea842db9530b7ada901ab9ce46a12700687bde07fb99bf66d0c775218b8454c936f03558b899b59361a0c664081ce8a7858ddbc5e7c5480280411c9acf4d1ec45035d97524e9e44f963532ca5067609540c1bcb5627f99d5c61cb9a6d400f0ba0a74e45ddab5a4e8a765dcf2f3684e3a2661a78ac069fa38163ad9f9713eb45c841c6617697cf8a72c54b550dbe9c22b04d579b09aab0ef4ee8b70ca563f81ef9700c07761c944926f9a76a8c3eee1cf7e7524d65908c47c35b0453dc10db5b75123a5b26b9612c0ae18816a71f34638798dfca21f5073ce771500034f9a71feb8b621356c430b4d47cb1b59ad4677b5c679188d8861beaf52558165f691f65a692e8cb8d24abb74b8885edebbe52fb13dac16e3a8ebc4ef192fd10d71898e93547c7a09f8642aa3b4faae23e48bfa809c5989d3462aa50fd4e5c4095542c45e5600926c2decb4d18bb43b7274239a8dfa3d9de1bb9ca099dfe56dedfc9e120867efcda10b48f7e630506aa606d76e4537036127fa05fffb8b8703cdc8de70a78d014872111a431f393345d74e8866d9a9a633923072e93dbf47c54c4b205c60e67d5155b76f51ab49acc7435525605dd43a10c88a03e08e257c68937bf2984be63d40f8a60589d909f8f09688a77da15dc7b4853339f235b1bd60aa845b4db6b699325885c49df9c40781cc56fabea6201e2f8a9352c28ce321b9441422807e9c81c8f1ec85d240c9f1c8ecc4ff06d6e3682dea3e6cf92f2b74c2165af247ce0f5ab84460693254b523498a57e7442977f51f1c2f649bdf756e7f43ae543f5d8e692820f8a06322667a7fa9c1a5b10199a69ccea22c74e172fed43e550c68c337ecc5e6aad9f7eb997a7e619d47df73cb917a705c3cde5ff344f6fbcfaecce6b734e09a385fe54b224a880704d774581074c59eb0a3b42c59b8ba4518e764c5a532f6655dd839862af716903a118433ce0809376a88e88fa847b4d1c63ee393267b15c1e42a91dc6107cde990ec9ecc7c1066e9480e90a22907c51af47da837438a90cc07de8121691bd73802d5d09d18a2d8b38a28948735110891d1b559a73445838f359a6fb90a3cab887486cc9d95cba35b55693c890830d20000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 55","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039bb718041514c93427af2616d8c8bb9cddcdaebeb8b5721e90f1bd307c8d7d04c04f9f2ae8dfb9a247347ab9b167e91bb33aed7aa08daae7e3de2a0ece0d01efcb746b23705749c3497dd334f38b1ffabd946e7d880b10e22c1365aed7a3329f9756cacac435ef0cf35edda0e9cb55b735c5da20aebc95dade31a6531ded1a1fa090eb989e355505451b0b068768d274779d1eea76c4e9a479945a050f5f6b17bab3608368b86eec0e4e48e819e234feb40d3434aa9d8c5b83c7ad2281396da5f65d2c5373bb8eed29fa7a8401619121c35086cc13d9abe843d6690a732d751e7e3da654a3a1ea6a78cb5219d103f62b4efea61066692cf4d5cb877c73183792f51678f0fdce3fe782c9b594c3d8375496616ae575aa18360f31cef8d7b31a38a62e489874cb5b9963583acedba4995872f1b96190b1a9771854f6289767390953eaad0c314dba2778cc8e412a9f0e96c62cf87cd8bcf6af7124f5c43a91fc7d4380a35e98eb7e4fad4ec9e672db062057b0e4e20b375c7a86c707864bc5ad70ee5a947c725b3842e107f90621e5bb21d3701c334b94902c6630f7291b2432cf6a4f3b2be04af278542d9e3afe1e866dd13ab0edf43b767d669e4e8c4972e35642ded616529087c3dbfe6e1a35f66fb74961cc129431036c5b6cb2badc1014f5cfcb172637609ddf1aa949bcf9add9721b143f315a67ba514d82b98b9ef8e123bccada435253dc7d1fb5e4d3193168378c8bdea1274a24963c70a9390f7229b159e3e6a5486f5be42526f8fa332c9c7fff0b69e62881568ca9f3eed24d32b8771f468dd6bebd07b102f64f1c3cf9be92b1f1fb5c6daa80dd6b29957e0935f7cc15b8122db83986a3f304944ad0fdeced8aa5d2f1f1fbd9234e33db89c93531fa1923211878930a56af7f52843c3ac40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381095b7d96b723a6615a0a01c546919200bc38bbcd26734e799fa46423ba8dd979793da6694fc6a283aac71927baa5f88d69223afecb8bbf07f43a7164479e2fe522f6a321778ebfa6052438a064f7529e02c0160ef08ac629f83ae21125d296f722dde35c2895f9181ea0748863c254e0045d9168dbbc545132c4bd4b1cdb05b9ad64fb385d2b36b1437030497a921a40c87585ef6b1c83a253d1694710aa2a6d8c1b22b9b643de4341050d785155d21eb1e07771335e9b10f8bc108aaf5d8f9ac4b26816c90c285c4057cdf4a5b282235b1c9f616a34776940af6daad8789209fa306d98a6928cbea294a2956411c910387b082cab795b25bb27658714b96dfaf5b31bf103cdfa8b25661043ca91894b40ec08868dc4191e4d377ca39ae199af2738bea6ee0f76acb518922dda1c0d50e389a4913c75a05b86a7a90f802104a6121247265ae3c6c6e0a1b83e57f7874be6b13eed69b0e3c20a6c04b8f52520234db294eaaf01abee95d3a0dca766b5e32afb4cc23bc2b501b3c1ef57ea3632ea04ea530c5baa9c0ab6a3ecb6c22bd4887fe51b5202598da5e53ff17fc3a8a72d095bc25e233f7aedc7988e1f696826f2eb19710e3d1077914dc7b5c927292063202c02d594a4221999da892837ce6d917657f4a85ed17001c770fa40c7251ada372e988469c0d2322e4c6a98c6a1838f93ff641947940b57721a8ef9896e4b4964eed884568f4671f501a104ce890d29905a4ee4de482187d225805c966c148b5587350c88cc019c8b55136ab2e5a1ee8d4b1821e38e8b227ff8efd10ddc8b2606ae902743bdbbba13c56e0cc6747adc1895997d9bc9516a7f416868421dd62dde0d2a90b5c9bf9db247243fdba4db3ba84458d38fe8e4bb3642d2e9ae3d2181203350ad296af0f5846d27b2b7be1531a6e20704701034d5489f911c3498c8524da3a4dad29edef7b7265b68a287f84b745f58ec4d9b0e6486c47d5a08b22d8d600ad3aeac24f64af918223f3cb298b70b8eb482441174c72c3ef405f6a55debb202042014de0c8bc972d1bfafe808545618b1d099739ac546fc87f55611ecf4f580d516a5a2c8a06675ab3e08da0392dc2d4eb4179ed74f1f988aabbe944261e6dbc90223899bccdde54356099daa4e6b738e2b8e2dd27b83867ba5c818e54c6dfe70f4563a5d5c987c2846ab3613703311b4505c1e7b1912bd96cc1eaa49157b05828f7d5902de0152545a567dca20258a3fbc001b8b549c10a095a29452d6310000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007590707ea05515798829f42a4cbddb4a95c5750879e0a584ab503f778015f83bebf6d63c3b48a4f478ef01091403ddc5a9662e39707dbc8502acf50f3e06ed0199cc647ea155feef503be045bea4035c07c4cceda306b8187185bd06c14220f2b7401229969c1cff8c36d499d5a725fa1ce7b44d71e6c0e4e750766183883d838dae4f00b140e0afccb0e72f935018a6314232dc632c5ad3c26919d1a7925bf0f665ca0223439518143486ce92650dd145fdb2e97e0d5bc9d6806f442fe90c9c1f52992e670db2603ad885fa42b3d8bea4e470b7f76a367aaa506e931890b6e4607f59e87a7a5fbf3991eeaee47cfbbfe3cbe028e67bb645d37a7be5e7cba6d7955cd62d1d8db0d9772ea0185c25bc1ad40a09d3e7e9caba72bdc3a6ef3c40c7ed6208854157914a80b5c66a6dec2317fb5a529421c03cca6fc0a3b3d51556e8dee7c1ebfba924fe2ebce8a46be96e761aa6749c0a9a2b2fc49b42ca47663ea3395df22de20947db14fc1fad03805955d67f8473baefe2c1e22bdcc7bb988db0dde4e83e26a16f10b93bd9cfdba77b9302edba0c9afba7369a023ef763c55484f7425f842111cae27e07a511a725f25d422d933f2ec201bffe3291411ac3cd6e91018c95074c18fc780a73945b148154987854cfa1cf1199bcd03519c8f34774453df90b71fea6734dea7191ee2a5735f7a191f527642d53c844b087e9346b07edd0b78c36f83445825e60a13c424f72530e05f75da8d33957faff004deb549985790956a0e7d9b256298d56bc6206f1e4e1e958fe298641a277a2c8b6b9b7660dbf689ad7e1a19cbd965cbeaa4a0d30741586290576996ae668ecbab4f06f2a1d542e32c5d3f042e7e29a41bf86bae29e7029d997876cfb23b10986a45ca029739b2446a29c55561aee8ffb187961e6e7401d726af6d8a5c816b2ceaa9a1c9b780ddcc4f0e4003542b193ae26ec687f8c51451d2d5387d9c3b9eb95981df2de069fe741cd5c15f6d1b12c5b9b94230aba33bf46dce8ac7e26896edcb4f87272c32d19e72c313738855c02c6f46f1162be0a3ed2e76704b16169689bf532ead7ae7f2b26f4d9b22712662beea1f46748fa4c27d1d825d3fe493b5b3b513617c81d21a0912d329c5a4e3a90ef5a29a4e3137d1ce3eee99c42d034e61593a4076ef124bd6bcf8fc911fc9f6077d82c2980c2adb955939441bc9e81bdf9d6996ce578114c01f9ba096d6ea40f4e0fbb18b3e3d25e7f6d6cb670ad26f604368acb6190667b7b7ed3c1a1da04e42ae0087852834b91aa072ad51c0193e5299481221bc9083118f7b5503559f1e2d9e22a8d57932cd0b59509e7d7f459e20ebf4c1d0df71472340e64992c0485d593714d6b469547616dfeafc95089689931e79944204a6d0a47a565dc325f3be19fd44bb6cd4bf2b1d4a78c883154d70705e121b833a4a7e7e80fcdca03f52c1f831ab0d989ac5dbb5cd83babcb3ee74b69681818dc05e33234775123f552cfc7c7bb0b98c937957a2c4e86e3d775468a7cb8d33756ed7489d04dbe52eaa2737efbc4c4d0f55b5a841e1453763e611bac358fad0b5778c6015d97cc42ca9fecc66cf844dfe55587c200da5250b3a419791f57d3a4f672551be885dfe2aa8637d6c890ee8e1063e782fd7e2cb356bf47b6eb93a155d8d64c9f6cca3971c5a7facc3c052a2aa9fb286750f76933261aff5ce408bda8382af8535145f432f78b3b25a768b5da2a211d1d07ab557cabc7a139f66edbb744aa76e0fbf22092e31c92cafc624ee1dc6732f27e8e7632c6eee2d1f5c85b52d712c884b36c91da383f0de9e06e5ef63d7b7a692e5e91ba1a1d9298e26694faad9ef262f117df8115e2e877197a8069a96210ce65d45e6aa7011654acfafda810cccc20c1985d54483dae12b29d7ecf66376968b52fbd727cbae7c9e3dbfee7391d985228aca9eb8ef98fae32bd24552a6b34baa581dbb03676a3a4546e10efcef269b18e1172f560fa0f0344149543551e079c1745bc0425b5233b7d7dc32f751d321638edb1cee56df0359eb6d9863cf3e341a56060c8ef8486014f956c39b751ae239a493a017b2fa5210d374ba83df5d799b7cd92987febb0b2cdb3ee42a61381304c5eae2add4777011c3279bbcd1edd6f91ff72b3c353ac35da8fa843dc5561d3cdb507730e8bef20cf09b0ddc36d47f4c10d82652dc2937d889f83b1ddc30e52b244250d19eea9cf7a3b5d931e2e25b64a0a81b2c4fe933a17beac2e10fd888d07f994e4f2583d204da126533f5e36b62486a00ccc317c4381a8fe11d36c43e71be108e22a98f53729f05a5e0aa38d512423db4bc1d6bfae9117383acf94ae2a737f6b8070858beaf08e365ca84925f8bebaeef5af77eb73a9d3648aaa6493cebddb95149f0dafacf129fc321e558084a44cca4b429d664d90dd90f2a04818b48d135952746ceca76f99b947a33a3bf7c535b187c1971af4fcb1eac841be7e96f429dd38127b52facc2dd6512d8d019e0080cadbf7078fc67e9af170a2a00f70f407b0a7ff469e2f6ea165f8b43eef1779a115089de9abe6b78c93e4b8e3b018686d16ce8ebc88cbc1d571372a3996c9e5967c035f9da6e200e7ecfd1cf7158563f36a3aac3cd8acf52a4eee29dceb03fa3272a671cfc9b00000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 56","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f39d597b8c8c67250501a6fa51165c4b013e7129db802e07a1682ec24302b089fb379a140e619445cc2f7c4f232f8b2e1b38f304e04cae15b83b6c6e21cabd11d4d87b214d0202e5df5b86121b6780192f3162ed10d30caae9d58b3e7db04bd66f9529b44fe5117eb519a76ad3b50fae6c8e92bf57e0c585995d91e7aba8f0aae1dede55c54b9521ca2fa20a9220f0c40f005436d50ba2571879ef25c1864ae29cbbc4c5c795cab8895987a43c2cda9b8c37f98c443389f3a2991d9a256cb54c92a34af2a14dab0883b2955b4a3e61b2700481b44c109bb2144e0e34f78d26649189befdd32d998bd34ad07728a86738f770f81e232ed447d8792371bb76b948636cdec5bfec8aed272a4c4d7abfb0a576247d74e7d0a8772db4267db0a3400ca176eb109eca44d3dcb5b853a93e5e243c77bb908698d96e774c6f26b9ebc77227dc51e2569422452360708619be92702d7b41e46d23fa34a3191fe4da2b1d4f0acf78cf64db7c39968af8f8585c75835c655de7baaae9911bcbdb4a9a59bd542f16cf479543ea99461d57761923cb87a972c7eedd253c0e08a14932ca86d5bcf1e29949e73f75ffc3b55d9582a96879b38d34848f3215f4ebb4e1ee5acb5a2586a7208e6482f7e5964d30fa75962280651034734c501097628cd1ee7d1a2d625b384793eaa0b519652f749744f8a9aa106d4c01999dab89822eecb16a122d0879d296a773de8e7a23572f0551cab5c930fd04688c0e44621a8a58f9aa9ad28b6370ed47e77ffb47309d0acc439e45653a2a13c92147eef1de1174c6e40b3408cd32b27d3517527ef4a1eee2ef68f354a572d11713ca85979e8b1b29238b954b8b0c368bd7a55ba9336ad31ed82454facca8ac39f4ea59c467962c01244c24b97971474c7757f69235b4f4e04675bd400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381096401f6482f6e138a905296dad8f087d90ea59ce83e70e22380cfa89b87f9a2f75ed3b021e696446988b47f7a20ca9c667daaa27f86995d1c5b48b3f20ea9a1328967803942c57a304b5290e47800cd71b40cc8959d9229e9c3132128c013ca231c124b6554b0ee47402eca7d66188e611869c788aede544d6e05fa0097cca771b1170b19b87425e0761b162e518edce08c02c43642b50acfee82b7f6ef1531ebcd23fc94f8119d3368704e47cd4bde46de0302016e43a22acc77370df62a813b39cc1ea8808593006c2f67870028aaa2e81929e0c00280e8e0997077f1791c6225091141e0114b0f0e22c2875e6312711952e194026c2423449a99ad1cf5303162d5ba02d0abbacf13c02dd83730e1ea727802e0ab6e64e37e86d20a43df0e30c862336f864d1e556993669ffda3608223e2d1686212a2c133c3bba1090570759d488ff8c91b98270d7f0e43c5ff8616431c7778f8899ea21cdf531a0c056c6dae318415fa38a5780ba2086332fe00820f2fd0b1ce2bc542c33fab45c6e4b38c79403d5a192e663e31b8a735db979e10316f222443cd950627fb840f56bb24c75076d2eeaf72cb8887c1e1525901875dc4fe8920b873fb1558a1ea56c03299128a8ec031d52454774daf29eb1b4c94dc31d5056f7c343603eb158123760271508c96cb509956779d2a801fb2084768e73412b09d4028a58f423c3d758a13369ef6223462927f5495d84a4cab2399f8280384525012ccc76b18132c628230d70eadd6b8f423b79885248dee06f0fa05cf5c49fc4ac2cf253d0900d495ecc1a00efb2452547082f503994388672471ecb9572afaab48f24299d91d847a7b115ed9a35f9e04e0d19dc16aed9c90bc5622aa3ee762dd5ece293a923330dd0e8e04709091597b39949476b9153c71d89a2be8547a3416089aff4bde4059557566c0be62bc0e2b9903a0523d63b67eaab8803c685a074d5a091d6b24e3a8fa8ee877b348df5d53a91b98a7d9d0b14067c94b4cf51e25e9263fd9cd380949a987420a917d96608cc2b61cfda356db9adc719c84c27adc0173d08a3b8f8b83bae6b5168bacd3662026422391c66f4d18e8d3d72614bea6b63c56b37d085812b29f7f23404b07df425939ecaeab9e48f55f6238941e5a159372bf478ad0e06348edf1b4182715aaec93691426969082fb4b23070cf266f8f2ef90613e4a00b508a223e85b5c001fd45428f240a4a29937b4dca7e6e07d7e90def6d659bc6d4834d44c5bfc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000077af3ea695264936d537d86e545e132131442c2973d19b37f8c911e3ecef4a13a8b1edf5e5968a6198d26205ffe6b76cb14e353b5e2c9de1bd44ab9bd55862ba1a479833335725ef52601810c778da4a32c497ccfa43f91c72a1499e8d295ae7cdb43f1ca05f0d4a31b30d9a69cab8288640f3f9e081e2c98cc8351c7eb9954d428da4bb374b346a83eff5aa3f455f2bb3fc922f901bbe5695e3ab9892a93beef90fc150b3bb47f6965c229f7dcc3100a4101840417a0e2547f9d42ab27216254a2898368bfc60e7d407271c213233b6913c8e48df10967757bfaf5b5e2a284b8f67c70537c97583786b5185b45e2e36bd8b5443e98601f772829176c4d66f44a81aae7c13f539490640bfc40b83e1c75305b06be60e18a0ab568859435b715e15ba1ee4de73e04e1b09dd15350ae423c131706f057255e9fa8fa3f9e3ade7435a6451f7a2aad0c0fe0f444c4a247dcbaa49e7c926dd52a33d3737b4439c1d40f861720e37bd25366eb5f34bf4b552160f3eb80ca8fb19304e1e4143090f8e965daeff17551a3931905b5cd991c6bc5af5be808073893a47fbfeec0940ef5e7d2f2ee199847e1a4bea447bec40f86f6fdaebece6ff0f66e04193355c9576dd4aab2d796cfee5d432b1d32e13b8903a06ffd3aecb00c169a3af8389848cec724f647c6ba8dc3134ca18586db3e4138601a16df8873a490f23c4d27fd9c3d4fabf2bdcba4af3f0793e7b591198100ec97602d9ba572409ea49d7c8edc646335fd4494577720ea7cdf3b4266fc201de4bc204c0d35cfb55010bfac68ca0df3ac936c9fd2a9c532b8e3461d25362efa37da159b64670060cab833eca799fcf1342c7ee1b80bde05abad08b9ee8908d50cd0d433dda0b120d1980f690acad9c072502ab537ef71b691917a76d3098c27fdc6fad1f1b29e307e17c87d9fa6a06cf8cef6568d9e4e005feefcb5f41a46d91e31b41268367d636c4478921e690d5d57e99da3448773d51b673109cfd3a58cc50c127f34f4963fced6c216e60ea0952317fbfe88807bff4223624f6126104cb46c8d39ee228bb4fc0002287e346e5ace43e2caec07a22203fe3c4aa9008a94f7075f6e449fb89905bb955fa0023608c494f7b73d2aa4e2b0a8a7e3caa889b6b6a6640f7222ef969d46ff6794bd97c5363921461bacda17f2781e14419436e37610e52e3b7b7bf9c1a4b1d80876030f9a8981daa4f06a432dba739db988bed5de7f38378ec1f7d8a46b305896ca0caa5d8ad74002863c6ff91ef25ae96450936509efa93f94718e895a82b4616a965af004038e0897a6563dbc91eb5a6172adba052250d06d210bcf5a250246fc3482e57fcd9901104c5ad58eeffac2860a4da9d2c308552efbda2d4275f3f3651e9935a0e42869b9263fc7ea71079e604a4ec6dc61cef6ac6cc06194def432c1f7cd9edfb0c4b448dae3c2a685bc818b2a90e17a4c1caaa5fc2632f720e764e2b8da314224498119a0d94cf5dce24176421c2736575672b361119ec7c766265768cd9ff1957a17779c11244c1cc82d72d4e3c87107885f71c56da2bc41008b0bc1375c12b3b2a80071ec03e377a93bfb227bd560edd5e5d88f46f7ff9831f05bf262f01f62278d3dc13f4f0ceca0509091c25d20666d8d3527975ca3495f6843b46b5d5b6f5c650e981defb3943963e14f00a0f78ce785a21634c46b531b4f2ac5ad0f03d92372c334ce963e514a1891716eb5d5bb1b67834994eda492719032e2a4f961ddd6d2002d8f52798c45a9da8145bfd191e97d1fba1b395858b0fc7d5f5a54e69fb3780635f70a763e44075075580778676e6b9705b40f40210e597b5aa1aa77bcc3be5005159a4b68cbdc6ad8674495e0df65a6decabafb993cc49c082d358db1e5b3a8af2fcb0049a15bf521986ad84148135cdb185fddca6802c2ade9ea2e82047725d73f51e072ccd799d696d7530f61b16e9b4727c58cb0f552b188f9b451be543bd809b63d66bcdbaeb7aa917be6aef05df559b3aeaf65d5ea12e852d1370efd6197f970f52292f27923a10d01aeb652a9a44573c137257b49d130f1da48e532b3e33d4854b995534380b4549511b39a99145af5abe0ccd3a9dbaf673efc115cb75a9a5a806679907bb525a2bd4507977329eb4c985b3575de6533fc5d62358c21af3dbdd20deefd7c417c77d37dc2a098a8fa48f7944b7ec6f929387ba11e3516c9ea681238650416ffb97ea343d5f227badfdd509b94c1451c54f85e4539a8f70dbb5efbb10b2d82a16fd0c997c603b8983ceb840a7c3b61918d8a97766bb8442c3b9ef2d324e28dc19748417d32f642874a8927688c74bf4f6f6724015c4dd50eb83b85f613fa20938f5c895f88830a40c9799c212b2dfb453ba0bc534f75cedaf7a016f6744cb4f5269fbf0284eb90cf1023918078024c3b125cd9c7501224050b4d20b585472b42a0f494513ed131bcd8f75e223317f56b37ca48780750de0bc81c74a3388c94d93a65719122e9d533274811b76965265d7b2f91ebe3c5924ed2d4dd5e327a6e7546aa2605e4c78d0208db7a7f678caadfb32e6bcf8c77fc7810f7d1d5d50e26d1a0da03b8afcf99904b2b3198670462451925381f0bc404c51f2f18fa7e2c1e8b0c6cf97a9a65e575373996c3e9da15a18d15c93548377677dd713c9828dc4e4ee823a241377c65a2948bd29447bfbe000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 57","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f39190b213f635d834b16b526f9931c594b1a1c823622469ad90132c901ecfce0f332e9ca7db8ce32ddb825560d7b3d0319654274cfe85f998ea383eeeb64d53f72b9a57228fd8d7c8682c24a50c8d1de57ae26753d4b1af739268e192ae5fdb6e47d65e88d36ded52154cdb333f44065110def96357957d4b5752d5b58048734c636de890a5461a0141d3be432adc7dd30d8cb923db72cc930e444a1b4576ffbc318e50b6b8562110776f5a34dcc8745f87fe1f835b623ca95633894d5772b7aa37b457febb4c3a12b0727d9c36ecf47d3db49fdd3ddfe55c54ecd31e1a1a7a6b233e3336131298b43864a92cd6295d5f5c3b289f5e5aa3e4d9e1652b7b20559b6939842952e96bcbc05fb444103d0d9ed49449939b47abf3c8cfae782f63c157435f3a1d42954e6a7191d62d0e2cb96c822ce3481859b39f206a6a91538694661248bb1d294094d892e8b4ab78bb34e8d4fd9b7e85e6a52dff4e95a26f3ece616511c44fa713e4164d4e22fb72373a9cd8663584bd6dbce1d49f4abce24dd2f62a473662a8f34ec432148e65d97c8e8134e0bf64430c460eef676c8d94d867ae8e9660f1e5f546da7fa81c2538ba6fdf0957ea1c98735d1565489914e50db0dfe3f255dbeede674671908539a659360b6c9e79b25f1096128594c28b8fcf683ca9beef738987a0e6e5ae46202519324c305f316ff2b810d9ef622ac0a824451ad2f6320663298a3ef05c32f1829a3e9a7b970cf67719623698d1fd9915b5a0d2e8d0432c8f469afd3cacd32c3119d51d7d4d627a9475b2e76ba6796eb5ae2f01bb539f8e248f0645d9845d1ad7dbce5bdccb3f487c008d23381fd489190b66a75085ede27586c714c39290e949ad99342ff6b4ff1abf7a26c3e460ccbe96a448f1d60a3c6bbec4402c74f35f9d99c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a894b5435417d96a04c205180b923b31b0a16107e55f3ea911fdac24a55e3f5772ac946501dbb38f691a8acde1a52cc66a9fe129f23e0c674a5514f7ee0f66a040f9fad65ef98b30b511131d5759366cd85e2ea4a75c70a2a326020ba90809ca4a552ca60c0a14a2fcb4fc8d1924922e61fa3c2b395d0b483ca544df18865d147a0066d6984a4d0efacf97b954b1d0d3fb6892b1bda0a2b152db4d56e1e86d604878e1282b29838f7948ba49fdc38873e55a92000743b758dde182c021196ef131788f897790a9686182b44f38a1ba01490da4b5a015f38401b94c390be14162a194d913845bb6b1cd30a16cdc4d7a3d1425362eea97715b8049a0ed54992b78aae2fc6b1e70f7926ac42424bd99e527b42a787b10734986b0cd01e6384ba3ba19c6c1f443e9773e32307bc658303ee8288792e45bd5052ac2c4f80fa6b0d774ab2e354ef9803289fb8fc66098a19ec89c045b00edc2e96f80ad235704e00551ef04339d7810760136fbea8d62328ae4316bbfb0bdfa974461934e0e5e699ad67206905d94255f6263b8094b34d05193fde092448ce350d9808221cd656e454fd13a450c86f0ba76585773a515f9e118cc0d368d18f8a992b934ed026330022a808aa2946d4f719b25bc11cf61a2828968e14d9a6d1c259875161ba3af9aecd232df5f7946d9f7e46ec837942b5482e08c7ac82d597b9ac211e577412710b6913cede923efb9b132228bbda4bb9ee6b38073c2d065c013472d1a74a52450d757ac894ef26ba235e2f143b0e1617e28e08e2eb1e3ba2147454a375b7c5645167a835012d8660f349c29d4d2878872ada4f9efbd95ca92047399d2867819e3f04a541a719b150049dfbc014a122187a991de82d87c6d7b743221979cdd1b4eb086e2bbea5a41b033e5478e7f4750498167ef782e41f6abed8fb40ccdab43cb62834366235a1a27695d75085924e6777d02eeb8c9c3c31b14bd451d2de10c500d012bab16063934b350216e526aa6fb280043a29dab219ac0b39242b6f548812a228cb0b6e9d415878e6829a86df00696a801cbc1034d200e7020c5fea6887ff21f65d627de4a3444ed3a35229fca6569e637755e98d51a34a9a80636b81a510b38cc4724eb1dabec6cf066908005bddf38ce22dc12f82c37bd92daa1b43bd26b12da890858e827617e88a94f1938a8312a7c8042ecca6c994279d6c4e18f0dd104f8ca67b65ea92f1083623543ad5359111d7615424adbc640e247aa18594e92f200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000079b437e0f77bd0e14d704be86135119f39a0a65650c762852e2694ad9bf2ea45c7ee59df915f5aac128309847e944127294566ffb193d0361dd7111d32b06dba60a12e053f424ddd70674e902e409bc6f5891cb9a76108322cdec1491d3d89a74cedd855bb0791dd6da371a75ae979593b5159fbe9ddacf88506e6a184547e2a7395a46fbaaaf286eb7780b789fed86f257e5036a3555e777b909243695ce89957df492c80050457afd84aad9f8918099ab00fd7ad3528a3d0afe5b52300053575b839572d4d7ce43c255bbf5f16948d40bcc2e63714487afd3638601adf47a324482ecc99fb88574538809227f8c0a5fa7f20a0b2fefda38e6a665550e44b8d5630290a4815621a5dd74a2108ca946241c48661eb087240788808bf676b145442b2de4c35e1a6b8cb1e97e54cb729202d8827a0d4994c6d7f3f406ed273b00b6590006af069d69173b5ea8237b87705f362288ac3a50bbe7e70eb15df6ed820d66290f57a87e51b2c5777c9c95c2a76ecf2e296a7c295bfe029bbe681b32a6d9f16d11c7ca2750e2f8877af5ddb616d8a820de998b0b2af5b0c2c5641f498c99971932327ec2c73c0ef4058d9f33683f60553ad2962370afc6725743c86e591d7d7c20944479daca5e92d66a33ca0c862dc60dfeb5ec3c6e7de356f6e43f06b1431358285398f8885176d60cba218217dc7afe4ad876d0890648052a56812bc3f8a9e6c49f9d70b0a032924b891a9410bbe2f214c842bbf0511ef9017744a0dbdbd500a4189b471930e25216d2588cf8ba39aae7623966cc62d6c4ecc8b00b0613d912e60adf613c8f55b778efb93a513a776c64e8dc943e6272c0eab4004b4b05ce9bce9ce2f2b86fd8429e9a72cb16ec3ded285339edfcd122150f4e7310f669b1dd4cd7e76d282d10314e8abf61d53bf343f3ebf9968e1be8f3785581f675bfc28c893729cf67345d0f7c11d6e7d6da0bff255bf706c986704a3b9c6fa0602c6dc108a59cca70f624b08e4f5393e597459bea4aaaa463a3b08de147e10de6b75a0d87bb79ba9a71e7f5999c8972ba992228b60912aa2d7a32703ba8bc02f774430a2b590911d48d3866396f1d71f19ca90ebd5277743a984e2156cb57de88ebe91bcc09ccb5c687cbcd4e48e4ee110f4075a21f9a051700b0c2698fcd6a5a73372ca366a230a9abd153e4dcab7a33a8226f8458c5892098bc0a95619880156548f300c40bdef81e8c1d8bd03031c690b7c3c000ce99675adb4b94752ea22bc9e0278d0a53a2a19363a9388bb8d6c24a45b5dedd8f7482e9c29603ff182f25856fbeee2b41b88b352f99db5f33d8eab1a1a1fede60ea6cfb7478db7540d3a286e88117503c4d0a2c13d32afe3f1a31d1af9ee60eab8fe06248cfffc7bb438b77d94b5644805cc276f19268dd1ffefbab3c796923288638da1c15e014723a84f8c2dd9f55f7adc2adc13fa7cdc29baf48ca438c882da5f7caa792b7cd984bb11ec4b681b332edfd4ab4c132b08bfb688f81baa3fec5a079e2182c282a3ebe2ad5e4c59090bbb989e6a07d85d604f5ffde0587add29a5175ce65d29fb9fde3e8b49eda1d88ee8dd64fa1498d33ebaf4a847ee9fedd3376af46c1552a150014c11ddfc5047929e2415d3f9d81186a685a1caf2f004de777760f0567e880866320a7b42e61cc994719ddc81e28525e50195ffe4e0467d9a9182b75ef57dfee926d7744485a55e07d1bcd1c9b9b12a60460bff016e9834848665f132e2ff87805e00154c7d9853dbca43d005bb197eeda3d2d9249a621efc4177415bb103893c82eeb0aeea056b40e98b5fe65527432ff33ce3e09fe1288a6e2641011721279253800abc4b73f65b15b434bd34a573e77a94729a78c92f0e791570a416a0876db39a8fda8696fb12e7fa3bb11e7838054e4195164b9676dd03327810ccff9586217aa3d50e7d3ebdb1ae1bf6889df316047cbb278ce8c9741798452a38e48a7138e1fba286b497fdb8b1e7bf6145c5f29ecf6d5430f8e550314db3cf48f27897f312c6d9d6357a880b721e5148da7f789238ce411f952695f4a878756bde311bb4e62f10c2f9939b8530ef70d3fb431655aeca2ad36bb5df0582a07f53f1df8e0325e635d5a5e795c130106502a081f2fc52a9d97c5daaf174f13d2de1ea0f8860f08f4fd5b571e1ab1e84437f3c82bf19b96e46513c316bdcf994bc26fb8461f90594e08e6d4a032c1da38481a1ad7bfb7d5270255bff23ce035535cf478216e6d2e62e147ad93357d62636b1ae42c4e8433bb94ca91d0f8ec265f2793514543aa86b786d9760be5c77aad5a8449a7dbe92391eaafc305c1267a68e6acf0f044fc144d82c917992748b9232dec4e33ec97534f2bf60b56edbff675f0343c9c78e8a8d0529a78e2eed9f998b360360352009f01905c1a4815a36b111cad8e5b34688b99216171d4f57283cd669dc05995bb8d94ecbd3e7b662c4a603bd85251f2ba35fb6ca492c2b3e996fe66a1eb904ccd61b0900e7dedcf136f50e4c3ad5fc312a2de4b3e51f355d01763692c0722c700a544e681a316a1d261fad727e557398e500f15df33883abe9d1ba645936891f5a91ff6c8a7b9b6fe5062718542df4fc4ba50d7f513945482381adc42d5a9d444ca211232615306d7241fc49f08912bacbafbb056c018ad4d6021d99fd720ed6548a5a29daefdce868d71a1ba72d9f998a3f89fcfe526493582c4c8af5c1be065ea29f6155428dbc955b745df0000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 58","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f396e28a7922c055aabbc3bf90dc9ddb33b8faf144a2574d28ee73a65b2cd8b030769e76f9e74a1f3ae6349772b4c9bf97ca76da21c6866bbd95069dc7a7a9b30a8ea346ca1934bb29a2d330dac83dca43fe42d88ab526534ac9c019b30fdc8da63056508746d1971866d1046d335b5cab15ce8742bc509204e10bd6c04d3af4feaa51c287ddda8c7a0cd7c9f3f1fd573f7890c35c88a6196a159da6efbf944ed03b3f0c943aea9cf36536ced41db761d146a3beebdeda5399c3e89c8243a3d01cf20abcecca0caf33b7a146ba69145bcbbf4da4afc76a894e34278e8e408ac4eec5ada2c2cf2c69d19a9a3fcb02cd9b762b5d092306002ad43cc335dfe5b0d0d755a56936f44e1234f54ea074cae9f1a8b3b65256a2b570d81d80de12830eccfccf642a3bcd99b0a923198df7cf223b7d3253c2f81b3ea77fd58ad7c41839146727ce27500b35eb029890e9b6e4b1da18f29aaf35822a28ca55f6197378505431a4cd3a7473187827ffd5b7df4d4f2636c44ba4940e17528872b93f5d4d19f7f2defdd1685a0fc4a4b5869f0af5ea046df065990622a518e1dc2bb20f561906b84915953341f6cf536dd1d96fc2d8e846245c3b9f491b396e68769e099f8f78cc2776f96439158045ca6d71bda3b1cfda51806465504d8f7daf832b9a23c697ca3e8cbbe13e43d0f22b983aeaf396776a12b3444ae818737d039128434c73699417bd835cbc6bb2c3328c6fad7434893e8823c657ed27c912c73f87677a3fb7a275c4e7750e1137634a1254ffc413edf9944abf53165eb0e6470cfaf6cbb7bd5dcb21afa0a93fb9d6decdc64be1b9d87adc46b2f958a3a3ca53d8976a8e4d9904eb239ff2e3713eac872e0ee322246e4f4d75904665e26726fa7b267a6ecbc4dafdd24398c54753eaa4ea6f9073c80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810966d4f49b45697aa47cb2fa6005127acd5f0339522243e10ca96a1e0c1786cd6ab36ebab9d535e2be9290999160c95fe9e99681d751e71cff4e8adab0ab023609fd20c2a4084579508fa7f380c980f95c077e075821fef171a59bc305853a27465e166ee943cb0e2f5f341e7be9cb2c9881818de0762c460401de85d24758103024da1bea9318b4d58b5c6fc6082e13820ee86489914d9bbb038d57fc45c3a803e69d5ccedb64cd35460da556e1104b2998f79a0180bfa87010a4c74e39453801968f29e022740d7943af5bb1c63ddabfc97ab2b655f70906ca2681fa909a4f5f682d16f48512473e4cd3832566e9037540b15fc6e6b1e9c605dd611e067487600aeda22a1a05c736ef5c1d75701b5a2ab343dc65224a18a01a10771a9a0db7b432830acd442015e8cb180becfd6dc0d7e29d04028692bc19fac1f15c16f18161c35f756a81f780565579a1b8d06a8de1be5a4431c0e5f36995008701aa996b8815d887e73f89ca4eb4d2e3275d64358b19520158d171a3969dcd44918da6c5c57b30baf0725095cbbedc1a25efa58712b6800a92821f11563ec7a0e836710e7b65889a4fb55c52fb23992f1dcc756bb61e078691f7e6c3a011aa20133a03208b6f254b5967db704200ac30d7a5f880b2f15b2fecee94c662e8c11e68b2bce2327c4d859bd24718fd41214865b72056812a09964c539e89f6b2d0e0e303285a07d8bb616ddb5d9a2894f6b2ac7f687da7e7e06dd288c5d8c5d188cf4f700cb8b288ee4bf07abb34caf05c268d17e9c2429099e824766054b4d44ae4db23202f64ece96218565ce0a2c00359cea8a50fc023673b3bb486d756849807c948e81851eb77b0f481a10382b759b4167c0a3d69c40c39cccc7d7c205017e64d7c366efc33be587d570e55b99382535c46dbf625a92aa9e0b8c73ad97e7b5153207122bfa460d058c580cea2516a9aeb47a703b9a470ba8dff7baaefd331234072541b48f627064048ce8b97cca42d0981040baf0a8ef09e45d9c1343a9e1044859e5b01fdfc7269a40697feb8401580a59bc51715841e9c5f345d29e28348bb5550e881c7a026b95f220252d3921d10c690ec8c515445117fda9122b0cc238dcf2b80626ad3ea290fa591e7d078a74e69c575c58e57d29ed0600012438d49f20402192d53a106fff0026e2f1f44ca884e15ff5898defab6114d5a9a894573ef6f0304e8815a547a524eb1a6b257102a2c45290c625b5b9dcf80d58f241a31b40a5058ca0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007bce4e3edcd70c4bbed033f402ceedc2c265dca10b2de0db00d454c3ae1a0d00c97e1dc8c6804b1777ed21ddf5145b9f9348a931c128a8fb03827f653c37cd95859868dde356ace682f627fb69fcd97757bbe8bd5a260a293d2acf0bfa2c0a3548fe25a2ba1a21f95123d592b40c20a927fdb615e69878e8d7c98d261dc01958a088599d3f9bb5e14002192fc7de417b1074b3f7b52cd2a699091fd9dc3c5929e51cc0259d2255caf0e444ec11257b759978bd4a7c8e2ce8473325b7498681102de6ffe9764334d862e379d9f2ebf9b312fa75d7a50e08b94bd43eef78722d423928fb8e26fda85a345eeed0326a5d694e4729154a9997b269407b7d03818025eeb2ba96580626dfdb3bfbfce100c508170d8150e4980d5d386761f4e8311339b47852acc2a0a01dad90d3978de6536547d4f203ceffaa652e4f2f28639bc3ff83c485c28edc0bbe21d17b8ecaf3794d64c36ffe7f07e8a906cab8e7fc9067ca4bf9b074c7fb01ef99a05d7c0f35d889a63afe5ff18023bf77f8a3da0c3cecea0e538a6dab5c54f3a0d83151595ad3ec4c45132ec2f22f652ea5dd930e692a7c0d7c23de84314caa7c017ad50d430fef42de557073ddba6caa4a787c92e6e28368943cad0974edaeb7addf991cce20bf51c5a898cf0a2104abb810bd4937d23e5d43490a3194b8a109b745e0a365efa59199b43835682e996794f16c5cb874c88d9697b189ac54a1ba1f459623c1563cba7689ebb32dc4fa0bf30e064d119d40c36301a653a4f959c97873003cff7e8e030a137bafe0a60ad08e4f692dc107e68ab40edd0c384875b8525aa0a5ec3aceafe557ec76db5283672f9751afe1166d53542d216186a3def4dfa94e57bffbebd6f4afec3c0f3f40f651a1251a9ab39c262d42313e9f22879645589ea54fe894ac005115a43dd806b2c8be6222dd9f02189d4221a9dde99ecb8c3ef4171776268c12adc37e4ca92eef09d2d1803db1fe917521662ba7ec0c07292c7e2130eca4eeffe53ee0ceaaaff6f4ccfd42186611afee79bc651b1adbad08458592d69fbeec708c7537925658babbe7e9867915c6a728eaf41b0af2effe55207c01652891c373f7a14409d05fe9e26c2e72d688047de9a0954516b85ed6a3230b6b0ea9c5f086720c26efbf8b7f5c5d14651d54c4ea181a707c562239cfc08b2e09a2941d04d587b90134d8f670f734578534138cd9cb7ec04437a768fe65fc5b3fbe818db423a2208e485669082b422ab1257c2529cbf7ba4cb30fa27b7f702418c2ef9c3bf7cde53661df716449c6337c54542eadc5209a0e030ad6577deeacc6be1813db24bec035cee6aee93749d524222535a0277600f8e4f4beb473093c5a00b6666cb319dff131ae4f004eeb1bf71e5d274e3dfbfa246dada9d6f548907091045fccf79b363e695ad54c2f791861ce04874ee8c3375612de820cede04e4472bc3dc19abbb91c42a1c3d7b467837570e7d20a2ca6405deccff1aec03e0558076e988619cb0cda9cc87a12367bd486b676a4f71d40b88ab4e7fa750350dadd1a8f12b70864792d3cc1804be8b7cb9dda532182c32582015c1788b43054b7010229f46bd39000440e7f5d22e4d52eed85b204b344680426aef51f0ce0551feb9672dbf391a9ad363ed090837cac1e721878e65af9ba92a0ee7c7979925fba9f4e452eb4fe3af03b9eff0526ff0a331ac0b8cd27a0c49e5019b7025c3c9870c900a7fb31ff834e04b87db77c4d6dae4c3fee741e923704ee5f294d8f881833e9137158d1ee0fbfcb4637acb814a2a5346607bbcd6bc916235f7875334f2b75a7ea7b8b8ddcdf46c0b8007c9b3a014ec6e634d4173cafb1dd09cb9ed4a123151f4f2631d4bee1520c10c15afeb17198009c2b254c1ff0becafbf69be8c7dbbfc7e8f3f1ef05ff6a7945ff79ed6c317609b9238670dea26d56d481f87ca171ccfd726cc0728c965d9bc38d376d707e6979908b19fdf7e74ecd2d0671ec338fd54ad6cc5f789e96018521882588f888d7d715104d65954dba8907c0b7ce3f2acb802ed49ddf1416c29e8d685c5ad879464819e1d53fdac741f71e31ac0c17b6c8932a4a00e7164cf8bbfec36ebbd30392145b292d355fb304a88a638f991f6f89a398b09f1de4f0b29866029bee75a12d724a52736f2b9f49937f0e51b0f2e1bd2c1bc9325bbd1061e0f7685aca02da735d8fc39646e0b2453bb9690ed1c4853a757ea9dc2f4eb4b5adbcfcbfb0cd2587f61a24b77ca0d6cfcff47a98c7098b986d4fbd0e46ef0d1f9df842f4473c43912ab49f4117c8214a42f3083936c7e8a38b294ba081296a393dcaaddcd0d340ac62511e47da6591836553eedb466da6285359ee831a952e6c7ae3b943636124e43224d527b7d394511cf31c50ec1d3e7a20e49850905d504f1aae477830e3bda50430ebd47fdbb0bf537d8d479cb799b0429c3f6591328299a09f45cf9c6d30d5c1c9203b9521d807875d7fb2c2cfaa688414497122161b1b4f159b66c0834e111da4f82d5252367fd2dbfdc079333fc51ab0d34ecebbe786f984852a596be620ec6cf84ed596425b90316a13b39e5ebfa19b319bf0fd1d6c812f29970fb1ffe948bc0d2e057b1dea15445d71b5f728c72dd0c69e277c58f031f90932994ac5a177926dcc1c570ac1b4b099ed66abf7dde5a5d77d08ef1ad7c6ffe018f56efb07c737f33038846247eeee147e4a5995bdc3352b73f15fce5140410aae3f0af1764e5ad996d01608c5e6c6c96a20274ea7781b41fc532b01b52134fee28f501efd9cf00000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 59","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39fda37915556784b6dd3def74c1cbb9ca04763fa7b19c83ea40afdd274ffd1f48089005f95503cb14f91ff698ce258d32e38b4012358f7de25cd86b4b0bffe99ecbad4dbc7bf3f465db0677d2f5ad8d55eb4ade3571e873d143a8c099faa60ed7cb9825a6960c917a6bd639f0b34c0a67e9b5e1b88f5609a4ddaef2df2e8113d5a9355d7671297b761d5bee8cbe469c6f14d2cbba9a58d9f5cf1889b91b74b3671e43222ba1733e6ac694b2281a433fb1d55c300d04522249d2e4095ac8b5f7b9374e37004b653b9c9f228ca36c28ec6e0cc2b8f86f5b548aa64c9257e6749206e7550c7678b16b05d7798c4ff97bed1c038556bc5affe994fb0811984fbaf7197acbfce786355ab93ce146fc29678d025362fbd6b396852084ca78d3ad78c27c3b2e6ad98762399b0fdb89a02dce6f38a52012b93a6c6c56a84ca1367c6ead62991eca36d5d81a2376ee6eb1250982419878ec25a6965311bc2ecad685391b267dc6b5f2e9b51a2c9d9df725e3bc9cd7ad92aa14f10899d7bd47e11f83c88a017992390f96056610168042c9f2d9b4b12890af7ed7bed96df8bb151aecb9a008bb0bf473a43c5d5278229b1729224770986350903db18c321c90708e4232670556935eb9e9d187329be9d1c3cf6e8e196d893c6b832bd97cf776e84ebb71e8e0f87565e698f77462a51d3a6e282fb419f386f17553fca128321f2c1b5c8de3cd9b509db4ca3af5a549df4a3ed6837cc4ad326f3c8ff3f3516513ef034a3547aa2adaccaf391b341e2a8b1c776b05da461914d1d97bb29f285c1b6c53395d0686f5e6ecf053141f9bd2651889e31288fd3d46beafc5d29ae8ba19a2d8ce268d7eca6726758c54dd718c30546b1d75898350baa648f84c45d3c4cec118d65eb584b3e3a2de7bc71b50e46f1a392400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810997885500831afca4b61ce58e26ca0cb664619e48429431b41292250449d8e5ebf1c2c7b224c4a3e35b949951a8a3934a5b8764929541942b52ce6fd33ea3f29f14729804114321c9a9fba8dc4c9704e19525c4515b81ec40104dc7a294ee80a9da6b0df412072faf5c048acf9804883b7bfa9275456cccb06e101813d6ca69006f42c312ec576dd3247045ef04d23b006f03fb2a744aebeb6ff12a0e828676e33d79c4be89ecd71441c88a348c244a44a0e4e34910095912daaa9063d358011d5499a44d66da24422d4129ab8a64866d82a506f27cf06dd64d523afa42fd613e7c6a45683351650dd83193de92b9be1e426493973070425be9c4005b15b5c7ab3c9d9706cac192d059bc2a4285690c6a8ab920d7b8cb4f0a36bc7db52caebe9e80cfa4ebcf13a98ee9f9f004de212a5f84ec4b273e71193081cbb40b8a24819f125d39f62a91b32c9f26f949b3ac22167a4e65c864a1eb2a0ef0c5bd51f8acae5263d2879a9cccff90c0581509c4ce052729049da60e47bd0d4ab374e25a43a835a8822cb7cc8e76072a8cf8c80971171ca576a0e76d992e4722f926ac5cf16f529194c94fe10e012bd9f6652904985f9d62192ac3d99bc25b0a05cf90024b493fd203c21a06336f28c2c4e0aefe28ee5160408fc5359c3c3b540efc439272bb5ee5c3390c0527f7e2970f5e3210ac554682a8ee41e3aba04ce65e69280afd5095acc5800bc6473d4c56509cd6a54a4fa4f083bfb63897a3860eac8718c7c650af490ed880c1c0196851e63f0bd7de2a94b0a0e553d809a994d10b44efbd40e2f46379af099d4a4235c76a70184ee4c0079611b35535b5be9dfc8985b08ad4eadd3f0e0a354fed47297d7ac004dc1b0a8653f5699f913d0881150ea1299d541032f9872e12c857a91a12134ca180334d89b3b2b645d3d7ebe7117e4d143258b40ffa5ca404637532b9ed32bc83bf5fec7a4921cb3f2a6471b18ce85d6dfdc4a49cdebd895e4f6257ccac42954940d71266acb48da755c8777a1185c7d65a83953d43ca3ce0d3bfaa151498c6355b64df59ce401a1e856bd383ce08725ef063d5066a9696cb1a1e8e6126fda1ca1e4f4c91ed57ea08e95c344651e5e81aa13b55dd13b24fa37be643247783d4289d1c97daa6784b82715285548b1811c8b1915182570955a967d77e6ad5d4303717ab1528af6bcacf37beb6e5039c1110b5c6413a452f48a161967456521c25c281dbabab272664ebda4b63a22f3e4ef6980bd10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007dd84c603d1b5549c46964ff2987a1f533b4ced94e67d576a3b0bf1c8bd87a74ac7db640fc9f7ade44ff79b820846eb83367153f5ddddf9dfb7848a13d59436916efabb82dd61291447491d2ca04166fa8680e8e0e0dc98e79344534ca1cbddb531797a61c291606200107002091adfa927a763cf98cbbd631cfe890b0ed257afd34ac0c5280aa7c70bd0c945d78e6fda284cbb7b3ab636bdf17342f2ba28d707147f14d15173d9bc0b6d65fd1663c86971be1fa59da8325e1f3773bacc5b8d4158ef525fde6e96631c51ad142250252a8e5786cd621210df3e24cc0b4b60ac2f013d76db0c73df40efaa05a65383a8892276b3d69dd511937d55d914c3222a2386d1bec0a268e683716af4ab709d2d225b86229095e87fe70d69e6a34bb214529ca3f082c0f2709e77b86b00b4a04bccd343c862333b7c9163857b77e30551710ccc3a803323f5cd4eb5317cd2e6a24bfb77727e1c64d0ac47beea1cb35e5f2ff6024c06f2f391fee76f2e69537673fc0124e48e4e2242e84d8affee6803ce6edf3a954d2c54562b8b76a4edd91e24a8640afe67255605849053b60f558b43ddb9f8a04e987d15f6292962d10ad8f7b47188d12d1c9090c0fe8710dc3937c6939496884bde0bea979839837c61be4df5662c724610c7fcb4631a0a2083417be6a20f4eed094e2145bc72a83a6e147a655c481dcc906e63adc0244d95b6085fc096fbcce81eeb0497f48bb5ef827c0893e331795e3b301dc9f3a91dba9fbc838e044e2ad9859f1dc67e9bcc375442b4eb59714b5ebba87ac9a79c99ce74f8bc75740ddcce46c4b408b91dd7d4ad26b0fb1a4ab874f5504c40e7363838d22aec45c10d3cc2e233124a5cd8344249edf388e37ba43598f2c2cf56d444bcee04a335b154dfa3ca694db481cbaa59514098ce6e0e4138c0a543efafeda4aecc022c824259a06c3d57a70ea15a5dfc822449a27f58f9ef842dcbb636ce293684e1b331cd821594a12634e5594410b6c5e2306dc8bbe62c8b0f49f2f699a59efb14d3cad399f74ed893e1eb43fd770fd61e0c58e5d8cbc9435f4ad0892681a30df4885927130432186ad4be41f6fb7cfe660e23c5e55f60789b3e97c3b622599938b36bd1c0bcf6fdb7e4ee44c92b6a86ca2470bcdb8bab8df6079382ca314bf3a8b3c4286518c356018fd6f6fcdd9be9ad9c228f29135544e723a898f483e9d9ee843e75acb3feac447973d12461fee3d984f3b4f31645faea56852d356c96cd73a6f185e8cd56731e83fea145a2bf0c15adc634dd9e2ffc799b59a0712eb4d2618680c7493f50a9bbf3f7bde1025cd44afdaf4a8c42c9254b1b34aa8559e1cee9bde7b4da0fb3cb2289418110620e505b793b91f422fcf53adda8f7c96d55e26244e075d9a70004642712eac377ce18f88f2c8581694b8f621707dab6d292179b2a95aec5ad6e409d78253dcc05eccdb45683dfffb9c629afcfb0654725d650e4a283fd98e47f37aa9309e2933cc0393625dd81d4a02f9d5082644de02b6472d5d3aae110747e4f756973fdfce8ea5f997e30b11ebd50b45f6889d227d87d9184cbc6ed40e96def8b9236763c9999e21bfc1a74457ffe5e0dc2b16876fe04c2e0f0f47012a767a7ac18d71a7fd65f8647a7e1ae2d4d255492a18aa81d17d390e381b1722bc3c38bccea9d5e73231d0c6e1a96ccb47079e36c994e94af9a318d67b6408bb602a91d8e9ec6499deed0b51a9ae31d9774a1bef4c1de0e7a324545b2af9870cd733c2195c5ecde386d298c33d492937497ea5f0e05c377a4d755dea9d96c61fe82cf6299eb34b857217a2c6733fed64f5dac5f95a0ef2294eca844b96ceb5163363a31c58c88428152663ab0a2b310b1a9e9027ca8cc0db6dff528f9a421fa826a86acb4fd1d79c1ae6123c9e685ba66f5ff109fdff2497b1a50c2e4e7b4662fa11fbaa305a960ca70ff98e5290a8c3a27b4a3cf1705c6df4290fa64f3259fdede7a81cfde4214230dfb9efb20049e905833b5d48923c8ce2f8a104946fb3356154519d950998677c56c8b2c80471a6117b142e26c0345cdf0634e356d80c3be12f4ab89eb41dddcf98188ead2ff420eed3fd9287322f24c62b21f430d5f9b8592ce1cdc946616111c91c667006e47992fe2d5a2aad82f8dd1af3c1b8ba5326220645885cc94e8b2b76cbff7e161e994c0cb9e489b8a5662e9d420913af34433f5bab10ac72c5eeb9249f3c102e1762e862c13cc882d20be16834e54dcc323ea89a133f451b70087a8dcdc5b518eef087a571b570a7966f1c49bfcdc70ac05034d1dcc56edc2c0f57d1aaf16718c67d162ba330aa61a2875f90e2935752bff1ec28a79ead1ac18e70a833946ca6a15d8765e1a62aef46bed232eae89dbec278297b396cf611448c5fd4b36b95cdc54e3394c63b9b0969d6488ff1c700b390e7226f99a945306c6504958cd43cd3d63910a4324bb662a0e5db1622d90ce00e50ce7112193872aab5cee0b8d6fd42f26c2fb87fdf99062169c0be75c85109d4e209dc8a640fed3ec71ef3de8878b3d1729ff118f50f8a33361c6f707f6011454c5d744989ec1beb644fcf99cb2e7c3cd20e6f1656e07c3566c4de68593bcba0ee9f7bd2e272c3d47a3e03985456f18cafbebbc1de74964becabdf3e9bbb9a10b29bf3b458fd50f19d63a6231cb51cde3df46e4bb6318e81e10ad1674a053c8cfe1e72853fd60e6e642642cb825644d6734afb00329839f22ced734fa1421c4334e20f2ecc8bbc2652004203b3b639fbdcf5fda1423f08c3a1100655e4763b8d8356a151d702124d30fdd87b34ec4d34bbb3639464e44a693690e193329000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 60","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f39268464f3ef41911707137b6a6e6c0935361f3f0278924d7fcf5237a3bf73317bebee688b1965f2be1a451aea8d77994f28597f577543f2abd08e469b12f2ff1b22d66bf6b46ebe1f89bfc62c0b77bc91403678ec26591579948cd108f5f33fed346e6ab7db6a1a0be3a2c138092ed2f9d745fb137ebe7edf074963482489247bb96cbc451d41eb6a4843df4e073a735be04f25d15fea5ba357a92a65ededb92132b22dfef1cb870108635be8afdd876512def40daac22b6afc79bac02f8f6a979d5a9a2736fa22c896ab5bc675a10e793128a8d10d805538cc4c757e61cd62394685b5bcfc5e35511aec1d2b50e7407975f40c9934acc58bf18ad79036f08c3cad5f266a900fa96c39f0c6abbd9e51db431bb7d01ca28083338962bbbca5bf6e44c9e47c1ac98c21cc167a529fcdcb7a649561ed8b4011550dc2854d17c539b51858bb3262f0e8bbf091c18859a9caa5dec4b4e7ef2276231388f211ba5b429063bb5a847912615bcee592b1602ef6f8729cab22e8435855dcffce776fb85574dfe6565c9733fc699d16af31b745539cc4dd6363d35a228743fba2f91d75469939d3ab91754f3da7e0a4bbe8c6becfb8367d8491fa8e22a647ff6ecbb78f3651a69864494385b5d9b3093cc340db29cee7d75f6e5fa9c8b257ea92ebff446d0edfa8b1f6f5d2ab79589c377797796cd9b732f7d9613acd235888e8681ab71e4c78932903ccd1cadfdf222aa240690f45ec8026fb0470d6262f098e4825f57e19956e4e7e86094e5afa77a80204a77f986d3b89e595044b4906888e5f6fbecdc551183324c6cbf253bd55ab61a242bb93743aa97cf26c529fcbf8775eb5b2209bb7f869fcac86258ac9e9597f8b7430fd6a26185d9c50e85936c8a3bc75723f9ec9946e38b666db949bad69156ee90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109171dea4088cc125d52873108c5d838be0c879489fa148d8f2bec9f902a847512ed142213191e7be1164b744d43e07b2bfd6d964707b503935961688517abd956aa8685db2e4b769676787fad3c65f011949056b441d4d3b69b9ec927f1992602a5af10c5ad545f6b96331a01fa3b97ad9918c085ccdbc1766c7fa7892a5e8bcaa018e6aa5269ed3ada41de6a50506ef06481eb4605a429e59cb385fec7840b2cba691630e3208108b2696d98c29f78218a7a0533093d8a4477323856721b882a711fe32092896d389ee5041af89410ffafa90e744772c50585bbd61b01150650924e1a4a6fe5dd8cc637f6ca93f5aad6cf42cfe1ca127e12a0a6414796ae99f2e5a8ac7ab205476313528422d769091e3f237cfc192d1eb2767dffc00f8761357c502a18c08b87266885e3a7ed18a6eb068b0b5f9791ff32a703da047585b164cdd586e8ac5ad96f97036560076ba88343e010593e19ab0aac9aba7f172644b960d6751a9db4e2ae5750987f0110aeaa2ed059b23ea68306a04518a1439a0f13f5905ca6b03dcfe37bf5db80645d47742105848d545da961d750995b3c7d708a449de71067dc6f5932a7ac55504266f5505363117164b4831d2c923215ce11858e25adc6fa87e658de459061565e36f43989f6abce8778a74195690e6ca4c6877ac8aaa56608c36960941399ba76e3e420845c46cb10810c97829b75144af1b5c06c32e22fb2774d0e4980a2f172f2f33526870c3f2559f49dd3b8067a4cd47247ee7541363347a6ed0f4c99fa0c8d4692fe9e9b85245e1d283b979a00cbb76cbc0b504fb221ba9b95b9439e2d9c28d9e8edde4dd8e7d74651a965c5adea8fdefa1ca830fa5b24493e0dfb081f23af6a943b0bfb4b458d21f091fd984c73e4630797e8c7bea18faa83e58d73409a61ffc013999858e6cdd43a601af6ab1edad4b09d4f1a3fafa3452c0855bac0c84f1228dba9e11bbc8a7cb69beb57b30188394361222aaa61d55f8c182ec60db2cf85de5ff8d95082229f2e72cf009b2a4b6131725048aaa357fe186ba5c623a18536956ae75564e0b9b74263d06065a86950aa056b49dc93f40eda54c8770509213298d00b92e45cdc34945b90e6ae7d0a5430267865cf13d93c3af117ed8fbce293f19a0ea999b75b672720437effc7856910654e00caa06b5649023ca5469aa5621e8e62b8da9d6fed23f91fa6273275559b756a6a2bda7d830c401c45e88c041e23af642c8950089db56e827db65f9b9b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007fe92d5feef68737ece61c6e0078d77fbae97b0b9235f40b97099c114b1586e107b5ed1308a8a2d20be41af129da2e0b38eaf02faef733c7a1d1a387bc55ef008530abc22697d0465aa3eb71f41ee72add236cea9a25995f3689c5a451e2f03915d96abea10d356d549d68048977587326523ccd71c05fd57bfb3c7a853f535beddeadfb84118f6548860f6ba536277ddd7ab42123e93381a385fa3e6cc023c1458a9f94822d93248f36c48fddc972b5d6494b26658440ffbc23b57363f3d82cce69fee4747a889e85343288d55d30fc54d2d0744744dba9977720e8edd2c0aca1fc51b0c6a3c68bb9bb8da0385db1ca4e9ce660cf7eb2382e5e95d2ae19def904a8651dfae53a4d0dc4d057ab1a506c3bd7e1d1ea3fc4623e7d7b410dcb312f037b7a5fde5e0e604fc33270faf1ffb6ecb3125ddfa5c49f25bbc98238c8ab1b903537cd67238995e81b814280a4ced61513d69a2178086d505f8dd1df7e11ce66ae33d4c982f94231957031a258e0ec745672a57a5ce76d1170111b8882a9eb5388094ebbd53ee9ea1fce4a275f9d7060c8da79018487b452817280c63b01b05efbf897387592e2bb3bb486fae0ab09f46d9f2e176de96c59992c10a14ec16eac36102b1d15541607075e67c842a888c87b268e9809148a323c423220dc31566b62f45cce1e2bc1b3bf43b87c998f00023890bce517271bec16efaa33f11611fde87f197852bc2e7a2b44f8c72a6f79b22f73be0611b81efe09253931545d2453939c46b6797cc5dc5a8f1aa3bd8456eeeb84ee76dbf2ebf32598750ed10670df422c7d7993acc55f657e6e1b3dfa1bd6c1cd55fae97e69d2f8f5af368f7da0a63b4065eb6d8f02b19a34600252fdffdf4ed8de2ea9cd2e74d63a6cef29bf02f92d346ecb9a61081ee5ac811f33aa5792f6a1af570a8b0846f3e6ef38452346dd637b19eca37bd1a6c42b20a5bede9a5de3c9f169d04d8c6cf5376d3404f0c21dead53da6c169f390eed7b5b54dbe47cce0b2ad1179ea8fc80fddc7281bd4fe31b9a26a00444af0b4d40a1b72be37501308906149dc6fc5cf02b6f60aff82b975fc8f146961ebccb4d126add524a9b33bb16f6a83c6f3727a72efa2bac116e493e07b2ca718a63fcac8e9d52a1b61479b4ee52a5ed30fabcea4d01a792a92676721286814f3b0f4e15e23ce0c5d59a0c3eb8573c0a2f66c25f2eb2fcff787324721004979be5eac505dfd39f5538e2c1b2cc12d20c1c5cd87299766361aeddbfff743693081842378744879e6e6371b3ffa9ddf34966fbf8dee91b7edf6eec3e4e2f410cb5351f847646c22ab594046ded63347d04a008fbf6ee9696c638ece73b39a269db239df36443868ad44d26a5c40fc92dffb008e436e5c18907f5b18b5e6c5900b41a9801db070d2db651187a4da7e2647ed3e9b6e9781627eb576bee8334374468760dd3b32985d42945d953d434bfd80d7f7ba537265ffcf27db0da1abdae89bbe94d98bc9ca197e41c0839728f964fe4ce30b8cc43cbdcdd9ccbe06fe99debc6f4024f3f00d43febcd62a1822a6d507337ee79d4517aa486870602d4f1c5368b0eaa1ff6c011a9a953aae58c75bbd3dc78d263a578c75cdb1ab324d71b9a065a9af3dab854189585c68d499ae8db887745e20ad9738705b9d2f5d429f12d6462e5e2ef9ffba53ce2f4e75449d2a7dbc3c818e61dc546175a6e0c10ae631df6b1eae6d134c08466ebf6eb5f8257aa10ef8c6f27f4295f7ebfd450629f3eb4e0f4be247ad7f5e80703b1247a4fc277311d69e5d62e0b0201a805cc4f1f807de99420d563a703493ad35a56b2b2dc237112f5ec21c70bf139a9ead8f7e921f086e001b4c449e42a0e3afcd5bc757040a2865d0e5adaf98e37e6f8a501ff39cef0bc364eecdffd03069b81f5e1978c397862fd56362835c059fcbe4d8e2a957fadd7d05bb195e21ad67b429621e1d6872de2d8bfdc91544f9e6ae8c164a23255ad0e00bcb21456f8fa6ae018f49605736c81a5ac0945e2d965f1493ed5befce512ae93ad91daf6f5a151d6c9856dfddd1f877945d932261ded67ac8231dc3ccd0b04dc1b02079c897601e363ffb9a3bcbbbdb0b0a375e69ee4a7135c094abdc237faa2e5f82d2556290adcf82adba8402c4fc9d0724f15bb87cd7a75a1a7bf826896d8ef63c7a2a3c371756af638706270652c376100ec42fa55196df332820d377760448d3e7adc42e9f5d8a7074bd0fa97433b0e2c501252de6939ab948552663a17dd7ff05430fa76e29f0519d650b86fbb19fbed097143fc242573e3e6fa4bd4a2ef6d9ce6932a066b4f9ff935ba9bc26fc2e5031c20ae30a52970a2df3504576108d5f26517f8577be61e6aa9d192ed62cf36aa641da0d274b1ed5ee864b549154eb4115658e6c60219cc5b2e22c49ce3ba76a85efb549117e1207f6df081d0761421262e352182239f1e34edbea4bcd8fa0027543824dd58a20324fd4cfe943aae5e361c367b22f587e2f9bee841e11875b026f12b9571512f72985f98f6d0c212df36a60975429173e317f6acf72e621f30654a6deaef9e9e455524bf07ffdf44642a1826f734d69f3eef4d52f26c06376c8f71dfb65a24a4c57d74b5976950af3a57b4248909524bec47d858c69041eed34e0ed3b111bbc117ab112bbf947d646ab3b7172f5fb726dbc53ae37956e29f5b6b1e3c90baf4e4fa544ff63815fdf4ac9a2a80ca0e8722383437b9a02f3ac538feda7a6d6c1635d3624a385d846e79e956dce483b89c346c1287a1a7293168d8a885feb6569ebdf3f47f8bbb50aa43941eb20001959af1b9b358aba13fd9bbc596ea42a9774a120af091d544e79c50686c26b4fea396bf1e4c25b8ee4929d75569a5fac521c77b0000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 61","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002903934f21077fefcc47670112fa772fb9e8ec38c35963586db92a0c8e837ce2729321e538d22a1e514490263d226ad50c18f078e55b755530cc12ec3171fa47ddc4ce27a1c528510a99dfe1bd893c9db07cf7de341b0bfc6e6344f73a66b1bebbbe6d8c5f7f1385e1dee0d4074b36c2abecea58c8db14071244465b484d137903ceb31825d27d00f3649083fb9d8f10e851c13f78ad8b98c9c0efa6f09779b3374820b06196e33dec20ba48489cd6716cd1e4811c5378d829b73d3b22b6f86ff90f9fe6279face066ab1fd5e3614bc233f6c5a679a329618964da169e35527422691d246dc944a37f5a5cce1cba0fa9fa78997ad4a63b08590c6f5976812a04a32fd3b0c734cca7b69f5b89e1cfb134b5eedfd8b2286accb5a250c71d332592a9e271079b92582f76cc2a72b9e188cc655f4f35db583635692abddd4c06bac26289cde73d49f16f248b6ba1469e9f4621d4f56760f7a8ea0912439f2c231e8e5e616bec18fa651b5acfe28f32d1c5b0fb098b4ee168b78cd5794e8f3724aa255f8db7993324c9ca63b848e3c59accb0ad8eba81b39ea96f4a27d656f749346b92a534581f74a890c11bff32aad3a3db71a460d446c0e4bc68ceb35391645295e11edda8538618c829cd8aa5843530b4195173a7fea46166c3ae29c2eb025a5926e79898369084e1926b24f1c458de3b4db48a6febd1bdfb7c3e0752ed37297ff123525a568b4c6ace8f0ede8d6b19ed7a5b70ae264947db9b5dc376b87d8fefbb65d7253c6f453622394411a9c0ce331f54d92ec1c38b4b0dc16ad45f1e92c137ed5a18ed9d45606227a8b3e8e07adf0ab95fed43f2c88a7b85ea578856dd688d5ca2990e03824b0e84ffc2701c892624da9357578ea323584807613b41208d4127a1cac9635784e135cc520e79da3bec0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381090d084688c21b232d552107be6cce12f609c4dfc3182f4155e480cbff882e6a8bf350eb73a474da862f1e8294b69067ca803288f557b895471186453a11cadd0f4224fbee4cb150a869804617866f75f2217de3e1bba1d90be5c17e637957b1199f0a99c0f134e56d3c09c17e625e0ab924ca9fb278cbe46dc0203bc7df0037504ed3ea0c9f19440d8a9c48fb5b606ed3b0cbf789acab23ee12f6962964181599ba142077f7b6cba20cb0747459d3bb651a86542c13b1858e20587dd5256f0c4445af985fac995f38d99ca89be2cdaaba4b2a1234ee452a1885681cb498bb65013606d139b40921a8fa6955eb02e92c10de989a55a4b9f1f6aaa184f120f476339a288d8029c2e39ee4b7569a9379358d3c2e5a64e75ae32e590413ab392549a7d93985b7dd8e091094c679a628b359cb6928539ba91dc370819c316c4e81a6c38cfcacc24821898c488fa808b5baea865a550b79fedc4457015d4833844b1c4a215375d0f44d6c30e45cee9b3350fddb9711972fde4eaa69c64c3e3e135b3c2574af5a0d4669475b63c29a97dbaa35057e55207ca5309e80f676f1d98118e651e56a407826dd69966e45ca0c192e79b1151e6c882943ab4c6a7f04437b3c9c6532ba3e978da86d0ef16079a883849dd5db26d0a90e20802cf528e90e4b7526b4d31ea27b01763808912303009bc7336d0121109c780da16079ea2ea20592cf67b12a1382a131a36ec68b05d06c88081fb44e662c01ccf4e659c6c1620c8fe78c4dab2f508088ecc9ad8761373382ee14693ebee1752ccf2a1ef471148a989ca8bfc7425e254c809d040d128b878a43772bd32a723c2f1651667869040bfb5a0e76202e74f716c1234695ffb983a285aa85a1826ee3147fd4c5c1880896a7aecb5bea88a29908c17bd52b4787e86d37f40fbc0f7495d9a1c29e6b417671e289ed7a74e28124066c0b65571a101688410055281a2f0d2c8c0cc28318676c4e64a24146e64720b59216246b91b89bf52be50fb3e488b4f8665fbf86c60a76ee1868019c43a6d5a2241641b39aea4f7ae90649ec2e0448e4e6e69ed67a9f74f37ab69cea91969c28cb1d776d6d2b552c049705824e43294248919dac36b5db3e73503b09361c730bd528605c6f3875c26ca36b64853b3179130ea5f421914378939709b89af835d7e05bbe54e50a8048ea638d76a244d32fb67535d37b83eb103573a1652508b7cc759672608b28fa4e96c62976bc8e28496c611706287a0bcc555c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000081f7f704cef1c510bc2cae9b70fd248c656226bd5686d366528f0d0befc0a8761ec640cd2da7979de5eebdf6127f29abb8607f8a3d3be05be25aace7fef3063df28e22a522fff0b6ff6a0c61f79b02a408e8e1c775ab80be6841e9f8a9d030ae5518e3ea8a4e31e416e087d47919593598fd58122a9e601a57ef02de183d56921811ae2253628125c24f93c84361c5ec99e7b16962bd96ca190c68f3aa9dd60ce3aa7610589813b4fb77a4688308d9bc72cbe918583e298e03ab95fc500209c14abeb3a43baa92dcb11cb523c4d17eb9c6697b56c8b61eda05bf5789166f839291cfe2997b7dd462eda69b0615f2ad82aac0a32f4b30fe8725849c144a9c07799d6ce9d293c25d8302161757b8c8c8d07032d914ea7dac275919a1dfa0d3348ec07fdc70266975722763ef85ec4af9e14288c9659907526566bb3f2dd5dafc0d422568ca3ae52486d3f2c18b667e5622ba7e52c56bf00f82af2108cb4949a09179544f30758b7fb98c49ea160720991b14e2858d648f0585ad1bb1d08294f029bfe936154e9d328df2e054004fc5c29070df9ee50dcd0981d2bfb3aa7d6f637c4ce457c0c66d27e2670107a2b85d1f026bd970ef3fb7e32c60218d5e43a06d9cd26289a937b4fbad2a831425728f3d0d30c6c602af4b14411e9b3c7cf0b4d630614a9e03ac30ba2b024d496da984d08854f1366012c2400a5c8268c2b126dea5aeba0de7c92be0af08ca22e02604a753702bdcd642bbfa0cc91bd8375657a957306a76b6f139621481b6f15cb57bee128954d30f552661f906d8ab42cf260f30f88993bb40c9679385f5c4639888973361216df3c60c57d9b250f64b7634c94dda3fd122713fd2405a7b71f476c263a781dce271e7d0665e45dcb27f7293de57312396c58c40e268f57ed856f536c8feb4b0060488de3c25949d2b7e64207576641b34920d04b46766aa2978d9352c2769d49f8599f3d0439c928532e0ee428a3773fa4d68e6052335c6d93368e321d750d296799faf87b82c640a6e995d18dda002887f141db8ece2584da2fddf848d38357d585cd619b1625a70a5d333561d6de856ed9908d1e377ef7be03b326594808be58f7fb3939e939b73f11dab3e572dba41d43a046b8d2bb521728222d5a77dc886ac6f328d9a531118156d791d64f5df8ff8be8dca32eabc3cb259b0f72b021ceb4db36a6cd2fd149437b251f81f7588ae921456bef1a79fe83447d80caddbf20895667ca0e493a4731eec901e03f66de284400a5558922ad53d4e0ff7bc6c61640ade0274c63d94e96bf6c642b790823109f53c3c27130a1ee38d448239187f5009373be328af866a9b8dd1bb735e8002296043c6ff641a432709148c707b900ecf46555d77644565d5998c096756f79b6f0e20850b8bf0528e78bf5fb4859bd655227873d289cce47feda8414d09ed7e8d380fc4d580c7f44b01521e829e7b0cb2d2f345c517b65e2d476687ec9a4c160a3ac0b01cbaa588644d799b125910812790f06c1ecb1f1e64d5ccf92ae5e8147c98b0cfad5626bab5115844198e8c2ac1df9a208fcd2d2891f4a29009f5b36d8e31383811a9493cf8e143b5ac8a14d48119cc16d2c6bf6826fc47d4b782ffc76b64401b8249777e32c1298606553dacf386a22809b599924a635796a1aec3cd8568064852e54c95ad887d7afe837f6ff676f69ee6288879f6d96193ad94a0418bbba2eed5355876f2c3497448a5f8f3f83b136703d9a38fbb62784cc233df448a5e88eb5f81a0be97a16fd4caba1d87a4bfb08e002eba548f662d496a1478bb7c26c69ca4c100aa6872a4945d703ca812bdba53ac86010aa1d2c53f29e46ad095936ff50db8805df4b08c9580aeece3a6ddd828e7b5d4dabcaf112a6e35ab3c28a6ddc4d98ad1063c2ed72caa50086e6b72090cc1f2afebec6751f27ef51dd8557e53d928535d82a220f62ba0645e3c2618f3424ea1a339a138c9b8e26b14bc32d1736a4193c0c72cc402c3eab58817335c1424bd6f38cfe16338611118b4100e4038d07dca041c72e485c5290f0dde601565dae9cdf657a4c7839d3ade72986af396e767430125786e219bc5736f16fef66b4014e5961cfb4cfec4cb2a32205a92dbf1399e2710395ba1240d48277c120526cd9e2352f7d04d89cc2754379ce80a2cd1ac765718b8ba61ebb8bc6d0d407022e7ac672065fc8503bf5bc4138520cae233ea997463d7c9e00bbd852f12ec17c6f1db1914446aa21e156d210094b699b4117b31eae6386dc0de1f55ccec09aa1eb38cde4602598d452732c5ef8b07c477e3e2dd470737eaa7357e2e8b74c31a117b519bdcef79b6b044148a10468e38b5a6b7b10d74c6130a60a268ed73dc9a25ed68af354758fa3f57ed3558da654caca7150a8e4449d0ef640184a7a33d00ba765b01c442e88d9b4257b93904ace04375679bfd8271a03073e34c4a1c0437c4009a9590cb98d0b5581dc83407f04a22c9b0246de38e1a13f9b1191493818783950548be562f940240cdecd4a50c94e406b1bae04b50a3a19e7923183e3fd356238c45ae6559193e0e846df0fc6878be6c963aa8c3508dc31f766a4b29c78d749c89985ab8f580dbdf7993a2261cc4bbe489c3bbb38c46739bd2516d3c64a93f10cf559db6a0ea3bafee8b43f696a5288c66509a57c642bbeafb40f4cd0649b4ce25b6fb2ef5529b73556051213bb39cc4f1dc8004b1588c8de836699c66ced567998523ad3ac303d9e13617ce6c1d2fc4c35b22a24504c51f64155f24d91d0e8785b40912b3dcedede71a6933b36bb514fdd1d3d843aaacf2c1e79a5216622c20036c9c999dac3a5a2d43fac3b23119927806f497b4048f561a2276fda0302423147d35579dd4411416f0f59273429ac0464ac49b230e29dc124115d18a045663d228bfdac9f57b0c5b400","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 62","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39fb3e2df8e48162d954f40843cbab77a9d440f9ccf5d6f021f843235af3ad784fb17c01604304f167d2ff5b695155bb9f0aba3e35d8663cad7ca7e215fdc9fee4a93fb90e6dec449661ac3c9d6e2a6dbeeda57bad44ccd7f363582a02acfc306d040a199bea9802d9121aa8fa6ed6fea7afef3916d1f55ebb4d13cd76ad481beb37aa7b232f52b7fa2dbcef6d729a6e2d96050441d939ee844bcb5ca2d38fe3ae458d39da1f0b15b689eac9da300a978aad4b1b54a8f8d15d7c6a18d32999a6bd37b14a8ad3e994bab4bc1ec62d88732c916d8299776c778762899d8a51ba59e6930c8222e82318762e99bf27cb28fd1b9a1cb2b0f5e9222d03a1a0f050eeb78674d9448f47f766bfdbe5a8b1b21e073e55095931f3379e74883028d34ce250d59b44c0818e5bebe4dcfd3633a6f37461ec701c1b93ba641c7a2a3bca5adbaecbc71c59fb937892f3a9b7ec3e1868dc244a5bb651986bfd6d2a15a9b921f58758dd665d7fe7424f02ca63b5140d7b6dda60d3ff1f6386b97b3a952b00473189c55341bf655987e0af3e22d0fda8334e82e4a155da85350dafef891fb71f89e9bf440d07a655d57a5afc8788c6a75129de5d507bd6c7b7d087b3e7430747b749984f853d90a89e55472aa6b7b5edd40661419d6dbfb8659e7d6186b50e0b31d089d0376b647aef11d6def3ac9d308ffe5a73c126e83f7561ecade395189ce3c173dda2bd664da865df0984420ee2dba11393e136690e247514256512316af59a165b9ae26d8f24d22e5cf7cb6219296d114202bdc03e9d192e4a22c67ef1500bf4ecc1b06eb369c2420d571db531f04287f640560e09e022180323b48889ab9a7bd231226a642ab3df887c711e8bd28a50b20ace84e00ee257e8926e3d3547a8afeae10c9d44e2bf7f244a9774800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381098850f5eaa1d4b11b710f884094c99d79f361a0c7e75792023b51015766681f46a6c1949cd99fa59d195e4fa262a436e65ca4727f031aa2d521554866d26a019bcd0b956fd2e178361a7712e7b082d1ef43200b87582af7b4a9ad26ba80cb9403d0085f9ee1f17520064b6dc805a7e87767b21956339ef62db90915bf0fe4534eaeead1cf5ea5e988c5a9adf07dc5b7ca1226f2acb834965baaf577c4aac203c03748f6202045217681046c3b01a17c31b5ef413ad7653e31a285e55682365cd0731383c9bd01b2e97e695f89268d823b60076d98adeb1c55439efd31e64ae7814bb97238172a53a0bd1737fc0d0e7fb02c202d8db91f19e543ad61cf2414eb761c63d156b449633022300ee910db7ca3d173703fb472017896a8f0637d0d9d2432437b9ac7a08ada634389cbb8344509f6000f9110a04982d5543f092ed088a5a4a60f9853b2eae3825e4ab886ada68086aa0067bda34f27f6802081cff26f663be1ad69c3669d0482e4e2a206a25ab06fd78763dc6bf72e99671ee2d119f82ca73a9265838bae4960800e617a1d558328cca93cd0590d51d60117a6ca807d44037d8e6529083b17e78c4901ead9a7c0898510ac5a75b3e269910586d896176aac84157b00dc255bca81cbd30ca1081626a61dedffa12ccf0b2d24fd33f663372314c1955026465fa066234a87263213acbc95e2832b4dc1737d153b7047db15453958dc6c0b0205f721ccd11d5e68036ab387748b7ed0830a4dcbab826a25856b99b398de6487432b2cca6ee6f7a5244d29296617467f57d845477605e410560d52436a465e4ac6a57d10c953653ceb93250c9a614d35a80e287d201cc6c185bb65fe2f103745a88b6098509711da50889ae2318c45ae56c9b15d28d05e7dbfcb00c9d585a54a8bfde50965ae466261511a4a7e9a26410271a27009ca06df3d5c88adb50c1d1f7609c90846a8c887cc8202892ba7040a05a45c1dc474005b9187495c7e693e226da6f354c8a9dabda397796598c51a606d78dac5e7545504878ac3fb8a9aec9041e8c73299b86571b2dad6ef43b6c2f49493e718a1b28f475897977dc00c187eae86968af69b45464545e4133719ef9c6b327ab6ec97042e40058274a9ab8f1ed5d9ee6d3b97b20727386241121ecc9705987a3bf04339e0ac5bac4e9de5d3d7f21c541a59c5cea01cae06a29ce80480b517858903cfaee93a4333a9ca3edeeaa97fc6c85a04a81a39475c09bcbef74a02dd3451ac8bb28aca0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008402e086fa0c4582e0c6ccb020f86a6107475985160bed201760d6489cb05b8d21452c81bd5d317f8857703daba24e968f3164c82a4a9751dd88742b72141734dc0b4a77cbe2ae1c287a396a2f5804519456cf1eae273a5c6361f52c35edce5ed7388d61d01ac040676522c9fd7b02a7deafdcb4169867efb69792210a7069287c5dc958d0953c36f84d9a26989dd3b726be8b94b41dcba1b5374123f55a6dbd6360698551c27d16baafbb0ecbe116b44f11425da45d7fe8aba91697d83b6896a06a7888c97a91406b81b3a5bc8b68a984750893114b4011b9c8beba6f5c2d7d9f2c7a27030555633a0f90e30753a04b1958141af7c1b95ba208da36f729673d20da0a83f913bec8049f8cd032d9f9dd94b2086c61643ab2cffddb2b9be0af996d642b7a0a31ce0eec8c61b343aba980fcdace9ced7be4c9048b356d41002eee0433428846ba4220efb7f493ff57b0c706282eee448cf7da9b17b32d0eb0016983175469aa5bba53489ec56ba3a92a70fda2390e3a5d8c038f496e7c3180c6971a39491eac10d828d44b3de2be64569b907005783e62710b9ad8eb8c9af4b04993d40d1ebf165efdec748fe9f6b334da6a30c568bcbad095998a47242ca16803fe1720fcab85233ad76ebde102a5d93ab98460494bc886bb04c05ae89e157967747f8c050b33cca52ed5e59050965523ec5c4eaf94cf2f2ee80c35aeedd14e65d937c92855d03fc76abaad57a21a42420819ebb9aeb65f031f9c4ba0ac2ea27289e941db89669a0620797091aea3ebfc2ac354e94d27894f444ff9e604c8bdf7d6c00df0e7fe9827171010445e737d0a5867636e3488eaacccfcbac1030c0dfab639ab45c5ac5435e2c5b8244e58c3a6bac81eea408020bfec66ef55fddc618083ed737f4dd3bb65474487caddf3aa2720a6931fc69533b6491dfc7e6e5fabf8103d05f870bfefddefa20822a68a710b517065bd2478ce080e5dea09effba3a136c1bc9d7d8088f736c363b30e2af2a6f2395ea8161cb64079340fa642c7763e3bf0623c968a16263cdfdf1b8334e427955e20c1ebce8c8cb136da8d002d8a9e5da3b1f56668c1c59e20dc3be026a43f40910d3a2b601d9d3ea2bf6d2c2781f976ba840fc986c8af0df84b8b0fb291d1310039d6914f8f7cc6b26cc33af94150253e8eb410344a64344a5a0c06e0f3aa23c68617c6f4659df79285782c89bea3091083a069ef8f048371cfa054de45e32c19a44db5d435bc8fef5570b68d80d5bf5dc06da13c36e3aea341ca9fe20047ac30683aa9d862306534ec93e79eff79fe22e3ba15e2ba3f59f7b8b9314dce31095d3015710c2927b54ba6f46d3981975229eed16c9b17813801c7d3cb3604de9b7a4f18c2f91b2b50c1f43e87198afbac718935db9cb96d9fe048d969635cb9f4dca659ab1612a698ce45336b8d9ff5468301bf05d04b3558d66e88de88427fe87e65d36d3c29fa3fb126f1f294e9bb391ee427001c34126c6622905514ce153682754d7fb1c985ae4da600aada1593a0a214332b310620b1b4e95bcbfd6eb8a241cbe848bab37462224994e0d2f3f4b521dca4a9a5ab10bee741c5919907afd2552d4aa300addf67cec2862420c8d1d8dfff60fdbe2d4a8d03c92e23bdb3400f5390ee4b141c5843b1e2c07c9afdbc70e3fc08e2840ebf3b0e5296e1ee44d12e68240fdf063c07bebf01c08586e8153068c1adc744a7b54f53b0fec3c752da9f6f989a1afea4adf1ad6ae926cabe4e0cb2cd864412daee377de559a38047f31e834a6ce56d4041ba709945f07e514f96d783f32b0efcc8b889faf2b6d217246ba7c07b687e028f23d2409bbc12d6ec0d94ad9697bab6395b7070b6feb2e907a119209c9b7d86af953ba7d2ea63982bcd794a5bac69407bb7cec5e027833b17420f146ae08f4b753bef6ca0922f3294cd2a670127f9d2a2ca78a30f62056a425cbb7074c9a55135bd06ce677abdf33b420f66cfdbe9461bfdf385a97439b3431cd29decd9b5e59ec3adaae879a4e8d5e28ca13e73fcdba51c828de271207a5deab373b1b6677a29acb87cbb01f10cd2c090ee66d472e8db61615a5ecb84a7ff0988dd0df9831bf43d732a12ec8cd50a86add12a5a2ea765744b05f73725ab8704eccb08bd74517f21054e58903481e7a724f7ff24c43d6cd23de84cd69c9e464e67003903c3858a6724247eb929716e170e2d2739aae10b88bc3fb8ffa849e385b4113e78c24de1673fc7e7285e6e3744f3843ac7be7ec16bf74215694ce467a2e859dd4facab86250fece28e0a6a31dd529d08566a6389b85c310c28a8dabbcca9cd6a631ef0473abfd6846d8326561cc9cb8181c1593d0f15efb8129af9e838af518477ce361640169d9731fc139881d452773f21a3e79e514ddaa513d7b9f3399c0c57d21eaa00d44a7f031b79cac9fc304e936e75a0cf8d204a6cc3c0fa7d037dd8acc3a33cf5718061fcd57ebd06a607fe0bb0204e687b2a17b1ff47da357b51a753076cb89422098d4f880f831842957e648c54adbfcc0e488a95581e709b5a5a129da7ec5b00ac9b18b80533f2dd1bd0f475a61db18fc0c4ea655f602b207b572234230c831b26cecb7bc3284797c4bed5a977c3bfbeafea3dbfc4257d4c2c5bb8689830ee157f3b5aa1eac09cfce0555880a074aeb86062a8ace19acdc1a25f8d0e454f50f119d12e707d103f3c1a502d4e358d563e53554395b5d386ad49363978afbca2f8b673a693acef70d1db4ceaa8fa580160924d4f18119be46c71e09fdee45efb14a74db1c688e99e24cb6025e73a3e7f0f7ea9c485274d2b6cf9784cbe39e388f9ccf1e2e8dbfa6db43355391a369def645f815424253abd0b6de9c0a0af156d9a4eb7474a2e5937f008134debc9fc7e54812967fcf5bce28fb5cd43f1aa240ba2e9cedd6f350d556db1658868091e6034d7e1ee5c6645d0a345d46c42e23c6821c360f5acd13f589","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 63","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000292399478b7d63dcfe5827b8d651a992f550fcd6324914930c213cbaae64993f85fab338a8a0547427802fbfdde9e65e585e7c7f2cd9169b2d5a65dfe14deb7df7297fa20c828fd256344b55d7414c51a192ddba45566ee032650f7cbdbdfb09262d1d5c54c7608ebf7884bccbb9e505859ae0decc3af5c693254f430e8391f71e407e59442cb664b41b892f99417d9b547ca03a030983e2e9b3a800a32959b99b1a427006a9178ceed24c797566092cb2857c3d50de392b4a96585d8af1a04871cc8609ebb9c91a7f848558542cee96d235df42cbe40a410851a12888d439eb17cf3265b4c89d9ee3afc8739a3b7b8b2fa6cd793a39fbb0a793e8b492f3e7db091d513fcce10552d9b0d36850261106f23136f78e9cc4ac4f4bb6c8105b3f83036fa06a86649c483ed0e803488b10c8d9eeddf9f59ebf5266b75695973483c371cca64b8f4a6459d395c0927b6f115f6c70f693651aa2aaa937299d111e6955886bf3053f15312fdf546c9eb8bad337b4b576de152924ec40e011685cc16e5c5c69c7c20e0f333cc2e186dea073b346ef47f96ad769edfbb3605373fa993a27d767e2071920661aa21918283f2dd68f3e8f3e8db37c3a1f8b4439b3c3e176baacacda2487e30f4415ae80c0df0a675a29829f4649d8ea23d8a754d09866d0ac69646aeec8a56c11554e9bd1438dce566836740a3bbd8b33a6ece137352ba6789c29717f86ee1089d6492a7faf8e8cfc43b2c96491b5afffc46568af5cbf545356ba4a22a7f514e577b08afd164940a618b8b36f68fc22ba9bb64d06b6b67c360ce431ed2b5f3d1d5d350e066499e4aa695aa2b6ec82d9382b35c6b22cc8b446ab66ed6d21c469b14074aa1a33fadfcb26a9ccee91414ba5aab6e85b9f86b9787ee69813e7ceb4d3501817d991bfe9a73919c8400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381092b603bea9708542df92344b19916864adc580951495cc4ede75e2f89058ee2138f9843bbde7a2baa436318918c609620c822c87d6361c5177234e00acf847e6854b5957482bb09f4dcb147d5c640f1a2a54fa6e5a5d85b780f50bf9af5f8d94b55553846d68498e4e2a2acf3a2340d8f9e8652c248a06003da365a871be39085d922a1ef0866fc4c0431ad7b306e1a3adc14c475857b259344754efd0bf9cee6eb27cdd7185f22feb2c1db8242afada2ba72bb7fab3a43d6a673790d02a8517085c806e94b4221d070a32170dadbc7336f8bb3b8da0167642779e59b8684ce323686a8c8955dfdad7617b11180159e86e3919cdc5bb71d73911285759172a1e0998ad638f084c488a90a3955ca30b5eaf87bf2c6ba6d43ac46b257a829cf0eb0556954e38ae4bc6671647d13e47efe62c917a5de1f5a82e4eb66352b01b3754608d17e8a323485ebb4834518abe4ad91a4cc4fe6e88b843e7ef1214085f6babef7983edc23855d55d2dbc5ef381dacaacf8334b6fade578c26b933b946f0f706997c5e1a42ef69123f49f1cad3d1d66399525520ea338e6a03c67f4aacb2dc879446a3d44fc9b59113923f139d9b2be5e8d6717a6c72de54c85bba7b5066d7a183c9f500fc6b3d32a811f70791cdb6e5cef3584e9f792a5da33220b30f58fa9b9714d4894c14d6ec06c4b0c21cf8d95bd33ef537c2c1dd158a32533859903953e4ae1690afa5049e00e528a6af4d65da371c4c6d2794d4a3be636b9c16b073ab273c256e6d137d123902280b27378fdb02840d8039845a09dcc8f71260763a9400c4b2a73149a63346e58a4c6691770979e2a7a5e5d44893017283f517e52515a4b396fd0932cde86d34100b7e8a6c235c17c5029733aa162e777e8e6b589068b103a03230a964ea7e906b99b8ea596c527853805738a1885002c4ce4353ec588eadf77056aec91d097b7bae97ccb4240cf2d9480fba451da2334e34b9a5f10ab6e17ebc493c67b5a36069229fc94c68373c018945d1a68ba3167bb4e422055db574c7644346b09e31467a1941b3dabd41b4de22431eab905043f97cd9675a0714b702fc90d6fce5dbab755c3a4b5cd04b41c66924e49f3b9dd6b716e5e20939979a3064f90648fa68f19275bced0573691638980811d37de2bd007a1a8b0ec96c75dee5a034992d7c819822b0c6d452f9f2f880ce564700d89be5d1a2a04863869e183e5815f07a46021db118db65beeec3bdb47bcb87ee0ba2e96e692717dc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008615180b7de9a84f651da10d334009b3d65582f3912d329fbad4ae39a9eec78943338c29db4f49ef41e3c50dabbb530e99113440383f20d5a3a8ae279a6201a0c84b003f6717c709c21ae893b6e412d87f8e0cee5a89e60a14ce975a4d42e4f43f4710fc9fa29e9b2afa93441ef5570123aa88aff009e2507a3e60a79cda25652e3ac3ac0c10a816bc04739b6fc758ff9ac467879bb67f270e4eab43f10a633e5932b8d6dcf23814de8643407b17b5e2a91b340f7bf6882db694de4dee4c480ce037b9f9a220acdce84b03746f307a6026531d712c0630e7de3add3a8516ba602d2463e3478008b3252b658fea54de41265b5c81e4e913ea0e2a63309497abf961ec40ac374adc0ff3c6fae9bfac5cc2df475885b0bc636702828489183cde1a2934f2d63828ad1f2b8cfaffa53151b0ffae6224df54c2ac47cc8844b76222c2a3b6e132071150049b6e46aa75dea28c13477980315fb64ce500bf0c6f633ae621d65b331ba96cfac162dd7897b8505257e228cb621bba9176a7afb3a2cc20d7804ddb3aae4b87ffafd3c8dc541d05624db02bd62491067ec1cdf73147014febcfa5b561756d5e7a13b88d1e7b2c0375e1d0de71ed20ca9cc4e6dacdc579f1ab024aae2a0bec9004e5dd81c046f00a2a4cb767c4eb240d205278cb863d1a61def16635c6a84c2406288410fa4b73b21077d8f7a4075a1ddca3d0d334725151e434bda80d3e73593338b07958d27337e32cde0010dfe5e58b99eb27a97dbd1c5e6f9a552a02726aad5a4aa63edc336d83e5870dbd514193367af2274804628b4eedfda3b2a155694e89f5a6798c5d6e036159c1f00d8dfb03d41940e775974b11c3fe4456e07b127ccb44e6fd6b2918f57a6523d7f77f32478d9f1bb539846793d4284e2907830e5ea76054802a266c85b122a389eaf4700629036716e2869c0fc9440856d562711e903a1853bc68582a95344b612e5cbc7c5b2aee23cce4161a75829b2048742fbd65abfe2397cc7d66023de34df4f2df8540cce9781ed6482d29ca4e906716c8cc9596b158eb51bab8c2e00253d6589a99b3d20fb494834b42bbffb80e7b0441e356b541f83877736985f6330ea459c007ce8bf18d84e78e36482d581dc7df97528ce15f68e604b4de62422b3aa76f3e7e5b33a49cba9d89fcf50deb65ee45173795393a50fd4c60cf6becba7e733513537d13f89fcf1c4d6437de0eae608fb11d68b9adc0c3a19a3565f6d62ba81a326ec334b239b212b87320c03a75c58dc8f828c4195ed9d7acddce493123e235d098e9dc60f5d3a625e1ff66f245e9977f9630a40d26e3afb6676f5122a88ce5507bd825757d9ccd53fe574fd0e6e728da355403ad664ffdeaaf636256fadc3283d6f15b297f79216833cf2c745c4c5e17d03260a69178f2216168bf8f00c9889e1e35540254f150c587a884cdfc9e5f7d379be474356c06943e416eb0697a1ae989ab4872d0bdf436d9ffaafec1631c9939fcecb84db2846f12ca395f506687b4a5638085bc6ef58fe8e2abe9f8d51f272ee855e2db84a89d348dd66950b8f43939db897c519fa302594fd1fbd6b6e94ca8ff63a7949432dc2d35c60803a570b1dac95ee0a60c62fd18b3319601ad29a156400d392dc9a14ff50af6752c1f6edc2acb7ecca71097b6e82227de429f1a29c5e38abea1c74de06e6788cb1790ae9f0e8ab35afe60b001f45971d42949263aa62519b0d630281a4c5788d5591b1ef5a003c58987e8665701e5b1c6063f93533094e96820f918c354903775ceb6675c4ce9cf940c4beb8845b4f5e1f642bf505821e5a23122e2d1adb82a63ad18cd1e4775a96ca9ef9493d75ff784a2d4a99f54dc3f87828bdff4b3a3d98fa5a29b62a85caaffbace4592a81bfaa5b8bae6606ad25a92a43140690a6003aa2d617fc707a53ec9d868e33596e098773942d798263f58fe5a1b23046cfa136ea35203b90bea2c5f0aaeb5ea8c24b8b8cba14cdee28f45d0278f193228484bcc7e08a75d0064d605d674aca9019a0a9aaecd6ac672cb8410fee4192e6dca7855fbb1c584cf288bacb40707d7e6f8ba2956f6d099f52bc7b0ad72b5a3ffc03c7b47086330244ea5d393c6b9f256fd82d5cb9436a469acc3f8fc237146895be148749f82d39b7ba4ce47715bb393a96ab471665529ab9e9958b12396c1ba7529dbf289184ff0f635c2ba9df301036c869d52d993463222b70ba778e81c8dc668de41c0356eef5c39f1bd42398bff30f959e115c6b386e73f0fe28a2665bd463c781da1c46d6d4ea284b152c8c12426dc9cc467809bfda6fbfbc0bb4793babbf6ad564d57ae9f5e2b7f651d6ed980f8b1174a126cc58b23c32ba73f5031b3fcabfe7bc360aae412d799cc14d8b252d9f9ec9005b7fca04a88cc8ae9f7aefca94137003d5764faa3c7c45670585c84f74c4ebd1f5ad1f97ea093595592fb90e3cab01f98f06e114f13de67cdc36f3ffb01c3d51ea643c25a3f6aa2c57690e42b98583d925ac7b06a349782a1d33c06bd05a82a7aa3dd679326d948d74a1861926b45db78d36070d3087aa9c5f4f42ca57ee9ce7035bd88a85ce1107c8e07e5ba3a62ecf012bc75fbf97c4c72331b55ab9a6effd78869f1cd3f330526f262f7dfcfa2b084b61e90772d5fce8f038c0f72554467192cc8a27f1f53c8714da1864815974b00991f466648478c5f9bf036dc4083d72e8d144ab10fd32408da7677729347febc79e48e7b87388d9b59aefc84b5b3b589fd91863811a6436ed76b43e657f7ee03eb796285a4d93be9aaad1e1a1e81687e42ec83f3dd059b78bb7f8ec70e6c831db5e90c6b3aa511f36507dbc8e7a77df0f5b9ef03bfefe9471de7c7fbe67b9922260d3703d95a5bfcbcb62d830e20c23c6cfddc210e47cb575957d8c3514a2ed4561c738928f210057896eaeb1499d4ddc70f44e30661e780aaf5c0a20c8553f40d7d3ff6d120511c1073510d04f2de544121ab851e98f666906367c21302eefb1aaa723f6a531c454eea0be7d5000000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 64","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029339aa1244c317140a7a3a357d70c0767bfa6bf97cb1d540814beed3798e9280bd4c2a44ae8b4b32b22e28c4793939136e746846f5fc235d3801edcc28ed3202acfa91fdcab927c1aeaeeeb72edc2b4af68f367473e6c0e6310e3645516ad1c62866936f272270d8d7bd347d35e3f12ca4c632e32e61581214729b26df29fa49db5c6dde68763288538d0e33eddd20bfee3d0f4c259dd658737368a199b7a51f0b3387819eec986e5699398fca76d05362b8552c269f47a20424399b27a9104db2efbb379c9f2fab860f6cfc29a8e72cd3e3b8283cdc92ee8e4d89013c35979a45a39e76793bc71d2e86374997ab2c8e0c80dc0bb122c9a968d37ffeba50e73a79891c10f4bf6ef2540f3c995fcce3239c485ba4f16348c42da97d3705a920d03e65eb16c468279379526c572c5555611642f8dad296768bc660b8dc4b56319122c90ba5848743a587a3a5449e3553463f7072f6a41d3b59e8166d628147b428735c0ee656b6a83c18bc48f22a0a8b257b4552868cac986674443b79472c8c53faf8d46d3c8e1a7a9c5ac1d1af46206b6bb495223cc24569c679558ab69f4696614d532753ff7168387a5ff23ff5492e558d5327632d8e6391a7661b74f77513252aae2d404478f943d66a85e362b57d93dd94d9cee019f47854f03462d322a31778e45270ab18a642c136e69a863792ad62db66a36854d85e1fa7b9c1f9229806a588e74ad0531de3ed35ffc4466bcbc32bf15d366b8fa92d3618544f2773fda065b66f903c3805f610769cb622382c7204a6458f3b5a466d88ba22a57af492c868674ecd1675089fbb1a6b61495912c53f1b7797ec48e10a3cbe75f1483364efd7e79a56281f53045733912ec8d24923ac2644f65111e12ae9ebf05766f7059bc5b23559db9bfb9c9e7e9b6332cc23d3d8dbb5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381090b88f6231b993c7368ba543ada749a90b4a85dd4a24a5668999d289385f612c873932b42d5e574e6ec20755ce24690d91f6f3ec3357554170e60938a01e70c333c812b58487b59010143df1fc0bb7d2ca6b252f755a831f970976b06c1ffa0e1dea176641544b9d32f2e5c7063d0249e86c1eca77108d41a0ca9851c609d05286c218d04c5adb010f186627bbf264745cd8f4e22aa2e927100a57829e440bc2fb886cec3f411171714ec62e6c69ad0079cf1547aede44e6086cb876fd9897068d2221f601d6925a9d91a1bafe8d990ba638f96094d2455947b1e81a9a72f6205a78d13fab240197665e2722ba1bd2ac029e74f8f693b50c29812a99ea2aab2b956975288998f14e1e9863eb89cf7730f111d28a724a1ca81203215fae2d6053d259fa74ed61d79451f53f81a57314291f2de6ed2b7309c4429d0b46281006b7ca115a30a6c71238a5faf31f18097c3e01200e27be7a5e23316f0b13e269c3ac5b8a733a36aadb5e6e67e184023c602c7391f6cba8a56d52a10b7ac28aefbe2df06486105a578180999dea555eb6ca39db2d6d62402893c029cc717aa663250c6eb6d27e86b78dda22f5f6a346dfc67154e5da0c1e1fb3c6238694ccc0131c1584b554f02f0888d54a1167b0c5322ace27b66d50f82b47ed2b94727a9a26413491b97bf0a4d5884329d31819004c75048f44760502093c9d533c29e15a08a69552803e1a48b9f8956d8bb55ae818eec6d94ed660b16f83f21e09b5e6f55a3e9999536a0947547a26bd4720e7d751e20ca57b12738a44fbc3bbe1d342f5387b45159c6f5af6a52a12cf71487bd28597edb06c19c9d395efbce8582411434060a424a6615c5ea6b00e650dd3b7026dfd2811a5d17204eb30b202046638918516846755217c19a122f78c35a1ca26aea45eed8ef1b400aa94a9ee2311c678bbde21198f84cca12c629498400a2ed93ad676027936e1afc04a2b5497a2a94941c80294362b389a518d7da23de665e23f475409b63d02de6e1ae3faaaea1b37e4fba9b6a042324431b9485750bac6e5573da9db12aae8c5df9ee96f82fcb71e4697ad9d1d77f0626596b49e02890c12b444c387fc63cb156ce075f8052d9bfeb315f282360022c5107f644547a88944c32f294b0142e1491ac8af7e3c9707c26d792efab3f211a698052d8b35d9ff31c6b310e86e55491620607b10b48a654768774d2b7d380805de67e474a69c1aafebda6ad8d12327acdfab98c750278d49b7c903600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000088299b5b6fecdb52897a1958c5c3d1fc2f20b7d045f551856ea3cb441bad9089c64cb9489db6b63e0655afc4c2fa73c7417ff1b80b9c7a1d659687d2c415b3a909ca30e96849d4bcec6a9a6a4311204936ba972086b2394d86e840770d01550caa6ad85adc0ec851d2b3808e4a0e9830b99a70f6204ed4dbcb6759f6228126039607ad7ed8eafeea28d1c3e25a46bc18af7e01f55fad8244f15de36f890416aa09548554338972c5f88fd9357792819e51a63d0b872b0a4d21ea3597405b52793d50c6cd70b52841d53484bcd3ead004cef0a6bc16ce74cb8ad0848000d8c5158dc16625112d1d85d17a3c1c8bbdaea42c3a43e9930724655592116c4c6d0b8b223337ee4e754541a09d898f7fed71c3785b7f8721653986c525bc00f15590616437d11f9722824dfde7e9615f1fb8488e5327e4d8baf5f79d1ff5e808d154951ad87638910607b03faac3a61fe9916ba65ffd16986deb4169bd24a72b1c8168fe569f3c81f93f3ebdd21d4e806f79fb28550912e9afffb52e97860c4dc0d042c56e1bb71c28b68e416874ec7043306a29bd1f4b9a3e612a6778315e2c2b850d6eab9ff1905030fada250caf308735393c191134f3c493d00b5695775d82adb9f2abdad17fc41fbd7a1defe337c2f8adf69154cc0862fbd43035295b1a9c80b88fa8cf75b36ca08868f881966b41fb3e239eb1db9cb51606a0a9ebcd552b2f4e819e2c30abdeccdde88d2d2f82f3585b5143943c929591d20cef559cd2baf2dc7fe03c9e4e084e8890fce64a4aa9f13d5eb945ad7e3cc53e01fcdc192b97adc1f98d9e773a0177e8d97405808ebf48bf17b689bfc15f4c515e38a855a9266230c9085adc9a6ddaed93d80c3f38bc516695d202b4e89da5b4ebc43788c848f8c4a72f79f37f857edc105f13e4ececfd09302711bc1993f5308b8f32ab96fb8ec3f5ea0531dafd0ab3451f81f47e62c593c8d3e3beee79db06909576bf876145856f5f716caa436c98eab28c5b85bc2e4d7e1653ecbb8bb6b5bd6981dc72d7f63ba06cac8197eccdc72c1481db44724a3c21f7fc60661f11fdde8122da5d0b1d72a29952618b373423a892875e6ad24d0916109ed8e9a9a8d9a68acec4bb5eeb0d00eaea72d8d5a76c2a42f18cbdb3d336b71c70ac73d39d7eb04533453779a1f210bb4fc056b4728afdfcf46675c6ac76f750626d642e3ab117e5d6740154759a46c27d51306587650e1039054b876849882e7dfd807bd03e69021e337dd69d9b097722c6d2aeb517d773d2f7d84d69dabe1a1d6422ea1766c0fe7b8dd4d7283f2985d96d91a132b8ba03ad85f7d56095773222d0afdc5a192d29f3bb0c2539a1c99db4e711b6ace3febd58e45e99c9f5a04cecbb309d50397f28c48bb9cc9f9cf75a52253b634ec47216a1fd6358af26501821864569879be1736b0ad242ab5b8ed16a7ea0989ed4cae3567afe1f8209a028db46db0270b3bc06668a9bf5e1bc1061babba00ec4ec37280379139d19bc6072cc6b7d260a816cb82f9bc90897be3025475af12191690f9f400a914789a860155efd2d606a15895378c827f2a4ff700303962fd96db2dcd2d213eebb2460f0b753bc6902da81d44c983dd027f1171d40a2039997241e09ae5b6165b4d55a8e4c79671a8b8bdefef2c21f81c541a5719deb939f866b61be250af371cea7b7525094c904698d412737f7781bd779365f122ee627d9cd4a68da9d5be1b0431998aacf824cdd864c7365c01cd5a5f480b6ac1e5fead8ffe40d87c1f9fce81867157242285c5e76cf9667919c29a67ca0c0a61d7819d9ee6b792250a358f5691ccd80578f15288f3d5d6d7dd6dfa351fcf8df0223f7d1da1b76711fbe0e7fabd30377660ace7b23acf03abc1d973248cdd0897773fb74e20481ebd3e52657c9296b980905ad29271ec128513284f1b78f38634bf84cb80791a0c5649177791cdab87769d57b626f78a03435c758a207f52bd2a1f31e34b6a122b8701cd9fe478c57cf3535b6d51eb46caf794bd69363d5a56adde6945e9788f1e1dfd045bfbd0a68834b13d6b9ec4ea9c860eea0e9ac19c2de14ffbd6b57e5992b08943ea0283813f3f15e4f928b8d0f13de6863990f5c77f130c97d8be12571edcec7deec4b6ef4835f136da45da70a11f9192478fd8b4846c507410fd11668365b05252e68cb2c972acf50156e369b83bb85e62e4bd4d84c2e9ff41a5844d5d88aaae7ded852daa0ae5c14a5dce64c7e236e9b7b60f5b5ad4d953a2d842a52929491be3555ab8df534cad56dbbb86b28a8a86b7bd9ad1c58c87b8a089324e00fde32f8186b2b74523a22904c18ade02c3e965f94624f8df57e750ea6335e3eba705294b76cd6ada33d90fec1f48de7ba9dc7d8d60a53d2563964188874810c45736c57efbc3a3ceee7238aee5281882a554f2143bdf89ed4bd819c08239c187c12a8b6e763434b92c26fdd658b350f51775c60cbab7a2cb120db8ce8ae9aaf6af559f8cade84c4820209cbd27cc09230b22f013a0e4cf8041e4a789a5d20be9914a624ab957318848addb39c9748c8922c54327048a2e46523bfb22487538363459035ba49858f85a469957df1f4831bb7ffa0564c53233b99b596f5356089949306dedd6b904433d25c4854a80590b964df6b0703b4f9628d6b9a4d3f0a4096e9a0b46d6b32f66d563baf688add18de001da62e33c503a4387ce0920ba5d1e8b69c38e3745b19f8d8b6ca5e1ac6de90edb25fc32df04f0849d769fbed3f8169ea1d2252619a2304e055370b4443cd23e56d4934f9f3fc92f1c1eec626657e6a89c1394e56061af8ece3e2a17fbaaa4d579a99a7998632a6ae2683ddffffd27a27c8815511855f09adff7bc627a7a5c95fe57fa3ef81f494fa7ea6e6ca2d14775a25beaf1b5a3e35ecd4a306545d597e4e44301c3d1648f0a7d841f2f76fe59c6eafa3f5b58907fc4e642ecd28d16a71ee3d295f1de12de1485b9cebeb2cc6c9ac051d3d42b6a1a068533a7680a98d015b09c5b819ffc61688d441c1b7fd71180c4423e64ee940917c7dfaa19f3f51cb5b38d1b2b7c81d10e7c000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 65","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39041591f322083c778ddbce9e920ebdc68bd3d6305cf16f3e9e06c63d28989a4c72e2272253d8da9617e5ddb56a944df5c7272856b70953871163379de04275d91c15c2fd345eebbf295a31d5652adca4e3231cbae2ec75889659325e66ded6f7ed36ab2c34945144821eccee70d27afbb208e1bf47da02dd8aeb6c556e5ec0d6f57437fd419d4bceef7a815577d12844ea62a752961ac4c72a6f8476933028189bcecf4a89aa6e5d20952a9c9f4b08efa9a8b9a6332efd5327a1e82028ad751890aa9f1437ab0660a7b8869faf40c25749e737daaccac99354ace5d67c8a0e4e05624c8cb7b1e6224bfb8ce3e1917394dee4cc79e7609456960ebe6912c5bd888236d08f479eab9956750f4e91f994e0e91d8a5127e9fd5a0481f2887367f9b8b2cd95a92dabfd7a3a40f230b14bec4524c6d2a2d3a0a776a3bd536e5574ab17248c7d35488c2bf5ae832dff084113411af9219d20b21906cb2b9d707b50070d4f8bd8e37d451fae88e80baccf68d833fa0d82fb474c6b07d642c8d4ba98045cecbf51e680be36ea35d673d7606829793b3ed2c91c6e928c35cb028b889fe2e08e0f7f2deba1642d4c4468cea38afbf5476043954e6e507382fc2e7c149ca3f315b57894e7202a6c90c6fa6e5961a5ee7a542c2a7f34ed59bb8a178e769c41480508f46962c3ad804e9f86bf4ae8c7b244323847787469b28e9f6127e9154ca328f98a75b93bcd18184b0bfd74f93236115dcd7fa25e3437f3a9e9ab6ea4368fa7dab6161d026b85836a8cda79f7fb61508ce1c9437048e6be9bc788f7a0ea72c9b5e4344d6b3d972308ce446715588b1dc44fa17875923614dc9599e1e17dabdbef4be4bce85ebe5d33cc444656e5ed5ba07bb6c89c47f5f5b9c6d3dcbd327ab7cab1845161cddbc38d55a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810931cd6e79526ff01b72efa4b1c1aa7bce3c83215925112143ca6722505ec8d4b90eacd29fae5e21e8c52591184d38179ba553d02cda4807d4383253cb3760e5467158b2e5afc3168e5f94ee55551df1865b5d6d2b364218c38dea5001b8b0836c9dfe8b097729f3e078417ca1a4c751b69f24da95ee153d97817846bf27730cfa9555a49fcd36e02845a109607d54550a2ce29795c154a15dca3c101a32b7c0422b50e5907560a3191905e661e2c6eb5232d3f234c2789fb2d6621328f04a00cb2b6ad8ee31f23ed7df948f5e9905e1ad1bfa53e919088313039edeb6c26753a2810e944462632cbc6d0401dc81311ae1b9441768820739ec3a26a26e89f8a5759e08f8b5b5f8f6bba95ea542fa3942601b83ddec860b8787734adb21bc02968a6e385822c5ef7bde67f27ddc7a1599a15740e2c6056610a0aa800b349e1e52a9d8e197c41c2405227e25319fdb619005bca59be7f494091279ce80d22f23480ad584fcc11818a0570a15cb487f086971f848799a19a929ce156e928624bb8650c53e003f078591744652718a09957317a6dfa90899cf3eb980f049a34da889d669338728b4ac22e4b6c82141bc2584cd8ebf0f4a08165edc0d40d84f934166706b6d6574845a4f56d0834224e5b94a24a4f1cc51054ef503884254fd4eb0b21314661f71e0c8a0e89edd81663f274551066f5a1e652f2795848207d08d28eb5d86c6f1fd4a68a1fdcd2a179dfab5515fe2ea2fdc198e7a20bd2f990f4e80d22b6d483cc2dba01bd85b53e90931469a92381e4a364a0755726c81408206b891da9e65ba5c9d2e28dc0928db12380a68c2f221a52bf41e58781730817c1758e8d8388a56484b0b41907b566e16cbca72068a5db15cc3302925e374b450de5255e7d503e781a37e783110cb59285288e635e4e4022e506452920ea7b11d83c0a7f7b79a472a9a42c0a0911f1779d15335beab8193cdfaa72a66da3ac6c218a00fc70485f481469aa22cd389042532864f600668343faa1011608c4df8321b43340f0647a5708aca55a12c67c19d9c509c44186d8d946f86717a1b692639f110763611b657d93d85218ba86c90b07b280fa3b9eee5222c15fc46e6e71a3243a7200d5a97e24944202d3ce7119eab7335368841a3b493f9e3fa8bc0be10a18834bed2a9458c0ffbb8490125f59c255387d475e646360755f47d4cc1d5c041e39216ebc1cd534b656510f4e62c5e666441f8e285983402f6ca9c57fb311275205f063b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008a3e3b57b208352a820f622a694b7c3f6f297239ef0a069615dc664c02f1822bba48e11e37bd9749c98facefffb0fe1792a386be10ca7b98cc874c68c36f5096d3718dc93e0734d6d6f913e3b958dc1fd1424818c9437b0fd59728ed46a79fb52c737a1d1d26f04ebac279a7ff6a971e2b69576b712d9224ea18fb9bf4e613a8935f3b36a073b01f37bdc0b77981c8f2804e93c395419352b85c8a32dd77d41da9bf3ecb914173e80dd1fc06e8ff5bf0e4f7424849a15eb7faf7de77456ebb64d10dc10fec6254070c7df387397137372ea3a53dfda7da13414af2df16c1e38c5c70a5f5f44f725d622049256bb15dc04a8d846a1a0dae7e765a7f00c498f1d0b2893b8405be4a43fb7e97881069a49134a2a847184b82eb5a690d87baf2f579619ee19a3d7a7c7eea72d6e3fccf0a8092bb8d3c6b551f27e63e762a30b4a4df2dbc4d119139ae1b135d06ff827846901577700935e0011b65461c2ef9a7b71eea33c8ca4519c7bcfb557c5e1d42d9243f2dc34057f5e0ccb9a457fc34dcb10d9b47f6ec3b9550d3ae4fd593dfa3e28c6cca1ff1ebc9d98da8db869f8c80bdbf8ad4684acb6a779ca9d0a106f26da17043773862681c5dd2deb1bca2ca48d4fbb4bb7c1f765dca3a1d991d890b9a8751ceaff543997fae5b128ab2ef22b3be94499dfd9d8e78fb4c82ca8d296b0415e84ca8b5f2024455b5decc8b4ccdc7bc4ee06b4f0c66e6748fbd07e3a3bc5b4b6889c40dc4a97ae3eb43c3914def976efe3bfd84a093bd69102d7b37c89b458a55b98a1974a13a7685d26e9d816c79585bcfc1042c2af88534a9fe8b0a6c8c44355a6d606f902db40d5490264bf0f352c27355633cb095268d5b8bec985a62d84b2323fe814053f05dedc22029d2998bd0bcb255c162c4bc03f60e3580ac3ae86c37850110e9a1bcbd75f64a0dd60b941e2f57da9d72498b3ea8324eea53da3895585ed2942b9140f260895dc6a1131a4c3ad2b64028bb8c0fd67e1be4c07f808b47daef306fd9578025f9c639660075837b2c95473f7f860d6ea2c53f4ba677a2345cf212c7757bb94f1a4f76d4e96625f6fe051b8246d1b7611bf6fe325ffff8514d2f9a3453f0e77ae8b958ab5b567e541f156c6f4d315b4c3c547d59bbd0d7403e2e6a49b9e7d3fdba338ada41875ceb03830a846a1fb266c0f1228aad2b76a2e3404278dbe482907206fa66487ad2c999867f870c8cb7a70b83437e14b9e893bf6b391dad75e84588e882246d161799adea63adf1ad706c0a3b76bae595d84b21ae9da30bbc0856987f2c2c543d977747b8cbd5a613b92804ecc5284ed23650e9dafb4b76d63f069710897334f18ea6b0cbf99cd590a78e3b050e1bb24c86d6323a17106f0cae3f30b01e4eb3db1b5f3a4771a880c8ac06bcd5a82d4103d0452fd7b54834c1cf8595dd77f82d4ad9ebc1cfd0c9a8cc787e10aa4d1688474208b69ff7ad4da6986e5f62a34ac3093e0fb1efe8ae3a96f6aae09b0e8f6e7a2b65c7387999cecca43cc33f026dc19bbfd867c48127cff579d1d71aff0c4a0e20f9fdfd599a6169df1b85f6051e02290df6f5ede4f29bb6f0c8f806d6850c6534ecddccd75bb8e4a097c70445585740f822e5cebb0e19eac82bb78ebde2ca60a810ac6c54119fd6427da8a0155ef48653515a919b299a306fd3c62b505a6911db2b56ca2f296e487ba02c546eca2783ade8e46a8c78eb1f3d7c04bb24548f92383e475ce6e572d8de1bfa9b3e35d9bd6c79547b592c95693750010a3d22cbb31aa5a4abe94897831b1ed9287631f006a735c36bc84a8c87497eea4873801a733f35b328c7d2ccbe4a41c193d22f972571ba7630b33080793498cc85e6eea1c412914459da175a6db8658d0bd7a823fab286edc20c785c40bfd539924a24af4e3d37bd781353677c76d4672098f5bdd17017012571d9afda05a40ab56998e40f5e359c43dfe32ca10a45bf08f67d128c24b1acc03cbac46ba6ca5a532c105e91e0c77ed59fb534aeecd68735a4978177bb5a656b9f83b202bb604d61a24574c16656e512c0a4cc6f597b3268573e10539d1ba775ed83bb680bb9115011c6ad43fbb66fb37c467249060a1586df27b2cefa65265ccb9051e468000ccae24f08ba941a8180a64bb624f146c8ec562363b32c369f62997c4b1375dd7de64725a598529244273caf8398913c6fc01522683cf1f9f965c491abe7a554f0019514ed98d75eb8bb8565f77c195f629f98163494b4aa2674f92a41dcb67edd1d818a5b98993d0b1198bb6bedabbb486bc6fde039433e842bac568a5b4eacc028cc2544b57d8883848dddee2e967ea85a6102bd0abdda41c3d78447bee1d4949449abaa9b3377e8cedcf04a500fd1a6916e26983e64b5e96fef87b32a060444d374409262453cb1376c349a8b5d1767b1e2991a1a6044e0f58831bd11f12159675d215d7eaa74807c995fe22017e30482db8a4b09ca7800822c75c92ff649fc0728f5a1d44efe7d0ff147274152d5f2f60342c8f5f951d8c95f83c1d54613a182d9dca68f54fd55047f1f90cfecc04d733dfa82cff2618f29a4db4f7e1e59dead58ca65d07cc90c25f804a895d6a82f9375451cc55506d276fbf783f7d4d53b9bfb83dbe4a8771afe21ac543983d68034badc980f9434527f9edaa2e228646fdf75b44899e749cf4c9e5b345222385a4424382603ad6efc24c56e769028f4394f2f6220a9b390d395e412498e57a08bad927b8bd5d76e18e8feb457fcbd3248d218236b07783e57fbfa03c292a9f5719e6aef2eea3fab2caeed5442e89bffb236cb13db2cf9c35a38c338c377c475daf45f8ea822f9aaac13425fbd43d3dd9229367f0b3687d7e82ac5ec2fc7cdb69c99a4eb1b8e45465c6a53f16ac0c4e0c970b8c732af515c09eaf25596f64a04ae4621037b8841fd2b1bbcb310ea23e122b0b9ab96d8f7702952d0e96e4cf79c2a30df0091acda91479ee2979b0054997c48f6a0e909bc52a943459af25553969eb31ce7685369a7fb014561b4697b8bce220983136e5eb2303cca4eadd4c6cc74ea2fe69d448ae6ed953a80363dded5591b27a1ea956df081ce99aa59dfc789d9d8fae952b0737099d467d0000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 66","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039b7d84b8c06665933c5ccc14eae33f8f3504f1ad5e313bd60f374f24df54016872db24b61dba7f9042923942220dcf60f83a317c6693fd50364f7663d936565c7cba158975f5b098d8d4ce45710e40fc48bb06c76eb43c743070387bcc9c2c5f7e7b54077b56cc9d14f1e863a6d183c9b5eeb7f43c7220e1d5d29b05db79ac40b81bda955c995bfed529012bf9fa28db6a922f7487d0224a2d078acdbaf17d41a99f20112b0419a7515128ea665996a66f750f55a67be3238b60a474e659f47ddc0fec25a39f3bf03b9cad9885c2df49df156b7a69e66ae14557e2d4d29b485d6306eca8b058d9761174b3d2190825a603ddf3be1bc9bbb898e13f0dd27b7166cda7bdaa92f5266e8461b22f9e08d71ca0bbcc55bfcf8b27a9bd92b8df3409ddb36a8a57e74849b559aa6c8c1e7683cbb0a975da8b9f437473d2a28256f39d933f6b9b37b1244e5df476310792e47270841ebee1a3164cf30691ea8bb6e91a5b71b7a9acb909c5198e9cff096df643da556d82998fb20b5acaba3e88e1937924464fe2b8ea18567de6ccb288de348532fac16280addd06788a68f633b4932079e751df23433a99b3af441a4c7166d4249323a2b8f7fe74169fa4712ec8e0e94c93674f243aee9604d510bd5664488d6a7ad0ead49b2feb50aea25eb6b90aa548c93a2c8a7ba578e215df322ca6209e4d28dd2762c35c4cff7f3f15eac76e94d428cd4af72831e2bea896b410f842f20b1ecbb1a474d338c64c608cc216a6bc989c1f7eda984fb1895cc61531522d71d8bf9d0cde24ee3551169a1215089e7a7533e4163b4474a7aa749ee99636ec74fd004430aaf4630c271be3abdc49290d34746bbff74821f4a0dc695e6cd98d22d3659bb17f187372843b148643af99b55054374b638c69d7158bbbc7a49afbc40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381099060dee2ce47aa52323d87f2264f4f9ee780d3cd457e9d5df090e6c79bde3e8669135417ac15a931aade417ca058176dd0a1b4ddf5ea08633c3560f4d707cf1d9cb0a781988443a040635f1e9628393bb66ca2fab1f6680a6016244918dde03167f536387ff2849237acdc4d884146f73d7cc03896e4b41aaaa6f7ad029646f67c6180814a78ac95f3506e7100f6dd9735e6f715302a71d5401f35e0cf634f473da621cb9999e2ba6386bb80ff4c1313eec6305819c48f2e50f8040eef8d2dcf033d5f6a4d2e87a2816639bed223f26b818c00d1fcea1acfa48f403fd35ce19077520e673a6ceb957ea09615d18a3e89d1b13a845c07edbdc2bd45dfb05da73654ce0e65ee1609b255119280723af1616e8b5d91957f209bafa1407303c775729610712ba12c0aa1f088be6913b81464bba9c257732c9340049d36088d29da3ac37565250ada2c260b89117e569602ae83da7330764e7a45bcdbf423600683fec5dba5cb05a711a6c07386729f7d47182c242549f07035249062194c1e9beb10470f255f250f568461c166c49902da97986d0130c0cc00e9aa3b8408cf79daad1257eb9c049e71243b615659727e72584219962a5024436a8793aa37194599d1167acce2e50388898ccd91d18122278d4cd834958d6a1d757bbb5cb9a9edb852d989dca994b2694c20591d9dd19bc3267a393457825827285208151056a0d7bc76ca611e1306753931bb2215d67755ab81e512191372858590a6b244491fe4968f9e0efd4e06b89f626831a7d85e536e61151a7367423ba3e0c979c3003d277e3ae8fc94e3b7e4001ad989ecbc6059291c837aacd8d042ed42012626b387f08c0c0cf189c2ce58805c32c34a7e95887fd66867e4057d41e972d07f840d420a4da593848e9dde45791024cf05365047118291496db9a75f8ef0b6e900e387ce97be7e2a96f09c0e4871d02b189734b311bd6bbb0666168525d03a6d403d0e051a9559660889e211db4e3c36aa12068dcd9f7fad519520de367aa8e96084d9fc5fe8b1e1e0905251a413f2bdd1760d364d3a7b975b37f8ac87b6ab88a94137d891043ab2a18ed24f17b36cecf3573ca21f8dd674d625057f6311ade33bd5fbaf6cbf1a08dbdc96f8f64b92a7bf677c163143a9091b5678e11281c85f79fb083a970ca1dd1e34a1920766bc20c325519c8f0432750f4ba4b09a7262925faf79fa595a08dc0d69e13000d329a234b9e739d659c294990b37dc1e0e008ee468a787390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008c489d960d04a3df6984276a3d17d59af9e72b25418c8797170fa701a672c5835ceaa22dc35470d038c6acc5082d2ae329f36697c91cbb1f9e42da59a654462bf19e04352192778cb050db6f4a656f6ab0bd9641ca8ce6c1ef8b020a3d9fd9dff772f38926458bda6e6072456e506ae464785399ad7b498afd4c211f09d0c722fbd9e20890cddc8c6eb9ee75390e6d76d0672fa64d8b97c65cca46dd1f542b6d6014f035d2817c4b9430ac8dc318cf8642ab34f4c8d71fc0e3b1fc961e94b6a84622876250fdc21987777360784d9a58f35e1c9b71f30561ed6854ee9b112e7b20ce064272213bd1a46d0d19e5efafaac7addf4d7b7a519d689398eaf1e67e64ace8e5e89756377e1fe458d04e3df7f6680f8b69815680276acdbee6c8e1aa909ec56994f3ef3b65fbefdbc29aeb0ea906274e838cac36a0607716fbc2b8da6150a4ef39e1cd9cca72915007723c5d2442f7133258234d18a257da2c13e53b47dc6abc2d607b98e351fcecee8ba8886821985bb3a7bd02429ecdc5a27eb04d01dadce88a324ae44f567593fbf730c284414056fa33ce90a6d6f146dbb1635bd26b4f883d4948da47216c70d2aa58ceb3979523c6a4f2f7ea455a97c7adb6c43685d63bd4c51d7ddcb81a06b9bac31a7b255b94052d686128d234bcb63ce713028451b18b981b83da1246281fc3bd2b06c741cf71979daefdfa0fd06fba3722ff7bcb2821fba964fbe9f6467fe583c06d3889a40360a7aa03358175ee75eb8fd1d3368c30b5691776c163764db924fba2362cc9572f642cdd2b11b40fa2683a529ec2100dededeaa70a1e639a71d6a96ad31f70a00fb63875d0fd5c21e56ae57b6e74eecd2ef34bb3e20be5a1f9f1f54955a18b4e4e4b9119973deb76a2a603fb6410a350667ece5c1c147dd00b07a88a7d0e86aa2d747a867ad90ba6660c7a0432e20849ef642a20cf5a20af7e34d139b39dd65c65b36750f17f0b9f1db06cc6e16f10eb289f567b647454a581604f381d66371238ab785585a4da2d00810ef6851a6009025fcadfb77ff7996ba6b091fe4130733466b29fed46554febc2ad291dd966bef4d79a9e04014d3003c95696e8bc39892ad32db6d6ad22d33e931bc87f78114bbbd97b334bcea676f9e9db23c0485ec06d8f37f070c143117b1bea49f06e1a2423d98c12883d32d29103f7699646e7091d393b21a260703e17380a1bd85452702c3af7df73ae7856a1c066013014de62c3c817dd74c44aa436a71490e7bdc6b8b74bf61711fdcc541ad7dc49cf4c3ec154879e048ff30df25065b5641367cbd3bba19606a9a27a64055d5d3b538fc88eda66ff9f26e619dcba696866de54a8dc8580b5b28144f952ffc6dc543e98cc9fd7f4538135c0f4deb4bf892266dcc48a4d1ddcf407be4fdf2a5afe4a0105a20ce2b3d9f48d608de2315240875f1fed696c49cd8d4a78ad26f51b3c804949c536ce35c3963dc1d238516b3f2d297f5c9939a946a0170e185c75087f37acf907f9e3f87a2b15cf81c7ecbf2165f0f3962d11e9c6a7845ecef432ce9e1fbe74c77ea1057d79cb595d47a8ddc1d911c6b97af76d91f3515081b95ced16275decdedced9ac790d73739e35973834503133510dbe39201f9b5c618231184b9dbafaa7ed6623e8bc492170812444db62d4f01925dc4f821c0896a746b4453e93ee51844b311b0a0a51601477bff651eb5ee331227a2e9e49f593eb2988e449e750e990a8a89906efab00e0955c81b6aeb160313007b481c40908130597626935389e47afcb0a20146f0c7b29b567e95d59ced7fa8023a2d69c89443a11e7150a03d09ee6b0f74358141d48e9bcaa3ee081c7d8f8c223f4d48efb3df8a4e287fc5b90b4fd251cb616687ed09ab1a06c42eb9d6a578d72e99d499882d216ddb3f35b0a33d9f2d3d4a700161a5c3b5a6729f197479e78009794aa1be3c25e0b9142613ad2ea508acaef5eee33dacf60cb7a16ab38d9f3cafd2150081b63a3a6ca0163a25fe81206a37a0874fd55fa3068b4c1b25e6325fa56646ee5f3431d33d0bc691c134ab306b0bd2d1087f4d898a529dae08b97683fe2eb8abc9095d67b79cff0e77404c1f7ff316c3cecbab77c710fbf961008047af22805d77eff79f815b21d142f517da2199f6627ad9fd85aa24e9b7f40c7796207a82901c7b5a3a42369a9bcebc24ece13a3ed064e4e748bee2890bb21b8e4845362be9aee46e25418f7ca38ed087e46e24f12012a1312bc623aaba6ed227cef116a3c2130b4b837ac77d86f8ca3553ba0cf5ad45e9b4e4e55059f1d4675291581d7cc9e5839212afcfa897e90cb601cb33a4d2241a5ed5925f6416be5a43d4767fa04f701076ad5ed5ece2d09b8daf11b00fedd2aa2e748cbcbe365031394ef823951ebc52b3e4c79d79234c16575910c29a35eb67c624f7504eeca3921f461d7f95eee39638c402481df7b59310c4554450789dfb28ed1e485c0018512eb05f14dc7a3db5c0606f9e28420d76b8f8534d2ae31aa01e90a20e248a7fb3b72ea859031c67f7b2b043d38f7183165a42ab28c6308608c530a9ca98f82c133bbc313fddd2109838e970dc9989ec14df781a518f6cb56dbedfc1e381250c64f95d0be5f37515437673425374d44811f4406ee2b5130334ba555839e61ae623d283c77247d2ef8b22ed138a526f7e41dfd41fc69a2839b77b51c6fd96d97d3ef8359e8725ba1afa80278fb3ba9c697f7e2bbcc5d3f0f2e61bfcf542d3160ede02cd6295fcc55865e7890342572499347df80ec073a91e00193baf804b884e9cf5c43269824d4caf7eef49fabd8bdc5496d190263c96dbcd287681c19b90c34635ffbdfeafe0601bbb7514fd84896a22895e9b21faeea372696e350f13959fc23533f3e8c34b17b595f3c935e37220aaf644f3a565114c34c7b85f1a3e465470166a62b13adb00a2bcd5a9a3ecd59fb772f09dd6a6e2ad12fd54ec62cface0022f2ffe3eb62db0f4d0f0f9d1fd6f3f11d76da868d2c1c4124915de19eacffcdb31f7ca018b6976260ca1bb2c4fcd6b9958f096313b608e208d875ea5a1fa89916d0367edc4f8890e93f1e660aff16ea79d1e583007e693bf06c172105b3dc24117dd921fb60d3ac0d2e5c89fef17087d885a0794e496e3cbea333cf72a507788efe00000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 67","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028c390fbb8189bba539d0f71d846cb47d234fbf86c5237298bb2728f4d99f9df7e650fdade79cbac773872ec934b123bba5f53aea4e21da4071b2d78b1e9518baebfe65ea95881aa7ad49d2f9df1cd23bbca6bd1d583819ae7cbfe68449f8a567a1649d21d22624d1449831cde3e771b10f56f33a99e638199e6e690324f39f6ee9d5fab43ffd0e31c06892d8a3cf5194cd9e9bb5eb7bf69b40cd27ba5b9bb39b3a04dd088b30e6132441dfbd4bca85d815d8ad0c99ba7fd7bad89bebd49ea6b86f3e7bd4eed883f8ae7f292b63e032df077ae0d9eb642a2759b7e6b31e9de221fcf0d59af76fcd1ed5ad35743628a06be37865f92e5fa50c31a88246d9cb8e2e33ef583fb5395c4384a1d1c8abd9bf3c2a9ba3b9a2e3d82bce921505efca3ad2851497dc4ac1ece5a3296a9dc4fab9f5885c1a5ae25db3f24f2b812ff36c1e53ceaff14cde797d9031398bae3d72a33d54395e61f355a2d8a6c13d1deb5b6231681e35c92426aabd0b542775bb75c893635fb58948ca18451c85459a24011a3c95d9e20f46e773d9182b7b8e995ff084ca2cf9c12316c513788b10b8e4aa3ea8d6aeed7cdd97ddf2bf8a22b5d6d6d65837cdf86735ee81f8b255bb142865791c9caf9b485a95a5640b63184d4c9ccd0925a921b1b9d269d24b73aa98eea4afecf8c363feec8393d5ae6ecfcb990454d34cc1eb3ee68d0ae4425d4d31328b53a9724e860f45c8d422669114c2613293891652a4830a6583d7e4fd65a5fb2917c7596bd639cfeb22f2e398d4f75478a752ceb4463f04a64c3124167a92b44f3cbdbbacf8d98caf066f69eac15674a0e8304876f60590b66cd75bde2dd5fd61fdbf7f7ae9995553c6ca818e4109858625a634fae6672a90cc54967d9ca092e413748cbc4df616a98aebd99142148000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381091a367c9936cc9ba4ae8f2bf71ca11255b9b1b3ec425dd2deb5e50e0e33e90b91ff6f9906e61bb42123659b2ab3d5a09e066915bd6a50de23997052f592d321adb26aa39fdf6d37b25437b441e82254b610b412cd8a303247fe8f816db98dd74defcd00298081a54a7ba135da6080581779e10ff809ed454bc488570326e8a356c2b215a43ab1c442444e5c3400f08499ff0b310f6df904ce0c41a8b8de46e4569127a03274bc6f141e5c988404509bb41e03f20253411982e290d3e3fcbdc8e435ee8c68216032401d2b666f2830e935aed601504eb2b59a13209a4a2602579eb2c553b5d18e8a4f5ae8d4ba19755868ab05f5835b25ea836b9a99bd3aee57d4782274092acda983a6be32dd7436f22429ab951e23b1c32c7f26782026ce8e8a346d17b82c3ab720c260f0dff6671254e5b21f7b6f696363e8085a38d1704b88190bb69cc010005b223a81ec041353bb25840c7810583d94244c07c9a97e8a8130d4e963a98c01dbcabb9f3b63f016db1b4a119cfc7681d3422a7c9252a70c53494312eee9b7df52504c8d7aeaa8496b5c5a7b25d35dbdd545c0b3d650396eb7c825e94976652d745ca26c7d8d64187023476d208e445550703b295479bc909116a0f5c719a64c8dea3db409e23f8f60465390adc03a491be6d4177020ba01d412d7b565bd63559e13bc98494eb7e45fdb7432064a8a50980771832ab39a27b29476b85e55031c568820bd2a9cb900df63f290cc1d043e31bc817067cd42d350db7123d542c0061c0f802a044a050a0277b5119881e121a94dab052b49f28c4576abf5653f17c0a5d45ed18d87795604bea1cf5c2999f2b29c414c3153c43c2d8c4bf216504fcdb9838e5e77a9dae22d79fc79ec4aa974fc80436743a74de1aa20c526fc477477046b50fb9745afd2f0e58a4df528a7d70953afde5146cd241ca15d58566f40f419709e54671ee098484f72cfaf8873616bc17ad64f073d776bdd2d6a8f3e5721ad2b7d82909a354cc5cbb0f49de6a5e08a22bd93441955874d5edb1b2ee30409603269f15a65ad349ae63d96fa8b502aaa74c43c84452a839cd32994bd7cfaf0af0c807de2f02d11af773888a27a88d3b3ad3b645212fd338e9ea7061fd11ef2e5d8ff5b7654fc4bc743251127597cb7ea123a03855b93fa41df289ce61093c8623da5d922a986721cc0fb32a71d3b8915803465e8fc69cd093b7f19d0240e4b5bce5ffa62ad4c410d66f2af8210f2fe85b21a1d5183e849c90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008e58337940ee74590eb25e52e78e8563a09cd2d45f650f48775e3e61f9e3509cc8eb7e983310d0185359f66bd80e0da1e45a6beb53acebb9030e310e81a576d0f80c64fce1d1fd77dca27b7c6e02b0cc26edbf496ad2e3ce8484e988e56bb28153587d7ecb02fd8882545e7bf79cc9966a7fede93f7e9451bc48fdbb481673d1c4135f95d68f40f4b4f847345a320fb4d736bf5f9fd347435462dd3a238e4c799e7cee081107e11682c7b558b19177522427f1d269fad81b565be538e8ff2d7193579aee51e50974bdc0b66331b59bf496c87e4f6e143754076db516c9c538410fb38a930cb5ba1e6610441126d01c8eb5f34e2e58424b8b218d9e68c5d8b4f5258eef07ee0aa5475a72ccf363d47d825fa524c16c7b7587c44864da9e4b267f738b87f7e5701147f550cd38774b17de48e6969a0dedf334fa67470419059c4d1607880cb12fa9c0ed23032c7e0f325169eace7daccdd4c2e5097fbba859970d7eac4522c1fea043c9278c1c89fcce95203033b4cea4f9f24b55ba6b79ef88f275310c6e48189efc1eeedab66b56b6bb028726bc463d93d742492841e85d5c837948978d0fadd1c172f8859c802c6be8394a05dada7546ee1cc5bb909d3189088f4fa6d07c573ed7263c081720e701d5d4b027ae54be175536f3bd5e91993cc040311a7d352aa26414cae30d10408ddb44e8c9513f4619e99edc894f963489876b24bb0b91bdc3ee5b78ac0d4046b2e864789c0c779e5af97f8f84f09a26ff74b8bcde66c007970830b70c2a1122dc9845905c3aa7810b40641e8bbb398a23bbef52bedabec7bb54823e64177a73786992dd67d5c007d770938402efbcb3a60281c5706920a9eee4c26c0b251c32b9e1936fdec2928110959e99255508250fd5ba84b4fb314187124072d30fbf2163d36f1480ecc08f7fb8093bfaa72f1914c63533ebb3a57420dc38dc93dd6ae4d197fab790c1efc1b7a2234522e0b408d0648c7ae782f2f08cb70b96cd76b5089af1ef4ba3a4c2faac363a4dc1c6c421f6ae1e9b67461eb02f36c25e763f1a2b73ceed4dceddce619cb313d124ce6f7ac986d6bc344e630f22cb654c1286fbc0ee01c968dadd1edad744c8bc828cf5f316336a5883166ed000ff98d6ce2ceae7d3e40bbc5714f71ba9e25e1506d644fb2de2fe190d327accca79d9b6d9db505cf1853e98f30e9ba5e568ed83e2567c936a64420c5d8f07ac4f65f38c28e88dd7b5209a600aeb81a6d2afa4faaefdafd9b7fd3ad7f49462cd577204184f9d44a45e2a909373ced24ec0ee56bf2e6675c506eda67b1e6dab75cbf1822e20e7a8a81a7729b42a6d67a1dd457fcd19b62f048ab97b3d694254e5c051fd2daf3d12ad627ec37c22117bdee9eaa290d11d56baff0de1037eba908fa03e2f869fa2b27936669306e8e70a0a4910a123f202797bf1c8fe47178bb1e8e8d7ab1c01f30f5e779b2bc99902df15185fed4c865997ab72254162d00858e0908ea95a9acd0fce72e571c7a381cc33e06a27fe6a5922775ee82c973cc3ca8a05717608f8703946c9a89854d627744da475defc1390dc44fcc3a23c47aa8af17240eb1a1a00a062d258d471f31333d0356243dc1cecfc559378b4395f01a970ea4074d5666b44d49ef291ed15930dada66765b165cb8331cfe549c38cd0672f534be60f4d9b4c125ffe747670513b5744676899b256b992e15106b99b794db3950582816612144649210751f3d0dfd5b25cd393e724f7fdef00756d0c8540e8891e592507599b06edfa6ebfe543084ac81858f5eb02d8f5eb8a72184851e8589a3ac6dfe1cdcf286723fc4c1202765fa4f783ee58c627ed494c7149bca6a4ddb420827cdca82dc42515beaf46ce9d9ed524bd00ebd3094f770b1e1dd09fc431e4c244d2305619dae208e65ef385ea92f5a79f12b99afdaea79c9d8d319944ac6cbbe3f1290ec6b87d97785e059e6871fdf239bc404021cb52064b88eb4cb3fb6a871b0f76c12d7b8c5e8fe0a65024ab5b25f4c67b6d15c22b0005b754cf7cbec898b49f4326f1ae4034e5f5a446a96ce08083d48525a3661e10c996dd22dc34fe570a4c8817d10d750fc5c2ed0c24c7cbcba5cd1b2680dbaa3315fbf2ba7457abeedc96b5d111110d4678ea5c7851d25f258926b0b028365799e940a6e17bb03cb332fbc6d713dea7108fc6268c8d33e7a578c94ff75be808c15ff7884f092c0e309f1af99b1a7314fa0f32c8d8e32b3e9d92c9c8ff6b8fbb99111529c4be3a2a4f62884373d0903180b4deabe613de5cf19415dfba7f9a46297ae2f21d7ea420b41f628fd8deba55207606539d11791623cb325f1e18c98aac27283bfab2408f4fd6cc58ec9e306643ba1c0c77d84b3930263e5a76a1ce94f3d7721f0098d54e6c990c3aff69b6a0d82c853ea2af2d3d2b3e96dad59ff873171b55d16ca9a7c68dad2e918174d264919ddcb4b9d01ce622d56c599bf60711c74315c918a7bb97b9513937afb6a652da68b6b0b34e316d7be9f5c282a5e8773c892782eff220667a6a54069c37b88eb1ce676aaecf2015e59fb7af4d30c4625dd8de4805f505e83c877cd61d2a0ba65b32b0dbdfbacfc88ca43e4ddf7a1a4517dce83b7b8acf8dcaad28284039747935865daf8dcfca29fb676ce2eba2c509cd75588fa5e58cefd0694626c9bb31c3afc372ed313c9bb3adc398e89dbdb108dda63f9380ebf9da17b378451634682f9823e209bf10e39f884ed270413152025cdbf4875c121b1e83e12c044453ffda6d8ca2c240ad522577c6898ab6f2abe1fe77f860939408cd193e605f87ff2248fa163ac2fc0f39bfc38503b23f5441e0e364caaab890073266b3b51217661f5df41c0ba925bb425ab3dd7b6a3675b7d60d0290131ead53a4eab0c66baa83f2fb77e74c3c123aba7731a3f62fab8eab2a96e8bbc911e501cd23a088e7887a469284e0b5c27b5cbc1de2b6938cf1af58a47fe78141306cb76e8f2b73620bc4549db6826d2d72873885f6c5311eb5b9462bb4631d314dfb9c836c6f4d9eec6818940c04689cc4d8d11ed9869355617861340e722b2be78197746e2759aaa8d68d1965888e89b6b0f5bf51f94e586b2cb8708f4cdb520bf31ddccfb7cb69e29a7ae8aab12c11f431de40fb9e82eb5f2b6ba1f9757f1487b63255fa69a755601c2fe17cd1892d5a6799c35d05098dc133bdd71318667d47c4671000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 68","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029139e5ac2e02798e7b5741532eba7097878cd7ad2369ad29bfc8c1e7b99e17988b4718fbdc5053815c2a3db3a11a86b8cb0862cb886f615a249dd4e717c6099a6658733463f95856218c7fbbf869ad5699a8cd24ccb1a12228431b3da3ea24d81484786124ce8892ca8c667f250c7d52c8265716b3ca33dd15915c999a67a28aaa2b2fd6863ca34bda4c1508c4a97bac8f0a815b8693f98c510c73d28cb10398c4228df4f4884676f537ee6cad2948319fa44ff835f7e34afae848aa1b2449c9fd592a86c2e979d616b9bfa030e676099b316a120e7c8b8ddd9599970b053bcea4f912054dd28db7b5e691c7c6f060c5ef6a65e003a6bdc2b64cb2572d7e3d9ffc34fd25dee2ac6eab5973da718ee1bb882e0a94f48d65308905b3729cd3e83edb374b892226f86ede69c88f8cddbe251cc0faa0aae774f73c8c49f48fa4059fad2940751db946bea5adb5c92b9c2e99a3cc1143afc2fc605d847135917f2cd11c1aab17c798553db834f4ef4764f7a1a82938fd350d39005b2870243a0f5025daf60dae82f289d63e01a09aabfa14413beefa923b6aae9e18cdf0a6bd73553651d2b7cd077e5d2956a1051133c36ca165d6e330803e061981cc3395bcc20e34e5931b9a759d0a9ac14543ccabd6dcde26646bd4d220d6c63724582eb1e11f45dab63f53f5698d6daf138a42dbc7d9c625b398825cbfe1302cc494761bccb6de69943bfdc81ff27ca4bbdfdbbca100d2bcb434cadb2247f61fbd711e402e5eee0c5f3d2c69ab8c223abacaef09b6c7dac4f596bcd277513768e9bd68ac796aec253fffb35a4fdff71e9cdc3db106fb7d547d612973a4ca2d086bfa2232c9c10c6410325b092c7f685263a573da3d04116fe264486214ebd96356c8314b8d1d368ea93bad4987caf86826c8197c823034556d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a79d8040e9e26066655962f0e74f3134bb32b063444a346c05b542e7aa950b77819b44646233f0bd0765616a7c47b1870d221e55a30346f92b347f353e525497f49bf5066df87efdd5a3782ac657fd1209515c3396a185675f4738077004d945efaebd210c50924d574dd0f8fa44ce3bb88ab1d1f021a65d1068b6c1e0f99e6504e935962c437c3f938666de1ec863172409bf4090bed8e90646602587b5f5461370cd4727a09a429850d9528412041f40c161ba43b5097d00c34501bb21728cd398d0aa08e5ead01a13a790dc091768947752e16529bd6a058c26a065549fe0ab915b023c06f412e8431849e1e7348ddc1585e03b55b50fa1888da4a5a59e367300ec7e4dbb609fa1b0424298530ba8ba480a45b5e95828013cac88239a989bc26992666142259d6e77e249467cec547592909c36061410f415ab230a33e623881a609d7733e7ed7bbe9d4fcaab864fa0a1cbb6eb63d91174c3463aefa2522906e6b75914077d3e344f89e28128f51a6f1ba1945232d33ad7c277dc35277aee95acd06600ee029229d5a7b0f3cf7ba04a17c1fc679985582a6372e2f59e52e6d235ec185f0db232a92a3da6c876328c4d6e06faaaba0a02d213e916e73f59db6df40cd1a09aa29981d7a0e760bf5e6939b7a42c7b72d27aa1eedd2972f2ad47c80ec667bae45386e07b48b94536c8d2523972e83473d8127085daebde1042166537f8bd08543bb6bd00a0af7d7a64f662b510996f78f84675e49f1466ef922b56eb18653296a24dff30aedb23e82a88a55cd478fa2425781e7b81cc5ac045aeb525e485117cd0143618529d259a8c725c1ed4202d20921125117a6836f9b80912559208975525eebfaa0a25a008827b259dc8b1104d45f922265dc0c551495c91d41ff8a09dde9463c3906f7461353c85af68ae9f8222c9c53e55ad234625bc9c5e48205d4c944191b6a9b48fe1bc0e5d50254c41b7a1ca52b7c57f0a1865602d1b30b8e2235b80a3f3811931c956e77c742c60a4c520633615b215da86d6006286e854018f7bd4b33a31c5d32a1081b02c993babc0075a6e8387bd02ca40d4aa068e8e9cc9ea8540200d25b9cda542a5f8a88779d9091bf27e579d5192b18edcc341531b24e840f830018e51de8272d0681ca3e8aa5787a7da1f70fa3b10db168a8dc6d4ef68212e010aeb7c54e1aafee6a79c9fc561ac6edb316fd34510f57aa6a5ec0ea238099225c71f4d0d61a85fc371ec13856ea74b9f68dd468d687d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090662215248e1f3afb19849f758d742f8afab595040c4dc520d603c9a80fa9cf2e97e4f4bd7350551fb667d606bdc31a45d88836cd376785c01f9007d47df95c1f4d1e30a927a13525409d91c9f5145c0b86d3b44e933ca81e4ed9559ac17940c61eb85b2d26d2c47924ab80acbaa3d9b1c8855c13ee45f5c8047c161aaa5321839a01783b21a5ee90cf91b8285c4779465b7a89de3d74d482080f68eb2d8b47429d5475356c50a92b3acbdea5786f4d6c2a304ab500490f84fd1d0f21acbea325d62d2657f3889b6f591a7f63d8633c061cb14b8266a7fe17642dedf1d08d9ffe369126cd780d9f99fc6262b5befcfef35d33498cb2cffe55f2f8d567ea8687dfc6e7d49a61fdbfe768c1d11bf5b3b18ca52225b096490c97cb9a0b3b2ca0762dcc36b60f7d26fcaa4e38b1f3a6279d889323010d9cb0a97fc488e09b06237e6eb0166465c2cbc2b9cd06f155759b6c93ca0cd3178845e0f3a2d20a68757aaf3c4e74545494462ccf28f6f51ec0fdff4f1e6d98fc5b63bff068fa7be1764bcf14497e71e424c9389c5dcf8c5ce1dcd40b82f1d75c3c3970da433a92a04de958766ac5eb3645f4d21882f7071383af8dffd6cdd91b549f143dcf59fed6674441eeb03d5013e90adccbd7e3da115535ac855dbaab7f51d70630dc00009e726a16deadb12047d85906cff315c73ee7d4e24c9067e3b772f3dcc44c25c7cb8622fdd7b8ecf5e9c877838d71d500f864a662619b1478f8ab4db2dd09a111acc99abe737ddbca06e88926c4e73b5f5d21eafc4b11938feeea5f8d5a4c616a342b54c9ce371817aa2409a55a3237be85a50f05b33d35aa86a62e85a01cf34ee7dc840a26fa1b8c6b307817c062d9a2e7163a3b036874d2abf6531a772d4031fdcd59ca79fbf442cb9155f90148dc3b723778e699c6985634185c3ffdb966adb80a3d1308150b12964142498466506bc0742783c27bd3472a5cb45021de066c28143ffbc82b5742be51e93bcfde1a61e661b730d8760e108b80c859e4b3a07d483a6a8967e5f01b03ec8b63a20c6a03755c75f419558878a5eb8bb0b2120f183e4becd4a104eb4db62cacf5f9964583815334a25bdb75724e549211699ac3bc9b2b5f58f1fb33429905df81c9422f8b84e95a7c36dec6ae9b48d4f502d8ab59b69e9d112693578d143a3f111ef00844303950f65ddeea6e30f1286de16546f90c4364a5c09755af3fecb13983c418b2fe4ac17bdda57e4d597e8bdccbfbe4082c446fc920e5145bbafc67fadd9799cd8c7714510da579516ed39b3e22de319977fc77a9ca61ae8252795d11724aaa866c1ffdbcbc1ff91af1b8713248864a4e8b9c59dd12863245f5048110dede7fe31ff9836715886c37e9642dbd6c668ba7ab8c2b706cdd58586eb7227b5768c3509c1f66493468859e275700ea38ba69064179f6036d7b50bd232b61c9b9659492894c0057dbfb80329a76cdc57b2a89bbb910483301ca0bf6aec7d5ddf86644ff52f48ff6c7cd00406cacbc09aa251708baf3276a52be2c7b42fb6a9036c318529ca98940769a67dcd532c0000afb5fc63ad2303e94e09d2cb40ccbe47faa1dd22ecf528179ad40fd4bfd43717864149243d61ca255344c52743200ed8385a7ca6cca24cf967d23d07dc2a3f9ad5f3240f4f022a6c6cd281b6c492e8d144a2f4641957ecc65b32c9f74bb468524ff58f0f3da2f5a56742896cc8f99088574264f857dc67cf04c4b63c6a08fc534229ca8ba616cd504f969ea6e3c98a517355f98a9e884062805b77623239074206e01ad2f3fc9fe9ff8254a5d3525c3b2f0a692803500c967a2e18511ef5b8845dc4b0dee9338c38c4b1b8b84ee63923250eb6f9e9c272617c7895bd538a6f34d3557812bbbfab2b8fa6eb5e95b9bce33ad3185cd90dd536a68639022c079b5ca7748864d37d45fa6780a45aa991f28bc0d3bf371ee2ff0c913cea6db38e4a278a4840ea1f255f8e83b6b6c5e260a49d727aa42095a88cb8120b51dafd764e690102f7fa07cea2eb86ac613e7be2f498f5767b622d04e8a6f272976fb058c3334cf8caad1d180e3456c210763c974e431cbc3e25ead8b9ff9243628d5b08d92cbf1d5df29a85b1a04d2999b3c669227b33610121d543cf4a978f8d9365c0ff8affa92b07fc8c8604a0f357f3c669445685b6a29898301a5afbe10ace8d64a47009c8741d7ce82e9900643900a3b92a26fe5f24886c06ae0918c3f2523c320699c799cbf72f0ddb08a0f1f63d6dc2f021c78a9d44503209190ee4be654663679cfd292292d71fc4ba6233a196ef9e95cb965852773404b2622b565bd91fca6747aaf7f4eaded7bd3bb53645381b687ae04b8d8a9bef1095eeb39a0beb4ea89badb4655a1afc7eecb7da0d670c192297cce0b31bbefebfe94c84603ba8c0b7cc73159ff59c01a037cf2c866dc40d88432cd6c2f1989351a4e41343cacf7bf2c2b395c863709d6ec1dbab2af514cc771df14df095dea8284be2b65097d8e6f72ef3936595384afc0026956e819f1657c901b92644e9d6d32d0d95549729b2cb3d5efac9c42a5f284abc3bf5cca5b08161b09d9a48ffb2996c3d4383d65b8d1f7fc3248cbe84b9c05464f4a76efa005fec342edd56959cd26cb0dae1b61b0493a4b68eb3d6335bbc280508f09d84e0c5f4ef520d92cd34d69e5bab76df5d2b72cb41a298d370ebeefcd6c1904b956458bda581efa6b3654be402ac3a971603f23f2b543c5beeda5f018543b72c146cf04680bcea31b4a238460329e2bc12f14c804fda3494c15452223d2477c9c8a497d04eaae7de09d7d7a879d3a5dba565ae1a38f15e69c18838c487c0fbad44a068c42efb7d3f5ef488f91c42f25ac564751f0efe0ece7d98bb1b3d0fc42c9756f4b8f9daf1fd0d414391155285c8daeaaf380bd07e43570f14e9a47a87bc733f1e676233f17bfb71aae464aed68487392d339ae064ae27bd57f8695f493ae56ca96c0615bda8da37133dd13c2b21da189a7329773fd8d51381bc118645440b28fa4f402ef84c4091d3a0bc4d206bdcf9007f5de9aa1e6cf7f6058ac6b69fbc703e908c4221f9065147766e48f54be4b076406e2f9ed19c1be982e636fd02dc26267c3ed989e6ad1cce62e7b988fa7c1831e5126111a4c3c29c38a1f96ccb3a04132175fa46f73c634ac6ec741b135645abf1dcea18571cf9a539f5cc935bc6d32beb1c7b8b3b5a141146ebc12dbbcc17bb4900cf0b95ebfaa52190afc6d8933cafc90000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 69","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039ec14011a2e55345b10861679d7746cbfbb1c12583e3303bfbdbba2feaf805c123a3b19c23f5d9f10306cd3139c8d32bc85b9ef839ff76f90c244f23b68a19cc277dc9b95668ed6163fbafb839e618f3f0b69e675e2ed2fc1abebe061c9cde33896675e5c16c1df5bb393586f2e68d154b1743b812620ec2f3ea38283a08bd36b095a3338f4910acfb559089d96eee4e0777d75173fe7b6c42f8b72968a623ca8aa652f6e91edf4bd226094b45ea97f3f4f413d5a3ac4ed0f8e4470f7eb7a98e6268c3e49debe29969dd649f45b240d8ce7c15ae8d064827cdaab8829854a2b779d21fccd555e8502c91c93a1f95765344244d0edd3982c20a54748eb69ab4ae5280e75dedd784a8b22bcee3ef644a2ebb6794d6697172e520b142e1a8debf146923ec3c74ff555d9bce748646cdfc70eb635fdd41a6c4200ef4393f823693b3b4929879b2ed0d55714761054bc99785c8c0d3c8e70f30b74d8b0d2702ad6947d7f32135256fd135290a9a72c1471bf6ae2a3a30a419a74458f675bb2a6cf8b0fafa2a2a9ec3e9590962a6beeb8b5483138d84a628621ac267dcba0cc39686391056a487bf8c4d54a5e65bd8832f3c561002432d2664e3b12b443e5becf14d235ef7d18785c3f28d9fdd665d74d8395a3fe97aa73a9e1e54f6fd74a6f76f5867ab18525dc9f2525c1883b892afd9ed8d1b1261dbbbe8f0c2202d7cc6de830ccc00cf64d6a9c2dc8b244699af46e186616192e25ed9b2eb124dbd3c36c72510766046b7f70ee0eeab7304e6ef4faf9959624f7e3490e75d2373e3e8769a286b5e1b77c7c3a77526ca3c54804abcd5c8f4ee4b2cfeb1c824332140b822194e8b1df993b8098d2d11a37335fc76e54ec841dd13151d4b2b97141eb3b0df7af6c4d709addfa3348a8b9f28eedaf6ce7ef500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810961caff0b7a0e20b8deb09b7ce1c626c89d7689d5a910bdb791865a7d11455584ace6fa4c7415d79f467c674dea7846a73559d8decb49aa897da5186264d4e235a629a1792b5e07556be013ca214551c5763680153c6e9ff71225a747d9b5f0676b2a32d1526afc6f21197ccf003359040882ea8202ad28630d39918621a278a151d05d65de8bb0e78552d82357e08934510c43554d2da85944e02d6a6813a1d7b605a53e496f1ec03cfa0ee20ae567bc4862486fe4864b98aa33fede4da4a2a747381427abf57b9a56214d5ed5fba4ef47654969e9635acc96adea4834bb5162af29d6784e8d173c6ebdd54268619b22436800ab1637b5fa41134e2052a1eda601a251962068c9b4191e2c0000833981702745fd58682168537153a2d0a0789d99ee3891ec0a45e2b179f54250992a3441b411871a0287b0daa4858b66b52712191678fa23d98665bb5c9512b28a1c3c96f6966089227db7e96e0bdf8abf6ae06d98d60e9f4901f53a36518046bc5485bb9700b3515ad35995f149bdc873ffc781a4caa7659aa582bc565c9ba8c1f9403cf727e255219854a8ab0d69ff239c8f609960ff6e58ed152863c580a08b6b8969f0012443416382274162b821b8caa5a24567e441207a1ee6c0a166ae377a60dd972e827b2b40379891a656938e5fc4abec5e8c69f719a44d243002e09b8cecb7290ee976aaa2200fb256f12eeddd7e0415eb365e613e240eb4660df067910d9b0d536e415ede269b200f4c1ea0ca170db83cc9af01f15eafb0b986f4ad195706edf6a07e51a0ab306b178725b7be392556e804180b72bb3ae987295e15be511614db45a006f785d06159684a53f854b6026c04c1ea55b5672181c3b106a94cca67b88185cfb76cdae407261a5dc862c0adacf5618efb221618af1c8c8d459d89a87b72602b71a42757bc25da112eb79ffae8365b41c4249d75aa138fce33201e8720a72f680e08d872a5609a3d4598d711aa6a1824097f9be821408653ba88393b064ef45be48f568933e0b10f66986a2530d48707b875162a0f9d954562804b2aebf87890cb61f68d9e3b515c29c26d8ab3ec21882a638b32508d46641b2a87224c620b0ce353560c12ef95837c74a0d3b8141e0f8a3f198b5a58859d19a2384f9ab459bc4bb50626b502b008a1807d110a8ceaa4ec63510df592bfec149c38b1e4a295799e38a070e387da5a8c4229b84f446f04ead911dd7538edeaa85220c27ee12899d7eb085c6ea450408b4a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000927954511394b9d10e1ba162861802a717e24ee42a346c9ed280c88e267a41ec09d6d73b6076e7e30257bf265b71a0b6e0cf408f02ba9078811be94d0f38559e9985463fc9671d182286cc4f18cabcaee1a3e5abdbc384fb27911168b54a387171c0524489fdf512e4d8d2f65050cfe7405d8df63a79c6e42a76f4538907eff4dc5870095241523f56fe8e389ebf1a1cc47ddb9f0188513d5259be257bda5be7381f22392cdc2406e0f2448a80f3824f2670f61920c667499de899f0f6b397381a2de66255e061ab92cd864de75c9db7cbab9fe76ac38e0ab3389530b4004055268b289b40d79b32e5ebcc74353510bd1627e2d5dd0be7d3dfd04138f6e3ee7526133dc70490612eaa5024be6fbefab24e1e83d8941a113d8b871f3dbc3011869174888cb7a265d7de9ab99b999c19af9b442ebdc904fedab52cf40b787aab35626417c5291f2eb892f43e698a8c65cbb6442a4832f33920fb2dbfc50b8e996fb227f2ff294c385a330957d2fada9f86839235ea79ecde6d9d94fbe7c79a38d40b9a8f241f53b921107ff1c72624c9600ec04dfa1160f1fa9e5d986a5a363e9ce8627276da73f5db47e4b90328884cfe93194cffa6fa680f77886e4a7a0fdaf13a7ddff6984b8855e1f58235babfd5106338fe2b075d4f10a9fb3d3c5f829b7c61b02b34e9bde6e62cbcc3ac9f467a6ca170eb43e632ebdbf6847f781e2469b4740fdb83da34ce34a286e3b363a72cbb13eb66ce1de35d8fd77dbedbf45c44dcd16e6b58a1699694d9006947c8c20810e85e3ebf8fb2c68b967743642d86556ab6958e545ab83ec24b96f2b4bb99cc8890c3c1e0fecce26ce09b6d99000694f870af9f642374ff0bbf61efc7cd5aaf5667fc3fe5745dfaf7f13fed70fe070ea4c09cb1a92d8b7f0dfd4b4a4b7dcf4ca6a97043bcef6346f1570f37b0eb48db8d15c8a82ed69b0c7833d6c830414c111c987471e84d2ceb5bd973dca34acd3a65d7b1a502368941935435b78b8f2b74c2bef127d96651247bdbe68eb7e466b9ea2a64a13c375103d7c8f7d30a13cbe184bd1ebb19f3274e645f5c7b82efdf09233d8ad146dc0715266963fd3cce6f8cdec20743bf1b7f57c101ac24c64d568923203e1a6af03a700f5a401ec4572bba528e284c151f1d108f7563858011fab32b3776cf2b910d7b21180dbe75742032791018258f4d1407c9a213755c5c91205352df919b6f14be056243df6ac2909e52c9a79f6917440667719185f1c5f1aaf40d873ba22956fa0bbad9c35360853333a10a0841d9d2e758a0b1bc187f6bbd31c41b74f9eeef1f7a28bdb7ac3d52fdc6fcb3ef0383a06a61188548963e552716d2bfbd6c2dcde496d06615e86a5cdb76a03bca2822aba85ec6807ebb6918ad2948d193ccf74f4bdaf7090cd4294c1785dcedb6b55886a848284a6a4a88a496800053e84a9f2dbf6b334aace11a5a540626716302e259a64c6316ed543806b3bbfe37563897e83bbefa570312df908c1786df0fcf55069edc336501a5ae9d4bf212d56a9cee811038656912238ae284575ef8de1285b763ae54adf44f91b6dd9e309b7a7a0ab71ec2e4611831b3ce1c9dc85cf907b52df7406b06367e7a43dece72dccc57d268820ea021c27056e3c6b50e7ba7a59b53539a6b7b06b35051e3151c23f3bd3c889b25d0ece1fd0df1aedf657fbb096ca1c861acb0158501ea1aefbf6dad11bdc325ac1ced3739a40b7a83458ef4f3453c0f6eabc1a48037809a90480df9dc4ff07daddc58df2733d49a4fa53c2a41e55a4a0167c6d33ba6e752aed3a125dfd6a0322cd235254505d7b3ced7a0dee7eb662acfd30f8b79d1a872998cbcf15cd86e26809e0d2da0324ddc90fd12caf9d8e4eda437fe4e658d47d67c95927c4b5dee965b940ce93e6743917296e10820a7101f8f633c93069e8b569f4625afd4ec61bfe4549fdd06c2290a91ac0fb40cb1f55dc8bc1fe695c73af603840ac0351f5256e00555c984e79a09e58c566d1a117b7e569beb5850fb491fd9b982442b55bdf53832aa65180dcddc2f768b1a1361994de8c25f3608ec853d5982e0afd1f9fa70170fc3589ddaf958dd840b4b502f8e2697d01ad7ac2233f6a16d540ef8d232887d2b4fa727ae2f038a69af3dae69eda8ef6bf1e0b67d811160b75231543ec5a4d0778b7b42fc1dd6732385aa4400450b3caeefdffcf147635cfa4aaa53de4ee3035bc40ce8670016384bb877a86a15b59f3df0c5d624d3d2b23ec46913618c745330a96c715c6f0bd096487e89b917384cc30b3d20a332f1b4056462227e98af9874ff1d18df2a6bf84ae822ee737f9e34ee8c69f23eeb9bf38ed056f499545f405759355c104284a6d08a9efad8fe28288b2084336a6479a6d42404f3e6ff3ad1dfc63c8aae971af11f2699f32f57ad29188492ce07bc1a271035b4d13a686efde5572353283a0f3138f6dc05cc35e5e5057c5c8b9e12b0164c0915adedf40a6e23848fa59adc0e65bdd2120486942f232315fc94b4676751a35aaed2828889864c4cb7dd95a662a475733c2ca8f6997a9c822c6c8b9dc95a8b4c367e613e97d3ec6d6ddc2f81022ec21b3a93244e3bc8c2737a7724a3cbd480b26819eeb2676fd383601d79fa266ed3f9bac2a98ff0109ad7e43e33e108d88c09ba82afcccfe98f50f789109d99dcd0a2c61947544f3666edc621b5d5ecb7088b2430a611bea52be7f5edfc6e2649f5e81f6df72fa9a748bff06af766a60d2b751b23a8aa95cbf733359f7c0cd19b1482a6e6572d1570349c688d78cf8b8c7dd37576dc47a193a2c2797d0af7504dee303823a8b77204ae7b6e91d431979798a7edf435056251d0e3f26b2ca16bfe3422cea0398d30f0a0dc06dc8a93d27d13650e5bfb6ba04c93faf0d7d06f99fe4f1f52a059fbe808179515fda48eca714f0947fe9a98f02d66fb0d80952411cdfceaef6aba16d92b8f1b82db151d7dcd7fb7781ec55f4a86c86011fbb9c5570ee76897e7803036e2fe3cdc2d5ea7a613897f3c69a6ea734e3811bfd15e90d7256a0c0c88ceb54ec6aac151b435cd2a870e4a02087c2b847c75b00b44bb3ca6d4404c3052bd308b8d5f595277592d26f6d5a2193cd4d650bf931fefb9deee61032b29ec0412f38e1cbe025b2891c59574c1450d9e3d8ef27940ef712143f06f38ddb86341a7fc781e0fa8971dad13aa7e93f1858c70a71a40164211ea9f6a41ae90d19032c2ea52c23375ce3c4e59599ecd6855213aea83f8dfc5cc70f58a62e4dca17c09705c0c099b29056592986c03cf5d67074735f2bea00000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 70","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39fc01f3f7988ec8690f097a68e3fcf37caaeeeb35686bc258d98bf475e64b4caaa8fe2aae0ff6c828045be9862a0ff05a1039646dae4550e5eb6fa0a8ccebc94b4c4f5283d9248155307ad7397cb76d7278d54929e373e6fe74ee4ec23509671e34a7edd142f38719acafef4d287671ec7bb94dda64b63d04fb1abccc161abb4684a65a5272e2d1917685a4600f56d303f4e623080a0b39cbcdb30d4e79ad86c90d0c030994b55ef5486f01e4b7ca3518ce1364bfc6b0d4f89bd49d2b78153206da3533d20cc42a8f02ef63cff4ed269eb53b83f73c19d5f58e1424790425f0cf82609fb0d99f6a26b2a06dafb102dfa02614ce7c65c59ace445418b27ed25d21dade092fa8dd22292e0a4dac9f4ef471d7ada1ba60fc8e020b54342e746cb4fb8db2b7c0dba41d6aa25917cf2e234368a4711904f93d6a4953d893912c3a43e483c0345d764d1dd8a48ef49c78e634b52639abf0aebd9f455519739b841e111db672056a35148522d29c947e730b85a272dd6528c2fa5406605429af7e00de994eae639db695f9d8fc7c39810f2c1fe1aae5547c72d6e38bbd2416ce2d8e29ede9bee852aa80b1062fc848fad2583afb1661ada6f5a221aaa3f1f28b306cf60af5d3d093b4ef9693914167e6a0f608a88c9f2d6bd13deca52c711a8e6814bf25874e8959675a3c442ef954d24c930b1ccbb126ff454b4125753b9173e096669764e24ee35aba4a3cc38f5ae7bc3b32eef4bbf9321d33f1b1a65eaa599c04cddccddab4d94827058f5a35bb9a7297c24ae6b33ad781562b50e382889984138d27ca9b28c25b8242974c6616a88eee3888b795d8f15ae126af7c4de34bbaa35c4b63385cb1dded43228c8ce8982097ab163bcf6080b91b3dd43d3c64f833e4dec1caa6e75d12d45735ac836ee540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109ae9aef7425cc0395ec49206f4fccbbfaab89d24ab6b796bb906e43db6446b5db4aad6621f2c2b588d28613c9c7b0a9a85e5065e7f988dc48133a6e5027cf74974c421aa38e74946c1f6b0dde8696056119340d6a6cd19b42d9cccd89ea9eb500ef2b9536bbf78382cf7cb10ad34120281c8cf39917489b26be83b5770f3a0095b98aeb8cc2b87ee9f9a820479688c1708bee4a47c98ca00beb75b29823146e42b91926e9db7e2eb41df239aa04de4fbea9f64491aedc53c1a3941b4222bf1ea13619483d637d9c610c135cba3c1f86aaec146b85c9b5255d84b595cb3bcd65366aead7531463918d2608c2fa410393f6ebc21ce92c100db108dd80c34d36d8e934e45105be9b84b214c70ff00d88df8e98b898c366c1685f92f9ac29af603d1f3d13b3074b748c8d4247e9e868b42af52b4269da4b510df9fd66b83fc4ac713fab1897411c15a30dd6ab361dc44d16254849f420996c5986ce0644e70120acedaff77b2fd29aa2857730c62e9a3494e001a4b38b0e89fac0dea54615fe4613da7b104879a4a74e807daa851b01231c86014070918c2834800094de93866a69ac98761586bb90d05b0f6aec39f092433853c2363275851e8f221d2e2de0f794694c1545ab6f49aaa4f838104fdda0b8942ea5051ab89de8b4c24412e74d1923a40bcf4870b9ea94f8aa5d9c94122a88894643b65008988ef18b485dd341a0c48f6c5809e6485c12defed3c31b7e1f11e55261ed3ebf280c965e52fe59c5c0b0b701ac63c67a2379dad855d58c31c8cbaf9ee603425341f5387913854a0d440194bd743b5bcc43ea97e4b29def3df46485a168f26dec703378e82498e00c468c24c51ded2cf5a0666d59a9a0b3482573ac1828aa1b644d2fb800bbef838e385a65cb4955f5a44a19e650c3ca5ae9ee76b8c45746c82403fca210938a8918f7947d4eb198c9ca8a549c8142c7efc300416583801049d12e1a67c7a0afd96ebc7f806dd82d193c23f73862f231f2e8508905afbb504196668e2ba09c9b76b2904f264d0301118adc57ec7a79a2ec81374c3888c6c5514f9d53e32fae4a34b1d46052965e5890148043a2abbd265278945ca72816f7eb66840f7e026d0b53ec4039b9bc57356af474e9bf89ca0fe26a45e7459deb2045818d7601d7861866a225ed58e97f40f76446cecb85fd5a670a4b780445fcf64b8cc037a23da037eacd5dc485f2d9e1663f7272550401d6141836b0d0d83c5c253cab06152b8484abdbde837f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000948326a4fe723be9363acfc000705a10b6cd8a7b25e99a34b4a354cbd6f50550bed30f6c4208490b4194ab79b24b093fbe132c299df924f2ffcc2cdc6c2c9019eedf4b72d7f0817825bd787135927102e1da041e9a78b501b42dce777a79ace604e57df11775d7b87e75e5b00adac90d1add78cc5ad348c7472eec6e6e06f737e77115a9509a6ae6570f738dc2f21314a7ccb9d44add6e1434cdfe3614bc73a6b468f6691b60f4f2db103289a90c4fb2bf5aaf87826d2beb0880fa64e07e9bd30d4eda00d6bda01d1eb22bcf14ee797a859c9a0d9034e8c5316201af91388c47e1ddf061c9f45e067a5f60b355c98f8734559b8f1b82f47bd9cee0224a1d67d40706333523c34f3582b6c8cb47bf7d0e4fbc7d7cf3dbf21077e664fd59998338f4dd4a423c3a145ee1e994aacc1a48f81a7e9fe106008db93a6626b8c8505043ab864d93ae3972675e69c3825304086aa3419216ccae7f7d5117739e99d8f4a0b658148de33fdaaeb9967ef56677d2028c3b584c5cc1c096f4da16799408b2ee2fc3482ad2f49293cf4097a78492470099bdb90bcb4fe3b245ac8b3c53e05d7609e34770adcc147033a8fade81359ff63c3fb90c5a498c98b7a0e5ee9cf4d287759acda4bfa3965ca85e1d1c1019e7fe6d82e5e66a717f94890277e6db1eaa6f3291fe1bcd7d437094749ff5574b8728e0dc21a143a14e382937efb7ec1b0fb3f6f9c0f547f470e3b436dfc7986f923beaa89583d8978c433e0cb0c4e98516af1ac797c778662455a57fef45ba2c7865c1df5c502edb01c8cc729468091bb96be9da9c298528187867eee9a06141daa15f60cf719de2bd15010550b92a41f12d8f38b54692589aff51a9d5e6047a0d9b707369992251df31341a45b01b05ffed8adee5810824f903ea59f14fd500aedae797f8baeb470c0b14c4eda5c687e4848a85b30a8e8f59c45d4c9f0c65fccb15f4d4209a55722c29b6cb09aecb4e53fa3aa602c56ee3ba6900cc12889e7b87d5ef283af1586764519a30cf60833c82f0ed15e39a8bcad5c6aee9999e63d399c5cea10ae1f53b04858ef7896aa29fa541451fdb685734c39470250545193caf26c9891f7f965904ae10e8566bff9b2f465bbe13d6ea4a79586e68844b9fa68b2f992565c8b0ef5ffdeb5878cc12a0571ca3aea50add29dd06e13741a1ab215bf487be7735d1634332f47e037253054a21e0ad8d8f011334cb5951f833d4d344d632bcab7c373cb7dafe8f3d79e7e13bdb1c6cffa474a9fbb46f5736d55f3466534596ebd22b29107a8fa50c1d0e62f0533e343fee038fc0c3040a6df2d318bbc8420019b1b148d6d1dd2fe428c2fd617ca73f224ef9af9bf6f83cf1006616235471b69dd4eaf9f32529ef3e1dfe6765e61e246b519c702351c9cd66c57065ec78993d793b082e3685eb06f2530b07862277d339a52813c99ebe16c06c4c8f547d9705850e770982e8fa0275a52f430ff2422a115ece46a9202caa0195789532b1444f1507aab2e4303464e499989f21c7d881328f18dbc77d4b9b467cae244a93053c0321dfbf815da28b6ebf483eafbe634e9947bb5383fee3a31bc03a63fcdda5e3e46d5d3184718c348a83975728714351df43baf91787caca346dbb819602f18a4c4fe90c4ce307984bcded89cd2e4aeb66318c10d95afa5be53393feb981c21bb1411bb9c58818bcc141223d66ed5f35f90c05fd4848617220dd72f5e892292ce20aa9a0f9ad54022cbe94d2c86daf3fc66949ac35d8e122b02e2d155e73f4ce24d7e85a5c301dcc173ca8ec090af9dc7f443c983280dda27ed4b9bc71f86e84f7aee39e6a7e9bf5e43920aac858f0f49a06216d9d3984cd2e3575c0fa6ce8a5e28b0f481ccbaab450fabce8a1084ef458dbe257cf09d8116136c2cf1edfa6cce31aed0f1f8278c1c8d9c79846886d48e3fd311c015bf2373f7caa71aa26b011d0df5a843ab53d7e7f0466ccf49c5d4de872ca87b8895101ee0147a3dbd391beed75fc16f65814d56cb29273a5f4e5400fcabf85040505c31d001df0023726e9c1f7c29a37039fdda73b9b99acec3a029f7c0dd61ade7d5e835e1cd605aa8e583bf8dc99285e86cf91f4b4827a0e8956efde2b495a86f85e78b954341cf3afebe8db71c26b9b1ba27b47284aa84e55b1c2afee733ac596a10186d9ab504f33e34a06ca931d7633462b04b9b2b0d4751b0343503bcb2a1893d944fbdb4be63de167348a1588e6551fd9cf2101b0b4cb61422655fbeb50d64cb9e87a23007a39821ec3aba391485347624efc3dfda4a133c537d7cd8c3a549bb6bef9a52d2edf0a8892c6fc3eec3efc3c18741c85bf24cd3b36ca04ee77f654ed5595a0e4b9316ccfe4d2aa6b4a66b06f309337e363c9e39829c8838729f19811093dfbe962246473b7a19faedfdb0193f63eb85ef308cd3be5831f35ced36d9448d0ea8306044f78946079210cf89ff78104bcb2964ce2af9954d53885d7914e4ffa4ac7e9b3d103922fd1ad68c0a4592f885c5fee51d52214e17035e8681086203b79b5eb176679eb3263b44ea7287262dd84bb98f6639b9657ac04e397d69c634a0c1181eca485e467d62631ad2d9afd5ac5b86ed4005fdbb7404b65bbb826f1a2334a481b9cd46e0ce9c414a162e84368089f24149d7d05ea6adf40b25a708357aaa5a28801ff100f69252810188cfc6087507bb5bde1cd43bf72b1b3207ce4f7e65a18e5276613d4beddaf21af7b964ff69965c47cb03846f7ceddd2c5133080fc632a4f0b3495b2d2751727cf7681f28675552df2a0994e425a922bbfcf84189b8c9f43058d691db3166c596f6bc480efde06bdae7b9c2985a1f2f6441520620e193d7b94ab46dba2a1ade44e2b006734e6770f34b0e2122dd7f4eaf045164dea8c2fece7758630384c00a6b528a6ecf07045b2dc0281c936a540904733149bc65b0f57acd9a5e41c2adf83fd6a760b169beebf04644db1314270adf86d01cc2cd580c609e78bbcd9d2694a89f9cb6dd36b9aa2aa5581ff561b5417be2b52f3ef2581e461cb0690782f33862c52590643bece0a6141dc805d8f56c4f64c1bbc49a3ecf1e8827926796e5f9335df47da6d3e4c14795b547116fd1f3351fc55c28b543183fead8df7da4dfbcc38e224901ff7bd83b16631064cac4a37fa632f53f004374aa19861fdca515af91e66186ef804366d5a1b3b4faaa60a0c4b36b972a9579548b4cdace7eb85f1f68a4e4255fd994c1786975e7f6f0ba87d0295de72876bce37146a09edebc0164b9c4911ce41ef4d48130a27651bd0dc315fd622cb6d03759d35756806332658b5b33e768860c1946569aa45130486ad49b000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 71","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39be9b5af60dfa7ab0c6db2abbc5e2cdb5c27ff330b9039f6d8dcfc936e3491b3deb00466c5672e96293298ff43b16698c36bae260b0936eac6880c9f2edf5210b9250f105699568b65536ea66ec39d5992c49432a50a15e7794658d3dc54897af833cfff99266460566e52b7f4f841d07beb3ccde37ceff5de388de512c64db665b5284e93319072997204b24265cd57a1512ba5d13e43bcdf18d3ac901248c3f95b61125c91a295d9ef16dc227525691ec63a2c6311e757ceb3bf8b13f33032734556b28ce810dd3a6990a86e1249643507e6e9dc7ec6aebf0ba5d9e639fe508820f23739cdadb65ce88094f6390d7cf5ebf35ddcdd8a0d6693c238340b86a7d4d19aae1b4287997b03e6a1fd23ce66e3f3bab8349708131bbc303781194baaccf62137d464172fc575f99218dbf5865f609bad59a45944583d3c3b14b5b03edf5c6618ae1df8674e6fb24fe12e02c5d7ef4aa28964f572b8e24a26f4e172f25c7aa2b7106dad8a2c566782d6467193433ec71bed82c9c3ab70a3126af48566c1c2b1ce56b20aeda68aca7abceb7412047e1eaebde85df2ca976e6533be5e258e43cf6ae983ada3df0bffa747fa4db3fa590cd726c5761db5be64cb3f98f949cb6605773ca216b2a93e63e8f2bdb4c7c5b255d8e80d8f70652d99fdb3b6edbfd7de8905201843033a23d1a8750169e767fa2a7f4ff0bb4f1b76d760e857d2345cecd6de2821d2441c0aa6c8a54b33f858d22c6358e28c80929c647e1ff0e3c410f4153fa46b2795b524bf73d13abfff1e90239d78c2546550840443ca1e090d3f4f5c453b2a5704c76374f4e291fce1294833359da2caae625c4b9d10d8ed2a1b47779ba8adfd9ec94a6ec28a1d56c301ad7fd4a6cf8fb8bb49e5cd8a95faca199ec916c339198eaf12cbf48000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381093e9e3148ef94ec01aa6347e5e3441e62ec57c3634a1ba081212b27872740d1f61dd7424d3e356349d8439785dbe8fa11da6d61fb49aa52e54f0d88e99be86a69dedc256c11d617a9d91719e98759a07911180c333a3287fb52eaa3862986d6659e155a9a08329168b73cd02c96f98876a95a03643eddc75ff299a99d95ed2739cd0a980a3c1b7ec3cbcc8b6b82882a9aa9c63e5acc93b465d70e939c0171b045273f0c7a54709d1327141d352b2f76b9494276bb5bd79f2664eba7ebb974d5a858a108e457ca32322d0d5d5a154b49a18e7ea9b21ea34a2478b2142d04a9642a146285b56796d597a04c418b2d8ebb1c06c514a2a54b3a2e39c4e9878d1d9ad17ded801e80afba65e80a227196945c135504649d057d042e886c0c029713ed503da057d6a8aebd29566a51ab4f7de666f96f8a8d0d4aba313feb9846f13481e9567eaa41d050b465f781690f695a456050b47507a7deb7117e97595d812e7284851615a323247954d3714b83652098180b4aeeae01d055a7e83b542456190d950557898a59f444bd86f91db1f855c4a21cf86241090d62b9bf28e743a6aade85f484c3b464e6e90b43d6e75b30c6c3b74994498d40a683db05218ca6d1ae681d346d2045062d2098a444a16506c1a18274c9c3d82a6738d9e02551f37fa60be5c3aad620d862605e401f66161cfae08a61b22a1ad57c9b040879b0c580cce574a6f420d356275f368f867dd7d9a7e54f3428233a11ea3b37df205ea7ed636ac5c7cc7fb500d98683f37d7afee580654d9654cf51d6956fb4119e2642a5a2a94c6218eba6b4139cdb9a64eb2425d8bff3039cb9a4ce3029d8ad7a641a42a6651df498b0400aed0ea5895d0eb6e002559bc23280f00e864118f534368d22ad7abd369f9678b044eb4156432346fabed328e5c5aad06a792c4b8b5b85256b24dee75e19c160d197e8a9a99723eb638eb18e12309664ec189030b7f99fee34a000d454a5bca16e07908842e5091e4790d14aba30e9be3a57c22204ed0f67f95f7a6bbe9375c920dc28a112aa7e0e4e955937ab1655307f014d07cdd7c3a8fdd9b5622ddb9ead17131f9ca46bfa35b4802fab25d1de65fe476736fc0b1908898b35260cf598a8748b85f2237f85dc0cc86c14c45abf9be826e6541e8e5916b4d5375c870a6e1cb807a857bb62abe429ced65acd099a76d7c38d7cfeeb19aae095f00006608e942c6ed5912a691d685a13d6625fad387aa6d5f852c4856c973a40859f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000969efc63dd588a7230ce08efcfeea534f5a0eb005480ad1d169c386e476715238526e936fea7136e2d8aed60de31cc91dae4e764ce5f93624fa7f72b87562fb6ad8996b5e41fd478af0af8338a7fd9aa250efd2f2d20364e8a88a8642e8e38f38583abf8d3be97f14c3ede66ebf8ebc84385cae646cded8c5ce8f06910ba7fec05d828446d558d6fed766fba347da2e84da247c34266aa31c328804f4e3aaf6acbb0ad50feeccec00d20b3610785b9f1ba06a0badfb42a8f43de3f7bac36057ee0b4d2a15db040a8903f767f7352995c8fc3e06ed1b1322587eee5b31806192e04b09a7b433d08cb2a340942cb75c51e0f8409f907f69c5f8dc316a227942edf7a458974fda76c255ff4f1a85a352cd2cd2a21507e0f37451060d31d0847528b3ed5da3e7168cbd0302f1b03842e63b3dec6fb37357e37fc3cc26721f290726a47ab3d4dd8fd1778fe5133726c240e7b3e398f3d809c6c469680b9efd25dbe890d6936b76a52f97aef3f93872b76506a95685eecdcbce203400d182252471b99b7f4c6ced4cac8faca7682d0df07bc5904aae042479855098cbc41534f0ef17f38f1bc8c272cf72c1ac4a5564dd132130ee676e7d7ec3cabb4e85ac81945c87de08ec60ced3fa0ab3e83c18ae493a851434bfa2c4968b42acccf3609539c62a4e01f8bc159362e15ee91d8aa399d8bd8d67ba1e8fd646eebb4583812293406b05ba5be2b1df9620e6fe3daf8cebd9652bb04494b899f407c7d9ed1c4e77ffade24abe56ad597bd438928e05b0363d6d2685d34d6b51d71012844415c46f13181b146a3af25ae4e8853cc7c7ef6387306c45180a6ef9e97abe1e7d5e10115752c3071b6a213367e8b1a3d1c3703cc1840735315623901d772c61d55ef8c47db10f0eb7582d7a043018dc1363e93f315dd984b8002ea7bf5bed38d3f273276ca577cf99a635cb6ed9d6525520793405be27c86e6effeabb1e5f84a0076bd151cafc59853424de4b3460c673b0820d76e15ee47b6505d2d5c179db92a44042f3631c646d350ea9721b8984660a76018dca5c6bb1223cd03cc844dc9371d32549d9d645f75d2683fdad1df6434bbe43200e506ed2a815fab511172c70f99a85fa3970433e8955b2f9389f23c10141b5779a23b8671eae8b91991b78f635fbe8e627d3e79d91fd1e6e90699640ba3ae8d7e4cf5145f1259cc76ae50b1fa150d8338a9450a5b6b90eec9c94318bc78c9c7715a3eb215aee6443540d211a0556813529023e5a581623cd6d19bef0705a5f69aad4833a57c308144e92899ac5683147cdbd279d5c3a55bbc5e8f8e26a158a3e42f8c5b858909b024b4ba4069e26de66460ff4a7dc92bd54ac244007b6ac6ce07a31a2af3323cb55f07b8f480d279308fe10f2ddb001da6c4aa132b988ad03fb63e0eb06544571f5505cf377a81153d6fbd4fa2b7562074cfaf587ccf28dac84afa58809c0b296e0d2594d3582c28596f5af7500e143be7b49c63d04f49bbfbdf60b024daba5533f945ba90659758e06984921efeef79604059eb808c9fe1bf9bc5351a406fbba7f5d8fc9f891488e537db14b216a0535c9ff7bf8d5c68a2453a8a48e58fa7bf6eb76448d6d0bd05bd4628c4b852a236a11bec0f67118f1267ca42647f6f2303509094c9a7f3a07b2724abd2d9b56b71fa7ac6cdde456ec209be76c419855a5151ec9ebf0e0cf1b86f4e8e81b8173960f8d1c8affed1ac7b818af8e3bc092e2b209d693e80b11ec7da39ca93223e1b47c6127e8ad40a78bdb0ecbfa1f39c84cb9ecdf960abb39884627bc4105c53ee7bca4802b92af60241420cbb36c407f46cc2e953d7e3503cc82287a8d68d0e673e212173d80a12257add5256652188c00590dadcfb7dbb6b35507b853ea5fad4f52e02230cb3d3bbdfc43eb74780583e8dbb851e0257117f4a39a6676586216220c1ca21de16cdfe6e1cc99ea7c989916ad2fed4a8373cfcff02207529bffcb7b7601317450bf430bac9ce111b0fba8d7de6627f863078d8e6286b2d34856426ea90ffd58705444d0dc12d4feead0ffe543811e1ef306f40939922563832d06e6dea7109087ac051a361ea9e755856fd4e51388bc7c40c63e0953c8413ab0cbff70c466e15de5b089d095e8ee8a64e929d26ca3b71ef0b2360aecdfa89284cce08c666f4e0146362f0bb84b87a49fcf2324ebb96dd941f00e2586f7246436eb66b1e04af84482d8ecd2bc8ef9955cbec62afdd754a7f235c7f3c41cd0b36a9024d426b7388d3c33a5a6e858846c0fb0d88ba5798c923f9b43d14a6661c65092d5c5ec0f97d84784fa336ae6ef57c7a5d04804b96d19849ff9074724a5faca538e32c6efaa5209317543159272ce50454fe1e7d068c8f5ff3797a66d5f87758627ab5d40ebe1fb7ce9d69287ae7a5f349a5daabd8a8e7778baa26da0eb237034a3366448280237a165cbb303be6b33c0f11c1e56c50a84384a0f6878f2a99b14cd3b6820abd27d2011e0c37f8439bede65747038a5ff7f00daeda094331523cdb7e10f1063b64a584d3e9f0655268f89dbef3ea3fa4c6e54feebf8f0046c6c811f0767cf6fcc9b3497db05582774047a8dcff6a0c1b5188076e64a9d5693195075f2a05e507a5a523eee4537079f9e5e79210e4af056d6624d45a0eba553ca9bc92171451970102cab57dcd89acebbd7025008325c61145264f42e4d14a76e5c2f1c129d4c054da00501081617d1a27012a6e160750dba73becb5dc05105bfde1f1d0cdc837355844b291b09015fd610628513c1c86ead373730b99fcd4a552fba07163ce9cf6a3d3ac0525593f0648256e8b33fbcf92af58ce26d0f036e11230879dbb789507bceefd2960ea320236a224ea74dd2aaac541664fa3ea9430d4fb09c878169a8af1e7fd4be5e7926cb0b6a352b25f452454474107286edaa145c0a0573361522eacb618dd9c8b32bd1a8a5923f4c698cca0139dc640c1d5d557ce889bb69ce32d85853dfbb0f34da2cf18cc79472906b67f6bacbf287f31de0b9e7a01a356ec9b64653cb922501ea1eda940089ba0f293b667f482e92438805cd6851776cea0920cdefc4062c9b4e51f5aa1d7ff909cc2608b6f28ccf28d574bf67ce80d4ddcce28f2ade0162cb66894b5b2da0eb975cd95ee7fe72fda2736616c8b571fac94bf8c64acd1642d9431118f08a62328d99b2b9d90bbc915db764c4935951a59c369c72060cd9f4273bdca0c295294008c0ac3a149e8ca5e8bf21042f5f21c067147f3bb52b13975026a9df7246afb1d053670982ab316509f2850342913e1322758ed89da02dd79126726b1c5566c1831ccb1d62b3e271875e62cde0df0715d404f95f580b63923f362d416f83fe5ad98eed584717fbc2cb7d1b00101200f4eb4ca50000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 72","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39f0c7a03f3be72e73dbaeab0a54ade85140fe7754943a2721f0202a0c278cb34174408aadd077a2ab3289f1a6081a4dd54bd906490059740e03a35154103702a2851ba52a24d888bf01c2e3e2733a481ab6d2eb644c191d776db6ae1d4789a0c3bbb94b360585d5fb7ace6cea2e83bd5afb37a35abd4e20c2b2cd216a5eb1d3395f6cbadaccab732fe1365189ccd531caa3d00eaa053487c2e76e7984c8c9bed32cd3e4c56a1daac5c738d4bfbc8dde60dae08a3bf0f4775abafa8f9681a8adf84ab444752520c6c9e650bdb46cfc8d8e9234bedc25907e63c4d2749c67a272ab64c65d8a87dacd879587377d6f5ce20fd63049c672244ece2da79a2fb257f36f87821cc4b160d2af9b2265ebc6aacfba8cb74e2ca9bb61b95094f9a68d8785dfaf4aa373e59078b8eef9ad369d1d0611f88aed228cd38cfb6712060f5682aaef8eae5bceb8f2e2dc6d0cc63f039f4d3730753f75a29e33e6be5093a71952105622731629b8ef66a3dfff16151d2c9fe72578321bd779c38ab29c5620c7a01ecd2cbdc77f6afc163a47eee2ea53aa274c93b7bd3f8a2ca8ad6e0b76fb9b3995766a56eb10080b099fd2b5a4274b2e90d6226bd28f3e59e179a4e7eab3f2737a040d8afaa1ae1b274b313d236fd7a5247d28169d146524aac66e2f7cd12970932cc1189cba22a26e4fe171f55198067f2a53a37a3e7e41926d32bce5de688679fd8cd33f36fcc69b92048f589ffb929b8892cf33f17fcbccb4c39d86d9a09d496c6db19a3d99f189c5b93f1a5d43183b91f207210bdb6c53ad4f9c3f3ee0a7bc0f4cda658aa24cd9aaf6a5297a910d4e3e1461292a24ba6d0fd4b9949a23931d89ff7677d4ffa107ecdaa32fc4164990a821bc19e91857712a1a0721827d92343d9c751458738a9d90247671b7400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381091fdd8432929a5f83b2858bd46cc94d8ea52aac9f23a12424b532ed32b33ac0fb45588f37f8a49368628ba816214917e9f041d40c241598aa04e44282134ab31f890189fc5139b712de4795aca4a8d1ffd63ccbcfb9e230e597ec27b4a88cc05b00588f00a500db56db39d02e7bb8127760b0abe609147c67fed026e1cc142ee20f3696ed7b802d5be9058d8b207caa82e70b958026ead7eb965109f0e5871307ff0bcc8817d68f5b34c90359cf23805bc63ff309418535e9ac95eacf4023ae66316ed8eb4815dfe6bae3ed4074b3f84690a5be5c2e953961496df457f610a7dc6ab9e6985117198a4a8f18a5518865952474d2c6d16a64f14ba3d88f5bc954b85700911ce6eae341469e46eef7aa0a1f2948f169f756efc30819584a3b0390a6ca9f28f109b06adc37a42b2fba964ea67947215bbca5f31197443f4d74bc189089c076408bd46587938f611269156ab864815369dc56363cd68b51bdac396bed286a412880185163718fdae1bf393647dd16ab970910f5ef96ce583e94a88154ff3a5053170721316165b9f4a04bdc61a6a6896597d915dc10a70d81e827fe94771adfb7bd3e2aca6fe35c4969fff19a6f7197bdd69bf6c328a5fc1e12664f14b43dd813cc6c07bc8a892a9e24d32cbafa018dacf386849612dad8b61fac9aeb4d1e596430b3e8df930cba927e32cdc0ea9d467ae598d9d42be9062b6c54974d4acb55424df99309a250dcac7d5804ec12f927a059853b05f8d0bd07cdbfe777c8d34e8429d945410e9d3a4239e29bfb6a8978f062da07b9102b15546dd1470074b0fe4defad45360443220855050a10a556a42e0812648c4ed718351c53c30e336ba8535ba0950aae2a24e7ca9c5a456a62b1a3e0668a8dd792fdd5a52032bab6fa102f0c1aa234159803a2447fa81a5ba917d6d6f343049a8026df5986c58c975eaf297857b53646e246d99cd127b192f97501fb5d948217fcd96d3b1200c951e3d677811bc5ac04acabf4a0a821e9616f21c479802ae52978adc56c44f59f35369b5dd5e01002e0a9cbcb4b6fe80b7993690ebe50ada4921c3543ed7ec46b12488894abaaab1f655a8ee3134212ad5012a62a88870784f84e436141771fa10b77d2911b13257a04faea6b4e6897c968e89a90f48e786012ae85a56e0afa4f0457642db3c5dab5b74acbc3056d8cb9e1aae62d201b47ec86531d02e13db5c224895af18b0982783c6b7c73f2fc0274eb14b195bb24cac1bf93f5e014aa980100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000098aacb414eb55ae5e49107bd0ac5975544f83104f7264495ae0bf0a6d9594c422c16b99469eccdfe8b8000875b469309891ea42586a615d146de64fe59277a61631b2c7f7379cd52fab3871bade120ee9558d1479a91925634578cf14d35df3b5672f8b5f9f956fa9f7489d6e37e207fe556017736f6b147a8cf664d0e0521d94737e18188a1b7c30296ccc9067e7b55d6e0f2fbd875f42fefecac49510e324968b07372deb10a31c585457e0c48879ce44bc78898ecefac7bcee90d0f8925df2b52d5ac81692e0160f8fd5808645498428260f592e29bb90fcb07d0424ec79fb081840cb827caa4a9d562183d10ee41d281e26ce3ec0069c83e1e446ef82e2e30debe3f409e0a9e6d1550e224db15dbdda44341e4ed6f8b8984716ca87233197528547d090058607ca141424a13145f1e896555288c5e2877ab3b51c7f9248d2d56a8521975bc4eae3d009988cbd73c66931bada0725fb8a3448d43e0c7364e9494fc4e295a700e79972e1ffd626d1cbe0199917851638b192ef9f5c03223f2bbd67eb59a5e8baec3db40616938274201dea1ae640f6ee7e047cc4c13f80dc65e3fcb5c62386015f4ef1bfec561e121f9bfa9b2075bc1c4730503fdd5debce8a535eca01b9d5b021c290854b5f3d49effb263dda34c4e96aeae9e71a686c009b205994b46cfdf1f76727ca67d415b9d21d54312cdc6a8ed0aeab96b580d0b419e2058e5d843c17c96d156549962f81c266233ed2b795fac40b1992b626457f211f08106ad86f5702b9deb9323a0970ad86125eca836e0a3d6ccbc380d474049bd96ea246b8bd9542793a66e15b319aece6bee17adbba7db337d25f8f642774030a2ff969cb5671f59901cb109e661e55fd5e75eb2a96dc37fec76a82eb89d020b4916271cfb0cb3342494fdb62ea0d253fb8ff2e91357b33d96d41530b8b5e9550fe9b3f9f34fd5a2a1a6a8beb93ccc322622f3b5e8487de19af57cbd1481ace02779ad928b17a9b05cbeb722c783b088b5912c2d67ce5073f1801c23170deb1eb6ddffc4c33dd25f94f4fbe59d704e478fb49dd2142801c37ed8f539ec1782ebd2f3253bbe19c5a048b9ef41824a811119f3a6ad2a0d4b77338e001358c61a9794572b0c46eb1e0e575d4da141a415829ba8712b791b625b1b0ea840ee745d9ffe1e99efd782ba25859351f443654995102cbefad7e59d03c9a502ed7b77144d0566e4bfac086a7dea356cb9e5ac02dbf7e81d6ceed4a33da8d801d61bab5c01f259ee3a99ff7f6d7bf8f2160c4bc3f890736074b000c4c58fa4615880f93fad43d5657c76045d7c414e6b85f63aac91f04a616184e04ff9aad513ba767215fb0331a369d36c0ae9b1ec1268f1d0b43c42b786db23dd66465b3af17ffc68c67964c2fc9e41eabc45db68cd2c3d95b8bec787d994bb8e9cf1dd7d4c563fca5d80b3f1fe8e3c7bfb7d171f5b9023bfbcc0cf4371b63c856edbda154b4313c47983f4027f9e61e86da1e8cd787e3e6b50e1dfc9201b9ab92059f8b6d1bf7856cd55c5b1d6c4e6ebf818d481c56f66c79444f5a6544a64a7d78ead33eb805a6ac4310cd46a2331e707b9b0950ca12092402d68c1cc5c3f269dfdb13ab34b97eab50b0745be72bb0fd2d73bea5dd37802393b635e42a0def8544a96e7f40a8d9d06b64e38dc406bd59ac5c4e218591d20b8dba2125978096517ec5c03f9bc6f96cb255e216ef82d7c7c873029f9e1d98ebc0d8e1312b84b8d02e8d680aa56a506c8668b5b9c56d04cf68e37c7cb1b9377c867240cd42fc7fbde0ac44e3dccfd3f877c9923ae9cece0cbdab00ca530f434a33f1c939fb88adef4d12acbd8b2b5a139a3fb776d8223a9846465c0372b8c3233fb5280e936bbe9fd49058961463a4419d939f4f1fea705eb63114f0a3533638dc4d3efd620147770ad877e2354299cec6e5c18924e78dd661697adf89a77c7365522d3e8fc0855187139f7e43e9a0629ee321b2cbd9f007b05c22eff56fe48045686b36c5bac2267f37a2e3d4e03e19b1e422acea31c2e9f3e7541976d4e2fa03119df9c4cc2d5418f0fc7a467cd98e290695b9530b91d5df8c626c7236a5c0fba73578b9a47491ca0ad26a144b0f23ec23d2c5b2daa03bf40130f14b9a427cdff1f232c9cf02426228c570cf1fa7c00a773bc0d70858588542bbf8f581540870897bfac8387cbba3416a846cf9f4f5d3f9dcedd080cc0de9f71b93828b835430898e82896cd3f30fe2af8349db294fb2a8ffc0848692a0b9e8a66ebbfc0f896f8d03e3c6a0c27e0f2177b85a2f6fe31e8aaf14ea5c1fdc54e80cde47ae27a161264680107023cffa961e913c4e6af96c0be37ad859c334cdb8bbeecb5443662739d027ef1b9535a5a46e2169933e419454025623fd6779f54c622ef81ab9289b50758ea34f868ec85aee589b08962b85cf537bc733f62aafa95fd81a60d5c2e38d6ea0df7d1390bc5050e2463e3e2e3a769de2a94abdedfa0ed67cc0ffafc5a05a3b0fd37bbe6967bed8debf02a42cdc80bdc62158e184fdb6672f7947505e2c0a6c7762b1145c4baf30e3d32434d22707044dc99d2cf2d38f15c43abc8632382bbbc9e0f106565906f7d4948d30fb19edcc3748100397f71e1548e58a5a01876d0a12dcc80000224221c4abd98a5022506d24bf4d9b9108991ad3421d4ab9cc393dcb8d744f97822f95cbb2640e73e401f044fe20253acb8b32a75feda640e190454bab695a23b14ae3ef60b00491ab22f622daa89b6b2e6d18e735672fe0eb2de269e4e386c926e23b865e1ba22dda688293de144102f7030fde6df653e4106c08c2467ad7c54d1df0dc5981004876c6baa8720f70942700a154a376c8d45dae1be74910148ee3f2733e591e1965fe763b58c8b28af25e9b3c633abd83f1c0a4f68da2e0b85083bf97d4e919340c0437a604416c4f629b33039bbf2a1f561548321780411d2e8ac0edae76fc3a19f3c84c3be902a1e84fdf69b11a12dc8b78ef257b5fbb5d923ffd548451a52c6a3af31c70266ae8a957b2bd72a51a034a2921b8e19321108ac303b0d2e269d032c3db13f21d558c82ba4158962f2210e1c5fdd96c98d6639aa844f34e40c1b9c909cc6af1e97a8dc83b78c72b30b7ae400f44ca60af37770b3d9147f7d6f5a327f34df7cb8891e71d41d723cb18e0dd324e5cd22ae0d9f2b1d2bfced0288b7aa73af4fe0a8181ba1aa7eae966d0a240e10fe5735d98326a106d16dc49f3fdb19d3a8449c56a74153655600e4c9e38d302c6d4080017d93c628388df94860329baa289efa4587f079c6f03fa03c54540a0ab4b067ee46a5a346f2fbbff6570ed0166a55c258eabd62ad90f060fade84e8fac799f7928285f58557a72e055b535d00bd9a4880d10c05c07cfe7a6feadfcded880521803e339f6eae3ff28a0a471a003358f952320f41a0aef9d2800000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 73","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039784915427e145c07decbb355b862fd531a06b7cf66c8330f6b1b2d7e356799595d5dc2f38b854f26c5228b724878ddb5470f1b4a24831b23c09d13a59ddbd68e210e9a4799a4434b23c66388bb7b8a214e616863e3fd78af225db9b0d14b14efa29fe7bd1b4fdc40cc6bbd6cf25fdafeed14b6d7632bb6796a42afd1d91a9258eeb52abc6d68614ac23ced29399b1d1aa55abf41cbe2b0488aee8d0878fb323725d4abf5b5d1ac59124df1b173af84638d1e610577d13d532e719ef8244d12208cc67de43274df8d313fc3ed8c3967a8fd4a036a6becc823e9c46158661934dcafaf7fb70db127882e9e4480b64c824b8d20b1874bacf1aff44453ddad89257c850730b8408c230265e1e86c1a917a70d4ed16594d6e21ac21b885a0c7c52a85642bb6e3225225e6cc6a90766b851c771307c245d76139ec4f4ae3ad944befe80a7506771963ce543648268e3bdbde34bb65e3ab91a44c37cb2f810d85198c4bcad15ca526871bcba462b407a38ba6d7c223b508b1589bf8922aa50e43d9c1cfef6d8be4e46d0d03758a496f698d164d109cb08831189b2a390cd485c6e65d1567717490b659271fcdf5af450c8936c93eb9b46e5110ed2491d98ec92762c8709d6f1e8a0dcc99e560f8ac3ea1d8a1201936ca22e4b23632e30bbf4af39b32b7675fe6652ff7225f30bf4c9a730dee124ab5e1b317c555a24adceb420ad1cff1fbd3e73d5bb852ade331934571e70e10e732827c7ad6378f0ca9d4102876b5043fb979523b415063589633654a751dd8a37cdd6ff4354abef773e4705cbf2e790fb959f8644799287be11e45a5587f5eff23e6fd5bb3592d9b97b3e0d32d6de7672895633baaf9cd78c979b74399fcc29245a1066b3bae21f7feac39d29eb6f6ec2a2dfcae7421d504eef9ce6d166800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109ac5d0bd6dfc9f64249f32ac8a4f542287f851cd4849d461ffa85cd4022181627b6892b38ee41c27da98e096d5c34b6adab76a9f5c9806ed38c583ca6e1ac160350f1c7d085e51729c6357ce8869612847891eb6759ed2c38b90afe0d70654ab853b11941c242609b54b9b439714d09c70b70c314cec4d755f2cc9b4713908f0543e44659545a7192a1ec48659b910b86f65a76b3805b2b0cc8800dd49951d9292d2e0514e6ea56502ea5bfa1aa43d4b771e800e6db3e08f53dd0a6e43f6b500ba5ed540d9ddda0369a41656201bfb97f64731608ed86f991cf70fa111002437b9caafac79fca9eac3d170b32d95d72169369f4ea6948d55ff015ec0870469f2724ddd42b7a32f78b8f5db0f2ed8357d6a530ca021a83ace3a7606f4b22118832a959d2876c7b413d0d92e9085c07661e15e72822a27203f97fc0db80fe18100ad15fa1ad0ff43f40635348adeb94d7139256f24ab951e14b75ee096520ff66226095b9a02e11f2ca3337016ba2bc3a13226d56263c08c6eddfcd78642e2899490a64f092db3ecd5104a0e9f4c74c6800de5625c71bfb30b11295e583ea956ad5693b9d046a21b3c16449f68928eb109a93296add45d0b1627a4478834a160c865eb46672d3ef0d4425ae17e00a38169dfc931c266605c68ec0068cd0437959e787a5ea861853ea9b8cb41b9203d1fe9bec562518b9769fb222e2a1695650c8816e71d6cb2a23aa39e860ae61888eb8e12a32c4cb2859933851a324b10d1dab9467c520ea43e9d781e06b7a8d07dde6ca2e3967ab58576f80617ec0680398a3d96ffaff14edbab64210a8ab936d5e423b74e8da482102b33a58c291b68ac94325db663ea132e40f5f674ead74ef4a9104d8c7925d8053a6aa095858238b1f49857a6225596aa523f3f001906530a3d022ceb307cac6c965cb2c1e8d786a71cf88398af1a6c6c0986c0c26b0066b6738b4bab37569625c3d7ea178aba774667ee35a1f9f8e7e66d882d0a3b8c1737bf08840a68135b1d58ecba13dd554d0d2908f9c9e3912245789416378af256c9879ffa3cc1eb6bf49c30a2ce519467517a2cf9cc77c74a6a05210fa9160ea1a7eddd51759fc866e28a043d97c00d482683ddd3ec1a7e53ab4ed4b6a2264f716068d75c554dd9c7e7272819602b5d886456ed0e63e19b15a0c86f2168232b87297462b692b59c10063b64a62b2fa5d542c687a855c9588b864bd903e81534ea5257707d1764aae8023545a1a6b0470395d46430000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009ab5f7522ce6bd0ce6321c27b9eaa6f572616201f283c5ec171d0ba47662c2320897805e1551ed438f3fcbdaf9de6f3a19dc16fe9c167a65b6e52bcf512c919561b548496a4a80af7ce25458a62eae92ebf677872482d8647c30c12bb1f080c6b9a56560d64fab73db17487bbb007c66661ea9dda14601ab27a100ef4cf4b7447e51418651c03211f8fb884be91f3980fe13e00ea4ecfe6d54882059a436c90bcad80e4101cc6c0754417545f2d167629f80a3c5ffe45c00ab2baf0494d6c065872b03a987a5ee818b3ef11e47fe1747f49e2db6a14410f0b1f9610a2d6114395ef6ebb231fdf71d595cc1171db9c89d6cf202e42d4fb968ab8105fddb2aacb15fab8014b534cf468d77ecde2072623b7002620b7ac3e78b62ad673feef9f8e97e91acdab171fd415b2d15605dde00d074a770e36f2218f7130f13e91fa4c88deea7e854bcaa01b8458d40625a33e982f0955b83080a926ec240e31f0d9bf477ee3a016e146a3909683410d4d09ecdf32eaef580402f0d416dfc082cf1362e8b79158bd57739aee56dc41a549e534c7ccf3620c7d7d95b92994a747d5efb8ec43cfa8189baa9b75fd54694e512fca388b71a5b9ea591ae9cfa34183de59d284ab16b2effa4b26a24a0e615b38b83088a9827eeb5c29b419bc061b033e0e3fc809afdd3de948412677e0bb5136854532639f3ccb176d54ea1961b5c527ef66f4b3286a583e86208aeeb8ed07d9e6bf1beb33995f76ca480039a6130775895f19e3cd4873abe3bf2fa9de81bf0cb04575dd6ae282720b152cf0ec6a4a04016db0f3543d8272ae56b1152b02eaf22131420cb194021f97060d5ce52eb21b57cc93964dd21344786e3888617152d2abd829799ce47d20158aa93f7da85ca6146c5bb94b512da053c35bfa8840ca43f6509a1477603fd50f5e4f9a7cf8d2369156989ad638d35d345bdc859c52688211bf7ef3f4ad4944657289406bf01dcbb49d560a11840ef35dbc0c7f9c96dbea76300cf61997a87d70f5ff8c51aeca2cf0680b6fe8c4025e1e25b62103d248cdee335f4fcd67597103362003206c507970ea6d78cff4b68b44244019152dbf812675cf667e5e13c8596eb6fea3903bfb25ed08f902722a37f8e460e37a03a2d6adbdf79da20052de658390484b83bbab28d039a303d7376bf555181680b7966c798a1c6cb215257e37739de7b9706cd1cf3ab031f68c82d6ecfa507c104115040744d74a40c49245215639d0cf4a5a7a10098e9ce3564ac3c44f0683ae9d3094784d354db1af439bddf63d5cca668d8180264efeceeac0be1b8e1c6418e45f9ed6c779ecf169143b034cd9f332989d445c83a8786398c507b9171b4d95728575539cbb29c5b804268d88f2b39af1f9572b8daa9feeef69c4a77dc64bf2dbb5e57f8b33ab151769b2d00010d67a2d6f188d6d5b35e5e1873fe2b327e42afb8885a842d26c246f7c18e6bcdd6fa49b300c65a3822121e95004928104017cbce2ab95acadb9802bf4bb049b8e96468353d649654c6f69d774380a5a387d6414dc3000540bab6eccbaa088c1068ccef20036e5c8342fd512f55e6794bf85fe15721d99a1bfeedc218617a940c8c25d4dfafec677d2a719b2cddcd302294b7fa41aeab5606f859cc0d638ac94b99ac3ea48c687d278eebeb396dc5bf2d2e89e880f76b533fa54efd30d8ee38b34dc5f8ae62c637e9a7e85d99e011f62d261ab4d3dceb98a8972d3482cf817eff476b873ac56963bd60183b359713385ba82f6e24be2d6cfea6dbb4ad2e1b5b790ee54d23f64e740502e887629b346fc8fccc3338d0f2921131b84590b32c7cb82cba8bb3b81ef7bc5cb12f0aa0b3c6a5b2878dc4f868057c68460c71d40d4263ac5c8b8317d2d0b63403c7549439a9ef227268372ec3a54cf8ee97714bc4b55007f92b1a32238659ec1ee27d6f2987ab06fee84c3afdfa73240963f076a955bf3c19410e1da6a19b3ea3ae2dd8766082d3295d35436597783dafdadb905465d05fc21fa8ac2737a52fa8aaefbd2ed83f12545c1fa3198ff225d37070694c9392738e89467edb2da3cd1734ce398e32bcb1fea2e4fe1260a2d9f9edc3607a8ac8a51d5da36e99b31903025e0cb157fd2ff5b51c9191cc16a9ccb870b4060cfb0fd900aef62738a58c5726f5164417f084ef14fc0953e3c6036b818c21ca3476b8cc5f8ebaace257a0315031a03e64e7f749b9df99bb56ceebbaa4333bc7270edee90fa2715bddc38d44898a41998b2374b6ee3b8524d3a385c03868ee9479355092c4d20ec32deb51497f4ff34ae7e7ea4828c288f46e5148de28a8c660ee132e5b5489833dc66205ec968b60dab96c2a4452a7019bba9fe3d19d5829129e2a9c75c39416ac8695145f2b62eb9468198cbd48d7670ddc6af2f99f77e7acd01a34ea8e0e974206fbc22656867d09807b980563e06a559b0c3a7e6f43cf8db75b18c0f90c12ff3bd43abce7df75d17e631c08c974322010648fe2e2bc940e6510fb8835df8384eff3fe6a264687256c6bc0a5f9d2ddf208171db55c4446b03cf27796bc77e3c68d8f1252be21877d7c53747404420302ca5ae1ab57e43b158be8b707360a2f59d6a473f98b816fde2ccedd92385202c419278e8b840dba4c05e9bb65f68ae2a635a29110329e8c0c02f6fb5eee41ed225051ee975f92da52f93eb1fd7c0a098f6d1421701537298651313514ad31cb333e9c5da719bba95e73878ba41f9e2512862a80602aa2de1e1d086576531330cc7bb8f0cec38050b3cfae5c8b1d6cb849a579f2294f8ce80fde5405bfa3e6ecb01d5117203a4523591ac4030397de9ff81d5cc91af3002590f5854e852b88667638b2d052f2a7852425c8ec026e48d9ef5e73d1993d7f3fd7f704760562c36d2278c9ce131ec6aa444d7b2eaca3ee888d9b2ae122688dcb35455e7de31562ba618f1183308b30d07a5c34020546218101ad42ac5054d4703587ff60e860a60375fab12734912058d5b0b06430fabbfe0c0b43c22814f56dae9e2713325a31c682c13f008b9a3d4ffa8a454f0f64a9213ff2d557a4cbc64ec6e4eca0a976cd9f27497ba544dbaa3e2eca0f54c2634c719b9c3a2ce37bcc8158a880baa72780f8b1d3494f589e2af3044b4fdd86f4db2df0843ebd9f3518870f55488f41e234ce94e907a69d28bd83347702750db1ae2eb1454cdca37a8b5fc90091f548babf489e57c8919646e977274fc972088a522fff9f9306d2f0ed6c01ff92cae8440d7f3526b8c186d5b96942cb08032886051da2a9fe77e38beb18f4fb25f1152edf9d61347a00a844929976a327be46ffd3e2ee0b6ab1014294ec5d40cf7071c36b11127ff90720596c1b3065e7de8010aea469bb4f4ac5a6efd20591cefb7b94b2006d85ca475fee556f24cc41237c631b75eb594f8342deb4f976d73aa46563c1aa6d0b605a16152315626ba08807daa6025cf62b29176f3a85e4bca483effea7e5939000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 74","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000291398cfca6a83d89ce8414fef3d5473ed5eecde46df0db3b546eceb15847b861e058143f399a7f77f05dd240142bc99f48a21237269dad4698f1c7af491e0e7e89fce6ebe9f11244af7351c1002171871b63f94716e9b1c05d297218da5beb98b0c81609c8375ed496bea3ceeceaa4806720d8dae706109c3504704d78dbb1e3af10e3591dc0ccdc5f2366a1b368a2eb8ccd50a8597ebef0996bb95d79cccb9e5090fabc09763bbfad3edf23d3312411a2a089ac1511cdad6842275f339e2dce473841d8cb12858a7c65cf1250da9ecf264b88be1584f09275adf8666b1cc03ad7298a7a47190523a1aa671df1d34bf8b5e34ad536dbc405aee1a1b1867dba4fbeb0353aa51aa5fdd2d8932a4f77e4d89be716871a0d045e306348501a9ed7266b8fa8ae5c1b422e63a026d3655376fc5f69426b83a93791191cf5c8c93259e88200696e68dd8ed9ff411f68e28553928d1e622a3307cf00f9cdd5b792b6ba6ca8537a0a0e86ca16ddbc5d8279d8735949c67e7d8ebccc864836f849c25d86a78fe173a434546b1d773c8653a34cea1d00a813982a932010eaa72f6b81771cb5d511fac8b0d6d4f1ba6a1c2d37b0dd4fef9991058991fcd3497f9feff97dcd49f74625c86f263b8aa3a15062a14318c6bcc7d26c379a5648420d27c92261086c09306708990822a91506126b37cf6c4b90d9c5b625e7f99e608ce3a79f45f71068e395fdf0d52cbcba3c07a7b0dc7adad571f7d5226fc7e6e1354b6d6d77af188557e97aa124409ed7eff4c71246ab86fbee74a697059c73170af45a529469948d0492a1d3e023f9da5ebb81886922a826b53e9ce812433dcc5d104cdef93a5258d6696e819e6f2f1882c615ec877aa3062632487497087a512f5fcd276521148e6f5b435e4909ac20a631595c2b8fc96ba000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810981b9188444af3c52cc8143c950d18d68aadb4649db8a6505595160e358392d06da0b5fae09d902fdddf63829c746980fe15f84b45bf1476d582ab2ab30a047a52ce418576c7e3bac8cb2c45c1985a2e3a817866182262e10ff5202b4fdf40b91dc7fa6900ad88705a57ea1c1cbcb44e762687811185de09309ccb606c3a84b9065170b64934e54d5e580c5892638ef534454c750cef7a5829d693a1e62349bd4f1a1466ae0a40c91796daa31220cb82f745e413dcf37663acc10e1461b31a4e3211deb3ba9c401d62318e137adab583edd5cbc0e45d9fb635ab21a05662e5a356a8525854a68db7ef291e30196004ca00793cb96771ada7de9eeeaea7bc409a2f40d9e7b11f7a1da1c9797a4ad804e12a28dee2d357a5d9f6ae86eaa2f99974156dc55408fd28ed06e91ecd01997d1c417c0a361b41080ba8a16eb857d1893ec0df59c418975006e2a774ad90b87628c2cc673b50e49708438a831b5dd0e160d2381b264e6a03ed4d3d5266db96a7edb6609da54c402c3155e84b8d0c52ba3cacd789e0fa404e71aa4acb4387b180028084ba2d3cb341a2ae6825facf242ba5a928a5fba2688a2a2b94d2c7bf01e4b03942c88a93f54cb6cf34aadb4250f91c481f558807ce922717c77399ec5e259b85559829f58403140979c835d8139adebe32e46acdd754a56c59732acdc6ad0ae8b190a516122c04564b02162df580224f567d03798436195d2925a2d4faf7a6c12f5db0ab5a9fa406a28b81cdc4a22faac7482494ac0ecc22b35c055e84c9618a19d4ee9ad0a6c0c51ca984acc2539be8ef60225fdbf749f88dd19b8426e22153d967e05bcd4116a6b7f125ef7350614d8728e7f086316d949916ee80462d349728bd7e0a988335d8a101c0cc5132edcd4a0e3752d4e373b2de52178b24d081b27bf98da3f81124785407177b5060a045d62ba9b9ca2335ee61ff0bfcee2152c5de08a06872829c64868d6e02911a3aabf0b7f46b55e46a02ac8200186d218ce708e9243c8a9da3748988d6814ecc9aba88797ac508d41392909c947e0254983d99d0051907ae90731cca13224faf9cd2d9d4c5245127b6988174ab89491e97d5d8a3fba29de0c230503c76e292915d016f5cf577384c9963340a0b89ecd94327e52be32a44bb4d2232939ddd67bbeedca012cc5226e07fc31ee8898884f5e14fd5962e8ea9413da56943016cf00190595d05126832c0caac116d82856d4a92f95da2b86da92e5db986e56459654af240000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009cc9ffa507328b2129c9f05a22b81a597fd1b8c27d554b36fd3eb150bc5fa0c6ed967ec5be6f1e52d3bed1508dc3c841360020cfc2ca1b0713076251f2935efa8500573cb4634c78a1d0f87d994e8e2b0bd265a877023b54d9a33282c12397dc74caab07ac2efd140df907651bcd1b37cab2d03f77cc28872291f1cb28fd4bbb5331c2a18e02120bfd2d9ec0c8938a6d43681dc03527fc2bf59703b5160d8e25d08534eb5aa5cc9c10572257d9e4db29235683bfe1776a2d9edacfba1adaf66587bc451d32c524c7934556f94776f91cdda96d2e5caf91a39503d3a742dc5a0efef7c1a13666e200c5e3fd7652d200adef51fc5136281570b7832e0c6e7552972e43291f202e6f916c916dc3fa48858f3d92b1b7efd42de140d43648aedd7c7379d7a4b71751a3348b6bba3b0db71b4c99c41e085e5536a3f0d2bddaa88069249e21e2d9906191bbb5c8b45353de72e00270431847aeb4ff6230cebd1969a0fb68d6e302b78da39adf6c0e681117c8432e24820b9ebf38838545e95cf7aefcf1e9436cf48e87b6c5181cb418132c7bc050b9498720d7d534792e0585f05da2735b7e68fe35dec358da1bf1681f7f62329bedfea3d12bfb26ad9403f3ac1db96d828050f39dce4017b45c5dae4d7de9e9f687a9d7fad1ae0e7197184142f6818a63d5617be9d8d82334a12e68f2eef88a0da3a915de63629550d8a64df591eecdbd1b89eb40ae9f9d65815271693c85f2ca41bf45e4fa16ef8b17d945ec61e757c6c609d8afaee32b3ca628842db255b619f6562e656f6125fb27195ec82fbeb9c14330dab649cdb74f523f5a98244194581503356b5b7ec51e2b35ae889452d3457ead713c0715aa7382dcc510b16e771b3a5a91949faf5e29223c8f1f861bc3b4e77e095bb61aba00eb29c065d6f9da9b4413d61b2202547fb6e34671930ebcdce4c541b3e2dc90073867a47197e08c96f74ed81de5f10c37c062e8d82364d67eb185cd098cac1bc3c522e4fabdf2fbefb66b9ec6e848f732a737fa7b935ef2848c29b1fb94044996eef006e251bceb5be356f286f0fc85e5cba627b67398cbfd6c0f520c6f896353fe75ba323d8ecd9d3ed2997580e7e1e49eecd91982c5da650d6b128068b8d3d72c1ec4bf1fbf121ba96e1cf5f247f9fda7018cb609329b1c95e59e112c393c45ef7138905902227cd21a39ce30397ff017495bc98a968fb497e03de5843e64923683f2e402da63cc25ad0ba13b85e3e379b08deb39542c06a268bbf44990447190a1f8adf0d3ed9ed9917886210864cad84e7c4d1282c4d3bff9dc23e4fa68ef6b0480e76459d1b5e0a7cc0cfc17f59531c4c1cb1d416b7d009ab50173f706289dbb68201c305e39fefad87929ef933006598ce0f0242a2c60955ae487115b4c367a7e49488491a6f044fa8b7afd81f6da09d29d4befe1b3c9eafda4f17d22eaae0b2d1646906d1cee65614640b53479e23831c56ebe12b92997d5fea725d78ca75f4509eebd3df4f741d6b2770521be2ae63ca365fe1518cfdcd5088d58cdfb8d3dba76731f74760a47c9d619a31b7e318e957194ac5acc6867cf8c9c235043d5c09240f346fea840ae0bb16094883fc801da0befac64a021f6f871413249e9c7f5cca92f4eab5713b0f2cd6c950f34ba6fb1cfaad541bd5faea45ea5fb37258301a49d7bc4657e3e986d707213c0f836b030c21593f11518eae3a8a95a2efc8b9839e79cd8cb0e6de59d5a43ff8f81fd35392f0c0659b7679542136782d559897fbcc0129c22f43a30cfb27e899a8ca52453f5459a281d0cc21f902403a596c7f69cbf9a64d97b935ab384fbea5851d831e8420066826d7e11e34047d18cf08283be8f29a8a79b0f477c27bc41b8ea4aa010ecf8ece0d37389ff13e235a4526070f96f415d41af2e053fd4440ddffd69799456e7335cc6d9f4370008803f7babb6c58b6996dc5a52649e25463b5267c188e2dc39b3258636ed8689e5c02e00574988b3af881d30e9eb38ac51c1e00e1c0a411ecf37e314276221d7d8713f7a449e38371854ea26520addb58082287faa1f77fc04095499a3c3a331a38852a287b24040c1ccc054086964fb1ee2b328f3de21a986507cd20b4de4898dfd15045324b93fdf85e5392de0f32c3badd04784012e97cb9ba19472b0c20eb0a71c89149ebb601abaa4a853f2c75dd2622235ac30d97b9d7b1216089b9cc8e879660e40ebcd15203404a8decadc42114715f4d8a6a10511bacc4ddc23520445a95fa3945bc95878bff18728e64de8b7767cfbbaa21f3ef2d92f3d7dfda792bbe4e5b3381077658bfbef8db95b64f9f2a44917b38df6f9391118978544369c882b218e7a7a31afc3eb9a75a28095c4478dc81f9cfa127bb749cc53898409365170823d65a0b46bcfba0e47cc0c5f6ecbee09131f134edd254f4f58b50c486dada13195b1a35739420a45be6558401f64c3b6ac94b73397925c20545621c7ecdc7da9f71a755f84d27f2c6d8415d37f2bf1966a76845216e41764ab96dc2e14c12df3684f7683fdaf5ec771db7050f81a4b3e516c7d5c955201a18f436962476c1284531764a9397e0edbffa8c3699929daeaf968b4524bd98ee62f9a0db9cbf99fda80cc6c57a5ee1099b1eb29799a5b5bf5593cda26ce2c66dea3d40545465c1d21f5b9373556b9ed0ae30e90b836003ca83f78e29bd8d49550286dc2de6407860e9a9cc5eaf3e1b1c73fc2d248b81b1cc8f59dabfb5daade6f2a0b38e76d9e6d0125955d08de7f334a56a8f362cc5d883d56bf7babae6d9e425376d34a05ab863a0d9adf7c6fda574fa8dc60965e021532c25ed4d568412d4143fbf2c4ec2f230d08337a4e546e01f7c1bff4c97f2f27af400caa57bcf398aa5bffe155b0f29a085d5053dfbedc3423818de8fc597eeab2c1663d8c81c71cb876f73ac854286063a2e8bd8614d06b80f3bf56381179342143f4c89b8cefe9168b6a96f416dc617b9f544f9df65ca6f4f7a84a327909666b70cffe889c86aca706a0a1365e248d6b341a004a27d4ee344f03ce6e85d3573e272d48210df7c3178efb7bfbef7765d24754673c9eec14c7513fd8de6386b0829ef0980b826ec9c77c81d1e3b8caa65992db9c2f8dd691c520fa6f233afaaedbf287a57a9a66d2330f4636f02ea3148c4bcd2c8b114d48a1027fb3bd5008d732c427adedec9969aead451e166954fdc207c1a4ec409cac60e42383385187af44f136f91a8461e62eafe6fcadd1e491162e46cfbbadddb72e5b54b7c655cb9489e7f4f7e55c93d3ad50cf84e1f47a706fedf818a5246bc755d6d18ef18702f5a90ce51812a67227c5e5a051133576e9ebc18afa18c1b05c854d343727b25bb10e3b9a3645d789287858fa43734d66ad831e8646fe604286544238dc99acfe3c8285230fc784bb73360f72ed34795b1c46edbe32a346bfa7f534b500c6c9d3ec26ad7ed20d1500e3dedf141df3c2f92e981472f0010a48f25429329ae92cbbb918246f5a53212703c75dfa15d014801a830deb75baa360000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 75","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000290391b69c34c690b4af9f91f8c289b2a8bbe511df8eae492902aa4f7cf9b3e4cfbd80450d32a51affc2928a6bc50e68f49b3b277b5e5b251778de9a51fb61fab15413169be00d1b45a5ae2c8713c17668f30d1be514729cbace5557414b396f7b100c611f661ca347549f5af24d8b0e8b1b6d0c41035f5ec76dfce1f07e10b259cdd6d71cd8879a09054a0c871aff30cb561a5e8960c0a58265c5f7226b3f53890df376cce28c99b91271c45df4b51dbde39ca9761089cd1a3bff2cf69da6b49034055a3df75c2353a276c59091a34ca56806eda38b2fcab2e0d9e05d5c156e0ccf2aaf1d43c3389cc0f2e60e1d338e66bcae0422b195852222fcb8790d14bf5cdb53d8ee7c05228335df08ef90952c144eee093ed3c0eb5973b18389f1229e7294ea17b7a7be628a2e1055fd8f3c297a80d9fcc8e89f42cefdf9b5c11de776808a23ec2953e8a1f40c3342237ec55f48d2ebaeb2ce9ad4a7f81673ab8699f96b373ae41a63564a7ae6475919d73bf57c2747c0a0a13bda0c9a21ba43ccdf8343c4cbd718fc99ffc81b11ef6948c372d8fec8a5ee38f192751d1f4defd2743d20ad343c09e487d36679152a4b33d73671d3ec32cc24995a50cb6a132d62198e5f4183fcac682b1b7e692e5bdd898947d02c4119c82668a52a68e6fb540fc46912d532fbcad3130c7ef15f045946e2f0c7e4fd6be6117c53a325596b524e67e60ec68809b38d0d031714fe77b74d7d6b7194f22831bf0ccc7375e8ce99f5d0455cfaf23facbc44db122c3fd22af63975deb0fea40df6d9f64daed8acfa6813811596dad1e4df9b70fa6451c2ee79a2468e3d1be12c2ad573698c6ed2a3795f127bb38b8115a646af5293f12070f6e8b274eed9242e34d9ad938a89464172551cc9c899c9f2ead501c79863bb5a872986b8a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109ac1838684410af24692bb615d64f14fc804996812183ec4e994800ea987521260109f8ae5d8bdbf046765be00bfb4ba537a2c1248741c7e611e259b325209172eef8795025922775451b0580d06e25b878a5ceb738916328836c5f9d8a5e41fb18c68b20cc68f6573656f68e507c402e3b1977b947094375a450095e8a6d2f948faa13009b3015ff93a19d0726941798b489743342a28471dc06789860272f403c33e4b4caef89a5459c1f41f904d983f54b78d6d44b3044daa215d4c0a042ee0142105fb7e8d8548da380ace6aab1d49c173c047f647bc89eab36035264d4541b248808bde682a6553b1b5f228f8e04b4e6f21a1b84c4f6c1d2954f33d964a2941fcc5420ed834301d2733268ca16c1c50c4d8c1663237328600e21e047861bd08ae9a4245e8dccda5726cf66be76df86cd425a6e9a32852da10d300c2829dbedc11820710889226ab9beb20103825f310ebef38586c41f20ae33b2d6f69f109bb133e864340c8a13b01990720e51409325cc0df265e1b39a377822b9779da4f2212801465ad27a3940b06acf8c4f96e9a351184629b7b45fc0ef03573f3e0cf9566771a65c6ddbc6c3048d0858c60dd058a3bca7cb6742ba3386c6f5a7a4f40d4d9daade27408429c9c5be46606560f5436c9f4770dd1d61fe8163128dbf535b2e753a9520f20e231ab169a17221980fbbf6bba53bc5c845007351e0689464d428fb40dea26e3805f3c7e30aa86608100d47538de175f9dfaa124b4264c1ce1437519dfe312198184ef8ccb7251a1aab66910475e0aa567ea06387826c70fdeee7f9cfe9b41decfb2397690d4de16bfad7cc390af1a99542cca8a89f880723131ddc67f733a0a35a5e40f6248df14a3abcd679c9ca204413e475142b9810dd099a21c5527c95c3d54aeb365559e6e61a503b300ae36f0f7fbcd1c9d95bcbb77c6d7859c707c26b521a0b78c2e440715c065a0dd52029869b89418797a0ac0b2c13ce04e1ff60ed23e253fddb53a1240ca97444a70b67598080202a6ac3386f766a2973d36798b18c6b81e7203f0ccda7924f36a8f03bd48da7c9a7819df14a0eb65e6117b3ca15c23ee8aec48fe3dc17e97c2bf8c7e63191ca923d049d055812f7b6c15504e1b545cf2fe8801a729998039d45801b3649e04b10c28804f56e0d790542f0e04bedb71ddc5a6a571c901a59c6249c6c0f7da308ec0a0e54912245b89d095b9858637e4b718ae0da7774023fbc08cebad816fdbb02ee2bcbacbf0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009ede7e845902e852b331ef9923416e492c1641236e4e72408d800fd70774ba32b6b4be04b6e82237a247d26f9a33afc4745c16ce0554774c68b33cfc6e67ae34e42038fc6c324972642338daea75982c71720f1ec9542df94b38434da34a2003fabd9daea1950b7751da6c81aff7d03390f5d63455d417f5d12a510337a16197ebaf921b6a7a9a9a58f9696418eced6b27cb8efc8ecbd9b68714f721561af8553a0d84e30e009a8985d011cb994eeaaf88c76f7f3261b47fc174155c138db2eadb09a06073b211fc0d27113e8fea0da56e181cf532ba8207f5d80d6a30d8bacba540d49a81a0763a0467dba7883766ed6358e809261aa3d8b757c839b532f272c5767671a3a8bf3391b14f5e97bf2668a4e98847f1abfa21e2370870ddf24504f89b3db71e210c46d66ea7296d65c926e2c955d899ac830cd9d06808a68e9b3722b86e878cf21a5e5d41d7f3cd95d23a6344c259859735ae1a953ade13ca103692b33af90ed0345c7b038d938f8f494d90cbd3933b2a80fedc2be57960db23ad018bac63017a04fcc510553226cd86c74ab90e13c72a1be12e4d751dc670a98ec4f81e9f8954a693fc7175ba7e50d340ff7f15d568d0abded0bb1fc557b1e55971b4c4ce8cc1b4d9e239c73b1133c9e1672dee36a2d9527f315c21764648643d866b0e2ab6d2dee61d838bc5dac183fc511c4501b6e535ecc54f3edad6e8edbf0de7cb70bee861b2bff0d41bb87ffc0ebcaee9a6dfb98d31d35cfb6dc0442fc285ad0879e7b218b6e66453fe04207fe814c5f72e49406b48fcb1db145753dc2a2d3e9793594f7ef1a1a6339619e1040cde605648234a51b2f6774b31c7f9a77c2ce3b98819132bb725d288c65901f7001e05fe5326b6f701c337d41c8cf8748ff9c276ecd398c725c36c11857605f58c0b154dd9f3c1b4649ae677533eb0338b7475254e273b786c2fe7db4c13468caf0aa2aecd55dc1a5f868c8edffd8be8deec20a9faa621c4680f3eef4dfe4a79794fcbc5f8c56eedcc3e1963569a36525d4f6a5bdbba5d12966fd8a0fcc70783fd9f61613842f80d000c9281cbdf28c01c6f6aeac10df1ddcd0322e00c4e3cc801ef091d9c1b01e84dce725d57c800d38990251aa1d1206ad93a7dda40f27726d6a03d973150f7a88703724e314c0953d56da6eac442a70c2a08bc66bfa2b0ee11e185131e352d10dd714dde502097af0ad155aeeec2a6b93b149b75dbb898b2b3a7c5fef2f48d9b12a580f54c4eef3ff83a4f13f2f194af551d4800ae86aad6efc82ce460d325cbcfee3400ae939431ab4070d7a7cc005f270896051e32b1051e58941530e250f05af19ff416e65ce40655fda31d2e7a6158e07da08fa61afd5319b682de44afae146129a8b769c1708a5d3479b6c910b2ff0fc872a4a41aa8bf3ee16f80011d163b599d18501335a2be10cf117dda094fe01596c404c14580a7075d04ceef68bd8f813d7de6599f478f3de9ce60b294cb7ce5284a61e078939d08f3d4fd998add3b92532aa54e0c31087cf14bf4ec964ebaad53bd15d04e37948e94917dde181ee3bb2346335ffb403b000f5669019c5281d88a0e771176e49dd0ba22e719c0b731ec2aae9c898e74b2967bcbdce0d7d73057e004bd62269f4e7f3823dcc18cd6c551104b9b896b0ad138dde7c3d761138641bd3eff3df1552659fd97bdadfc59a05cbc622a4492a1b22cff72ac197d61a4c5a949aa9ac09d4c1112f4c1b1cae353c70278a21663e11f27e9ec66ecd4ad56f2179a3fcec37ac3a3f4b33c06bbbd4c8ce8e74825bbda3e58a2e2d928c2c6e6d886274bc0e2175ab03d8721c664fbd6455db2960e3aef0bb25afd3cb0bafb71a2bd18a89adaee00aadbc7e4ae70ed4b534aeeab88559194755f9656b43bc83e3952000d9e2295bf3391904218a015c786de0144868ee4aed203b261fe743b7168788a0680f7484792a3f64782b2b1ed9217b09ae9845dd71ed363f18e8aaecd51a4f5913aab33fea3fc5f1e37e0cd6333d2a8347cf45eb7c4ad967fe6fcfff3565743435ef09a646e75c7e968ecf4202a9b2c23aa8118a1683219b1155c2cabc95c696704f5b270c6d213332649363ae13ec811e9a1090d1603eff745e2fa83379dfc6da5efeced556e46a8a5ff1f2a5c0d911b95c20ec2465ad0c96ae7e16fc36143762bbc0734cf4d6134dcb0d739f7822470e0abf66a0ab15ce0d6096d3abba2ca4c81c1c68bdc252a8a4ba609b7c05ccd913ea56126f418fc0b06de8f76ef651f8085604c16e5910f3b8651ab78296b56b78326e41ac15774e442017fe5b291e5227ef5a4b78ccfa96d6921c8542a8a984bc87e2678903869c52c2568fee4e23ef3cc466ce270614e6472244a4294b31f9438f7e43437fc9c9c5f3efb0f4f0af2110a613661dc24a1c7f7a7f8cd14a943821f16f94bd874f1a32e305db4776cdf6633446724ccbb2488b1b06f0177819d53885127e6eb717c0d6718366a8b8a089aa6ab17cb2581a75ec748123b7d0383f3900efcff77d2e022e90aa41491117758221a0b149c8ebc23cc01c17b9fd39118dad413a391cfa0a5c614208060a61646c7cf1dfad4abc3a9cc5cd566db2ac8faf392c9d8e7da0f84b941d792a8493fbebad30d0daa0d683dcc1583f0c9019622eb6c92fbc475babc8b626319be2264ed873ac063f84b7f83688ac99d732a1e3fc12281bfb1e1e63d48bfbfca619bf4b95f899c50ad0f5fe4673347df2bbf2ca21bef49c7f8440d95a83299960f1e42b457addccce236946de80fd4862baf36387e041deaac3c9751ae345512bb1f423a3b4ca8d3a5e3796d289641d3424ff22670a46552ec68d7d095e8636441d777dbe2e9dbf6b5fede5318516c3886b943f6adf17d8b7cd40b20a48233c9fd981145b45a5cb8f6a88eaa36c270e93e1d876d7781bb92a1fd99727d8e0ae34c73398ab8781bb342f5aacf4081459ea5ec20c30cbb6122344c457f92b20448f78e1a2a291202003781ebda1747061c6ce1f8bf882fea4fb50bfe638685cd638eec15bc24252567025fc5c16ed1f5d98dd90c76e720ef7b4e25a20d262e339c5e5bb5a9cf051bf5fd1f63e93452a179277b57956821cdd901f1c01e634ae18485708a6ed8f592ae2ef3a9d54c9734ffbadc6f0b86d0398aece9374f9acafef38d4b97be9b932b9852f97aeec435311a67ae344ac1985738c72f52b3d8b71f64a916240477fddc5faf02f8224eb35d310fea03fd2c5933047355a438676d92eadf70df662d97c2f5e00cb293053699d51d302b78145c77ab03f34eaf170eda5215436faf0238a4b0d41d29f36052a5278c7d8af9a6ffc6e2b6ffc4c5d524f7640a7170957f3de2451ac75589ce328b61ea7179fd990da1698f5c73bb8639a4da2ad67d364db04771ca118c4055c25f1120a0643158c07cd22b375d5c1dfa26ffcda44921f41d4a504b2279dff03421cad19960f87c6b6dd8c29981cb66c9731f931e43b0d97c6ac9862e2cf711df0ded8e4d06f3957fff9085a95d9fcc95610fde22856b229a3121d8b81ee83dee4a6a9fa3fe8c75351574cb000bf7f3746ca1cc5414aeb23a200000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 76","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002913939216cc1160bb3d6ab3146a0bc9445007cc90026d8d8e182c4dc7215ad06bb97ddc10672b373461d9e3b7e36c9244bf71be734c2b02675a0e34b4af9f8ffc2987209b62eaf671106f01ec4e5c297d24f876edd47db666bbd07c20862dca4f8d2453926e08a88c7df34dad87ffb527fa3a57fa7dd88d92a8da2b124fc869447e2e7fd5530a2c3582044c763e4a2dc0b3d7a3bc1f633ae3e676cb0f39b1cffbbecb563f412dca2352d5f3aed4b73b67f200853635029b7b71f198faf3aa57c992f306626031d3efcfe492f257bdc5c4cedc54ac4134830baa8a2b5834af993696c2bcecda36dc639ecb433f4888746f754e655c51f23f326cdfeca1b876ad1a4571984221a88daaf0d6f1bb6e2db41c7a464793faf941e0e4f02c85ea12a2eae27865193b39700321ca955f16175695529ec9545e7d12698aa3b52e36ef1c581918424cf6a293ee7c0718b13bec2e5d21ad9ff8ce1d5f84119db6ab1c9577e577af0afac3c45097b25efa2f8964b93dfd43dac4ffa926df6a18920c915878b68b721ca626745b16e53e6b0c2e1c89d2a2e89741e8cc70ab43146e348ce40d41e62e68c384db6c786f1a6864b4da854dd120871933a19c5d37c50e42d04670dc9bec2476108cdb938d94dd38c2cf4d14c5de9723fed394295e38ae0ca0ed7bbc9e64a5cbc92cfafdb51942be630a9680d4b61ed97b3b83471b93b28d3f0e1e64eaa168035080a577fc5116e9e2fe9804d58b69995c2650f440f87b36172db3d3c969cdd3d13c9ac6eba99bd8ca147e8d6f04da68c4b2f444925a8ffa6715cd5cb9330a5448a8e7e1071a5b824fab1e04309552568c3880b978aa95ec424e2ed24c12831575c4c336ff2973dda63498c9f41ce62a93da4277e978637557917db9a856c82a2499f6d61fb2be6b2aad43028c400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810907e4d3ca27edc2a4f0eeb655e6c693b52b361f1dfe0e1e3b98bd61052d9a3880f411580a3cc99b078dfa01b51e356cab0f5f904c52ba131d192ee30210e0f079097cb35365ad95f4b04696a6e52a1e09656347b0555d31455c870aa302ac4866c4520f615d60d767ec2c66e201a2ae29311607e3b3c480a0404b887fd15197490deb3757691b62c6987bd51d8f69f2b198e52a73f4677005ac3e9b89b0c94c498198f85e65e0694005c68ce81d5b9f753df97b6b6d870a09b386182ac95966c827379e379e1a98d1d9e54433f1baf169596c2774e80b9b600e7131c78641899cbd7986f4d313acab39a4f390e3b49308f60876ecbe08acbb97485a5309d8f6b868d7ef512683f95a8898431cf163a0d2dc63e53fe2f7cc0c4942db082a8c3cb62ae7045fa3600f846ccbbdd8ba153ec892cd86ea4f5e4bb8e024fa80629739925022b43c18e150ccf9be9aa6f4696550b7e0d1a1389b1e08ee42993feead9e00e6d0df676049c91666a7d1292c18b82590192f6f25efa0552e4eb9282935360198356dc828dde37e62e4afabcd655db38cd313036cb3b8f5fc54965025027652f16c10c5bfc57670374311637ce91595ee23382086c35a514b40328f30b42fd55b9d2c1a102246bee241a7d380f84f28f365f605c84a5e6be36802ab0d82cc48426d055a2a6695675194b98901c7b2a052618a2b32e32b9b9c6977b46518912afe4e336d4b6098b55e8480c94a393e9505c8492e16781a3ba8e31618cecd02e000476cd61df5ce5d52404152e8d0d8bb5790f457be427442522ff32b4db27ebaab98321d64b0a84b708d9169a8726a3ad32ee72e84daf50a9cd900e0569a630027261a5e4bdfc08b800a9d418807215fdcdc540c570c5531b490959e526701ed9445c601a7ecc6138f1922b7ad2691c04c943176d62a25629d837e19d8594de21c8cc9279126e80abd3861906d0065c465d9b69f723f44e031e7125a7cc823d182082b5eb4b7155b117780c5168945131867aa26f71a6af1a1353348d3aa85b62284484152977625d658d21939be2aa2365298a935de5a34859f912bd6cf06065a6a52ed3a648268cc0aa260a7358a9f798aeaa153ca1aa30eff30b811c31bbcb8a4bf918a18f88cbb566aca6ad543c93d69d88085a805a114f18b1513155fc31faf1caf9a0e40f7090c60f0c09835229eacd0076fb40eadf63431596e4d209be649ee973d859d237e84101d98fc07b0418d83de83570f88575075170b66eb20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a0e34fcf4626248b979a7a8d306cb9ed69c4ccb5cc3729d2692e0ba679d5c2feaac54a4e06d4efcedf78e19357dae263e1b5d107fb09618a9c34f54f19a738a66b95e6f88e20e01f879f53e8f4c371b571e1438ff70e0a8cd00d608976e24501b2ddd323efe6c1302a318cad821c6ffe641672bb80ac62286c69fcffd93422911c46d43dc9a1f00a73e19ebe6cc09a9801f2a1da708f0f1f98e7f1a18529010823230279f487911cef1e784a229d9e311bce5e2d368e6d613f791ddd617d0f37f604b786ca2bab754e8bc4bd3da37e66a54df1d3b268a5a80379a30a52b1532e8cfabe24168d83cbfd61e2346f901c361f771e0be3e03dae8cc30614c10fb8dccdcaa5b9a25ddd8d61e61f60f22308e12adc137d3d8c53cf7b31984cb813758baa19ac178f2f0cd2155ed674a7509a3cfa7ff66d2d9b1e60be50fe7fb79591c500f66bb1d35edb80263f4b696a3dda0b9b2911d01e76e9070d99db93d1d0c3874cffa776ba24424a6b453526f7c44eafabe13c0750f9df33e82105930139e70b5cf1b09dc3913d6bf4a4859f67fe814ff038f0fdab93522a35e7f81002a395989d68b8b7e4235a09837cc6402a5338da08e7c73dc63c43bac42054c694f4931b80140d6b104edec995cebcc5629f85d09ded8257626f9fa4079adef81d044c18bf2277daaa41931b62a6028f89f95f06d8a8fdeb95eb2eb1e90c0d8523e0b476b158e3040f212390ab2503021e8d6fc0733b963cc6188fb2532829925b59c8255d89f10b657053d0fa1d8e76c84826a4609284503d3a101ebfe7af93edc423ef5303cd946c8b570511e38eb04bee0060e678d03e4134f84f279a570aad0332417fb2099e3f1f279ce7d6ddb080c5d83064d107bb560b21183ae165cbb54cc75313de72d40d1cf5173455aa55c5c356d7c40a2a7023dd95d3f89b515d7598f800dcb7bf68b707978ecaf55b794a17559bd1e913f4472b1830783bbbab5f23a760c78c46157fd1b429c445494cdf92fec8bf9fc217d3ce2697bb6c671baa793cd0c1c84f579f0daec400beada799a9f417fe4744145f21c6f8559afa7a514a0e951f03e5e68c17a8e5816f3fcf41774d26be2edc11fc3a42cfcf00f817c3d0fbf474fd7f30c9c3c6be7f74fcc79fa6ab07cab037eea7d83866673a74c087b5f7542804071d53ce348d2e836749e35af0fb884d5d53abb195ae1ee6e9ae35dc91be359bcd510a7801fc243c07dee92373918aa4f8a89eda3895a52456f7244d1ff007cc7b1a52cbef4c1ade1c2c0ac189ab24b3f260475e1d08e7c5bfa30a1cdd71de5ace80d5fbd1d0f17198b79c8eea0365d139f2ae73cab6fbc9a79786896de0ce7fc747d68fa4abab662a09e0e409f7e652153352bb92f5da1836b0e92b0b644c821b2dd2bd0af193ac0f8cf5b8d88432f0248dab09b46fbef2ef1899b5981e9b33de4e9927ae50890fefc35f681e075d8b0169a2e16feda6392ab9858db87ed18acba25575afd1feda9fb3fd01ecac13c245df6972f65087513f505187c4e8ea54b6433fa092b6cd3af13f4718693904435c55d273060fbb5fda76074691269493e86f287922d074e54eff04209b2fdd3417d8436d1395e638d57db75d68f4f819141b6daf4d13a9a18629cf5f84b0cd02e7a397715dde5476bdc467218d11aacd6ce399d9d54645bb27ca43076b7e4e57fb4f7c4f4b8d0aa949719d731c3a927fdef1533d773cf1bb562d5ea43817a5acefe9eb7e51029dea143e8a1d5f76f9bfd74a26c6d38f54194319a1aaabc4daf45efbae770b9e9d834c09fe45c15d4bbc0251d3df2f2f23387dcabce6ca7a59625e18fd997770d164c338d0692af97c749fb746c0d3944ca4b2da6d3ad7b8c3aa922fc029cf9ac5580cfeaff50cb2e9044211ea522bb5769beb7a7bba0743f345feea9aa9da6ec5f0579cf7a5aa4dedc832fe3f65185a31fd49c0d259e3b7f8fa96e110d130f588cdec30d0fd4860ca6673c46d961fc68a4020fb03ae24b1ae12967ec1ed19abec0808a7ef89521152033f70f406a7005819d28dfc556c79de18584088f40be40a555eaefa78e3fa3d9360a7cebd963555cf208dc408a07ccc1369f98bd840f5c940721064e6c7cb241ed0697af0facf36f05632a504870abf90134a01af00d340f7a5d548a8078c2049600ee454d15eb8ce58c26b3c8185cf9dfcdca7d4b6dcdeb82230f993d51e701d8387b06bd45b4b61dc9da6d3b4356f50c1d4ad2b467d36ac092442fa90d1deb014475ac7ce90c974063459dc951decfa30d2de4c70fba39a8b6931217d0924ffa783c8c3daf048908e4aaeaaa3b7c98846278afdd1753252f39caed7d334d8575ce3ecfb2edec31afeb2bbe67fa929a267376293c2b2f295cd8dbd66106e1d9518be1798949f3315e0454d018c2b706fe836fb37ab908d9d698af495bd285a74e4cfc7612d42121f43fdaa7dcf44da82897b820514d66b92983a3ec819d2ce208d688b6f0aacadc0cdd619d815cd231ad8dd9b6dbad9c47e16fac098d0f4279ab52055d2ff765af6e3618c4509fae6ab00fa23980efb19a26e0a6ea4c9a7dc699121388748449c429b28ad2779f5642f05ff58b68ba3e289f90eb27ce06392616c080d659338caf274d46a90d58f2bfed25e8d4a8c62030a5e89f6b1a5f6112a38661e2f2b5a37bcbf050812dcdce9c0a939adf929c921e7da0c30815da318eb2f350f286441cc92060c970077623eee68b8c6fec9fffe780a6fc85fd7af90172951337af57339e98049132a4cf58874a7418fb7aba0628b6192bb2c43102ee6b1d7e824725d9c75d34a8b69df4a6bcb1f96b57767046c99ec6352751e2fe1075bb4092672379b3518ddc884fead5bd062b0336ea88bcbe0d22e066566347feb617a322bec561e9aa9d2177eef0dfeeaf6231ad56d0cd9e300709c9317b3d334d8d2ac97f96cf2f45b8582c4128d95da8ca207ae34d3daaccdb128c11694eee6d3e8e6ab767b6886b1f7235d85a4d9c7c831c5db8ad8323f63927a638e19497cfb308285a03ca2c1fe2ac4d919ad11511ecc6f28e7d0e0a614fe21b57bccdf83535c7e2c40840ba0014247190c580378454751eb3f2361d7193e160b9516f7ee1d683b336b873c8ba22e97480a61f002a73844c78309c0a3b31be30a192a62bdcc3d33a7a5ba1f6ae0404a8558740cae46e5fd15971b41c0bc39665a9b92eeb3328c328b073ed5b3720d37a1c097af8a6fddc3b2b067680e6caa760368b0e1c052e804e9f80f26b52596202ff2e0af7215999eaf7d3ee3e8916744e40aa1154322dd068aa15960dc38671a4f5889fbe709ce1deccfa80b9d33ad2fd963fe0581a2ed7718a27ca62819d05baa3212ec7cc1c5472bcf579ad52d5e1b2bee637d9827851c419a4cb91db57b2a6cb4433c1bd209648f1fe170abb964b272bcf0a263ce28cfa3a9d1449cffdf643e37ad97182f0031cb334a1eead23d63a5c2d0a675d0ed000f37fd2153e1afc4ac01692701014927601203ed2b8a477ccec45c1f43190e4fbaf2295e32a9383fc7915aa76950a301abe47bffaa9c294292126934ccfc173115a6ca96f3945fd5f924a5017125ad5aac705106eb852ef3190a24420196ecd37f7c67b57162cbeb97dfa000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 77","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d397737f3bf5b0fda52f5dfb8934f4f39718163f472f9f145a59a06aa9a4fa988eea8a465c559b8ed5194c632d4038372509c27517e86ea22722732eb19fcb7dd4582b932793d07b3e75476adfcb7e302da777f5a4655b7c2c862bd6fa182e5bb99fa8f1f0319bcb142cf045fa4c67e918d85b368a4824469238b0e0cbfb58a20b7c5c655a0b2b846cd09bcc273507d7b168361943209d2140fbe59b2dadb7475a73545f42242f8d5f391c91fd9c0d061bf04234c4f315b8e6e1505f2b8549803c5f393517e7d8dab5dfab0241b892a3d8ad1665f0d473b149cc5a0983268c59cdce39561cc26f3fa7328d435990352c736e9eb3a8731179c5b518327d294f5e360ef7b4411aee6b05384f72ccb4bb54b8df1985a7e59dd7e548ac71dab2d022e4b1048971ebeb1184318505feadb15a9af5277937979175cbaa52f5d782e8ff6d4cba228ec632eb4b839b4bb11c24655ac254626fab8f5ee440b5916b4c9889518c54b62c9c62a4f40939654760b78e2346e1a08f26d598470e9c68f0453a297c99e167a6ad32d88d3b1d442c7c3b6d974b85a458bf98935e8727cc8a2fa4c544392be5eb0e98eae1a6da739abefed369332043b9d329bbec6224421f0c5cf1b7640acacd327b4e6e91a1be672c7854d64155ba5c731e5503f968674cbb39a259598f86df71568d12bdb432c985633a6da624bb2587874b22879ce84c1b81a78f3e6efe420bf324d3da646b111b64a2c515cd860be1fe54eb4b47dcaeaf39672d0ed6c5daa91ca329474cf3264fc989d74218f45204c7c193c6e0ca3a9846f4482373c7719b977021242d0ff1f4bd9f4d0c61234a2568140e794894eae03d321729cfcf76d41a3bd53539f0bbf9c49e764e3ae6813529b50bb66e1408421a61f9a7767063a1be6e0c93a98794a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109bd769a14ef6060b89635f60d858c4e20b65b0f0fe99cc4f3a9596448a6f9e826e7e7ae8841f6e5de605aaa12e573e16f5138f03f14204dc722b161e2bec4681651bf8aa622030d365437dec0ba3d40e1279ac5589fbebe81cac2f519d023299460744d5e74184843a7bc4d10a590cc31410143c902c12ea361418548ef712dc8748764953a23e278e5ea0140742d1a210f9c8a3f48c806a8109860cc7c82fce33f57cd7e0018d2d0245e6f2ba71c353522fd22278cf7a03682075110fa92d4c39b7c9a99b12d1f262b1b2e52407d42479d585eb08883b9e80242be600ba265a301da4ab35ce1ca678e4340169a2db0201a23a36fde9bad56f85627023cf2f9d08caf7ea99503720f8e212caa5c8385d5e03a5d62a5a0c0aa152c35116010d08f15dcc25893557294b0e22140bb88f0a74975c1be5a14e3bab2981b68e53f49ef602424e244c893899cb27a3d02cdd567a5faac17dc55a96e21bfe3285c700298b2f66a5eae7d604633b888435c0e9170c1617b3e2a7254c419dcbe7e6a9b90ca2822f5c9c0d72ffa3b04c2a971811f1bba52b9ca4fbb2bc2a09b74d710a6f0db49fcd92a1d5ac62512d6b68cd637d608c9295fe6e2f3be564a5140b146494281ba5dad07bedb7190c4c0e3fc5658ab7e91664de19d5876a823ac44f84abd9cba0d65e9167676026ead1e073dc8c98b2a9724f82ea6ebcc3154c477b16d6ee486da86d61b2586a73cb1366b83168500577b78ee78067184398d9533a15c8c408eaa7fb0fa7b74bc460d15e5c44211d32d26aa7cf812206796d14e24418338b23dba29882fb946798c02869317678195398be26309beeb06c3660f63b6f9909ca9f502f0643027edfb0e96c2a939d4b9b0e4ae7a7b1ba03e485a3b23d75a98f947e0a4c1c89911e4c61a29e2aef582c8714a6503504242a8887cbd304f48cf60167e19601ac5252a6500a944934f972665d599059fe92d9ad5494ee2612c21aaf08b23668180d49937cf4385c4ee87149ab05fdd3cc2ce68306ff151399a46ce7f6c54fa23642a3d494e18f284b20d5de6a281cb637c462413496c6f821d4cf829a421509d50138f8b659999b982ba2f5160a85048f0cbb97ad06d453522304d06dc193583d96a219dc79a2e352d296f072998282f34a5057158fd53a8ca751b67e76d487e4242d293b39190e15bcfc565b546aabacebe7be5e6616c0cc7b6b5b968f1c31169ca9fb2a5cb11368408b7a79bfc5ded3855ab61eb5ada7d37e1ad70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a2f96ad5faef409b8a4c21acb1acb596badf387d26656be3eb17987af59737e324b7bf8412a306b0e706aef73d79af753d9b0064ba9ced8dcea966543fe748e2611709ecd1ce6e4dd8fa812d485e91809a225936675369574b0d104a258e3353ee0e021683615ca5c7c531fb29a5025cc7f7323860443dc19c9858f741eb9d24a9f6f04fc839b67153214116e8b7fa982f338445830f915f7c85c88c23ba2a3ce8e2020a9d8dd7b18efe95563e3924d2a341826af51a8584cd026b1c433ef0221145ba8bdc8f73a467b33a9eb3e8cd2a4d671c17d7c28aaa539d1c5bf2f4138639afb89ce791daf0ef0281d52598f4c13d210974cfa1f099a0fc70b1dc120e5c00c33a2bd360bed57cce069060d6380be2204852d8bcfff4918ba0b70b0bd1e1d55dc1d68db1d20ae713b0093eaefa1e33d40d9bd95cff17568393e9bbf5cc1287325d2668f65dfcf44ace2f6c6cebb62f1433e69cd19e6c6532ea93682b22c4c4a62c6abcfaed08ee64f32723e56205222e4ae0831ab8fca8c265fea0cfc66aab1e367201752aec11f752b963792c071e42a8a1ab80658a0c6960147ed740cd07f307cf6a644a98e1d2e56c625acf458d0bdf6216a4f1b9c78ec3f14850c803a4207c894e61a8aa88840a27f2b439fa7cbaabbc789102a95323e06e2c324859db92c6ceaefdca389f677082180fe3d6202ff60dab9f87e3b84841c0a4eb5974d893333f7f1513e54ea4ae0731ec409f69b77089fafb121300042880ea59b7927e9435eabfdcc1019a96e145d5d157998d620e7bc6945dbd6cd78e94c2d89589f8dc8a01cf1b295a26b091847f034937f764adfd811f52b3aa187f3f49273eae5949ff34b64bc86ff11eefe378825d526509483e7191b33333e5465ffb025b269f898ce1f83ea549f1864b556c729f510118921b69594f67b8c229236ad3aee55bd7082e027b5d342c976a549e01618288944de0b2c77473a25201b61034b334968178afab7f8cd1feb6a25cf8dce3586ffaaa861471e2ee7f0c22538fb3c95d2145965c4673e6489764ae24b4f048ded77fe3487ae175f6d4898f69f9fff276470a93daf986a75f685919d98c9c609c795d4785ae941c782b551ef382f47209aadea19066ae5d3eba7bbd99e91943f1e62754a42ffc8048f7b87f128ccf6c96bd760b45f07f740e94491874b06cc3450aaf55bc664b407c57369cabd2708a9c478dff64d292d96ab71eb997f8b71cdd6ba02f52c5035ec26e8111ebf8268cb00df9ecd63bc0d557e2d2e77a6363b00daf25237e77dad03f929e5e9b39447a70d4e5f4b90958f312c80d594e1b1f3d0d23f2b0d9753bf3544061cf0c0f841c440319e74f9b9d15b91eba1e680ed6aab7d63a97b48c0a4aaf314e8e77e2ea6be9dcfc7b5557fec1b996a37c86cf6941325ec356ee75671726bced7d2157be8d4c62cf4bd0420baf2c4223597c0ef75f7a7c9533d14be0d21c37f06faa53ed5ee0ddb025862417f98d2f188895395cf2fe72185acbea952f55cad7ec2d684a5ab94b1257d7abb565b8c07b88c6335ffb9d2fc6f6779cc24fc3cdf92bb3b12ec54360a7cf3579632a2a65c518e57015df1c616c857f83f5f1aaff693acff210dd1e95ce04cca9a0bf385ed6ea2aed894e79d5133799393469b666209371e708d4d279e1ac5ace28985d0db2765d547c2902b715baed5a4fa3e7aa42645f3bbe1e9f3cdb87b1dd8dbb5aab08626591921cb49e552f8ebafcbcf428470719ae40b9ca847f31848f39e4d42049c5d40b0bff036e5409a6a12e7924148e60b64bb83386079b54486ffc8187302893b8bf826578d9ca03a1291983f21de7f6e65458f8942dc1b135c6c8c1fef4f3863a58db17112419590ae57b9425592ff22e596191e5ba7c513ec315ec3476c95a149f6a5ec1cf24870400fdf46217a23f42e0b61157c3cee23e7916b4475a94b96b917c171b1a34db13ad98833e457343f94a76ee226fa5b9f3066c2fd69f14d3aaed1b31f5114780442ebbc88d0de5f689cd910e7464d73423b9d4e03718c5c51871250d11e27e28df1268166e3af328a80d9d335f2d27d2e91dc61cddc7f733e345d56c11b6130875d93d527f93542fb352407185e7ac07051af7f642e34fa06b1376ba15a35d837c1bfe090ba67a89fc1e307dff3f02a988ecd48fd229733f641f2609ec8db14b1a5ac170b104f03c2509d2ee6844c716766d06a6a25d957530fd68a8de6f1753f83ec19ea2deb1a4f9c7986f20ff60a7508ded6547a85baba70577062e8144ba0496777a5218595e021937febad4bfdecac29e3fff2efe7d598fcb86f93a734e4c573e1496a6282a3b40e817dd3c9d631939aab350adc703899ee3bcb1b5eaf6ea8420dd6eb2d4f64a1818aafa97b73c75610b6005f1edc1ec7d8f8db1e5d3e9666c1292515105037d26f2c8d83fee1f4ef5deeb287cd7c1e11960218c1b8bb50453488bab019435065aedfecd8d218bd1e751fe736442e8d09ce7176a71c06415a30b070693a68bdaa5cdf62351ae665f37fefda9481e62ec181ed24f0d0649ad01c89ac422f1b7e27895e55dcc2fd817346d361fa559094b37894c0b478c68a1d7564d089d9d4417d5c7372a33ba475a81fc129f3259c5407bc7435825b415782cc84d85e69d9b44b32d78fa255a895cfd55319dae677ff89d93a3884ce9401775563ff1788cf3ac11cf96daa199e7f4579a0264378a323fda64fad2349c09465fb23ba09069c7fbc79e7288a82f9165268f6842e0aff0e250c21bbaeefb4347d4ef1cd51161dfd29bfaffbedf71dec93f4157a5c18995379ade8d15db59ec4a8b308c2eade1b7ddab55ce2220f3b3ae8cba7c8211cccb3846a225b438f4b37df54363a987c5c4e6b9d20ec3c0096317d11f982184b75d8effd168b7b41317d40f903a23a2649999db36caae31ba5d91998a684d30aaadbd3b1ec154bb6c92513bfc0c47c673254f42b1fa36b995cb737668cbdc2a0d1ba838e74e0e50b22fc22dd048f48b6d1e89e1ccce5a226f63ac7b8e6e9e8ce27050bf3dcd7d0f35f47bbec1caabd4d619cd77302ab4ff6f56dfbe9f5821aff2d72ee6a628daaae4440edcc070473bdaa54ccd775331ac2812fc5b9884915da582eb36f85c7923f06d961594753802efc5883ca484fc64face42de6c3105e23cb90663a3b381d0c6a7265b740bff0a1a017058f06e39a74bb07b63f883cf914fe675e7e5ad5ad44c9f90ddbe23a125d9be02264edc13972ff22ba48ece8890a223ec13addbe055a8b4e03882677fc0d94c9053da6ced34e132fd83810a793350446d60ae5dd0d174b534a3b6f5bc1b497f9406b5cdd414401b6dd881ceabab12cc51425e88a81bd9e14bda18273583cce0849aa48dba1cfc49cdf29242c73c99c87f063b8b739aa787570459c098405dccef78d6d97c21545f2959df9cd62f9c38ad9a849507c23a51714565642dd76c9103154327985f7dcc701b795a7af8625f06367adc11a7fd7b6abbda5b2ff6a825dd43b64a48ede4eff8603a82159a6011f9e626171e4593c0e963595a6e068ad05feb12378c71ae515a82c293eb7d2b01b333cbc7991b44685aa7513b3a58342ba5d094b773e6a27f8582f3dabf54def59974cb8a2499369b5b64c7ac08d32d75fe37371c578073dc83b82a828dfc325976ff282d3f60000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 78","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f3972ad80221232c0d1b6aaf6d4b3edfd3e6f95aceafc3774782236ffe0638c345f226baca98c304e57bf93a8ff873d0ea1e57bad4c9f3bd634764c6468f0f0d94826a70c866cbd899cc0909e78e7ee687b62b46128213b0619bb8dfddb5edcd95989c911440e1cd23a061dddd030ef752f973daaf6e3e5414586f895bca5a660f0ebf9903832db6c5ec9cb369270b1798dd9bf2ea85ef905cb25783ddc00ea316a65273b996991c7658d81d365a80d6488cfc87e2fed2095773238e8a103419b4731f351f147156daa661526198bc494152b879443f30fa330cf97560f5332142c411173533887b300caacd6ab16522426e8cc244971da280aa947e967db7c7b5d07cdcaaeb1880e577062f8fea96260e623bd3395aeb9eff3f63e26a5adc3188c0eb257c98e3f8bb7bdd4d2daa51594015a40dd1e3c622f69da2934c6cf75b97eec5ecba23ccf5d12e29795440c25872c9591fedcc96f8230a69341df508a9b14bc60b6e63b532f799d1b21889b2a48f324b7e46493db133397c1233b1c03e7ef95953bb463db52461bf7d67e9748e2905945fe8753985f787cee9de20ece5af0729869c93798b664c9356fef749c7d235f7a3a219c6d98da31ad5d3cace9ea0ec509d258f7b9eb4ee5f0b23a4eca76d73f64d34d44387b2362abb1391b12e5ddd63e4bcdb2e8e7322ad79d3b5422cb792f92a9a5c4e81d9d8a871fc9a42d847990a7c84e49d4eb9893fa5bf810a61d3730a1e6fd3e70facfd75b58a9c379b04e97119aaa1ea51a7e92d0eadb2299f7b767f3751b434bcc48e2debb1d66e74c2236f9a440607d38d8e75731eaffd73a66856919fd7fb5a2d1206d63ed5b4533b187de9f01e8261484ae2291fad5448580560c36721a559c48badd4423fee399094448fcd11434d2bdb5d1b2923e5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381091eb994c3555d3e2e0d75ba34989704114c15f3d72b1391926aa1ec70a34c0177c4a2b927113d98bf87916ec9adf3194f0276d299a3e6ce6e7cae3299882f6d6418746ae643275d71b8d0ea04645c4a36652b21e413614d986c073980be01caedad03bcd568f6df56b377b104a58a9e998f79794879c62179ed5b2769dbf56716ad29b9c5e07e842215cca95eb7b6208b3f2d7e521437fbb39811905e62e947d1db8b460b593740271d603a0317cc1a255a35541ea7418542097b7b4c3c9a8e38ea0c4f58b7a89fa984a9a763810398dd2906450e6f5990661c10ee22952dcfee01c9c1f7b8eaaf1a78babb745748b3be8418659b1796d1b657fc6779011e00fbd028552332d63382888e9c422e1027aecb37d66930e752ad774491573051716f42f1b1ccec6c9efd8c434e9cfb0c283114ec8adaa5984e60daab409a528084c4cf277cec9fa0f8cace5fc591907c264aa5229714e68c2303a608245a89a31df8bbc3adc1a15bf568e50c813823c02efb1ec3591b963ecb7b20a0ba3d60c52a66e299aec21bf905f35df5142410a34d4f0959d54925bf4fc19e53e423e379d55888329676b6d290ba7c56f55f116b02ece3d6a2c26fb080171da810585495a557afad0467db19479b0861d7785a4d570d37474387d47039fc8a464d086f464233d360ee5062465135a6eb66ccb81a5ee7669190dde9fb02522b78fca5166e723890f651b462f36c6c9d578dd9c44fb1872123c06075ed61857612c7723d98dbec631f16b9c0e5b55183a2e24da1194a6a93de05d3ab9eed94d9dc89cba1e111914576876bcb3215936adb4abc8a4466a3864e861d4e739b8b6c4256202a793222b316c06048c652369e0e4c36e762ab8b3efa80ee1fa41b15a8e27284926d7cebc141a3118eed73d0ce46b87348f9d11d5e2a8135d1f7afa25d35dd0e818c8a3fa3ded2b6d19de44a8ebfe62508d41464efdbfcabdca700a91500e00a77400305f75b10767d1edb485b9b6b8455e2a3035e27227a9a038a934dd0b9478c0af5aae05e4120932ab60abe84365d338b892ea0d5014132f20577fd2f05983844990958c6b8ce2042612e30358d555117e6c18a9086ba47d5151df161959312a384817f95df6dcb7199a7d6b10da7ba4daf19c981a6983efc8bf9255133bd4e72d0606c24ee07c52901658c19199912c5419b095f71eaad268268cbaba8aba42794a6e11226fb0f1a2b165bd4ee8112c92a2210a20fc11f0a104f36613c1b2980538c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a502447d338bf1a375b66b77fb96cbe7742508b57dff4d33a368ebb8451c2c67b980d3576e6588d8678b285ef288a8b5c9c2726c4a550e764e47fffa2a128533a7653e480288447509e10013ae1944fffafbd9e2baca0b3c7069c07a4186c056fd3857caddadd5f891512daeeb26865f5c89ffa63a64c85a08e41ebe7bd8786a8add571a4267d5a9e426840a0b988e197a09f3770b5b0d80d65515cd4d8390af40e6150062dc4b8661a8238f232692c152c97b8cd5bfe7b5ad863dc92d99744d769087b3edd81d2e475f5cf0224b10cde6fae8dfc3519efdbe66805ad4468d84d3dd93430363677360da8f56cb58a6b775ff6417c1f324380b15c9ba668eb0f25fc2a690b483e856f3327b2d79fa6259e30d7f76199cfd21152b7c6ffc3fc113f70d3930c08b3c1eb1bf25c100c5a930eec2c52664f092b89614943d9d85ed86a2ef666a94f9826c3d116a2bbe49443e2c11748c977716381d9463da8d09612b80a6760e5a6fc5f59425eaaad6c8342c1ea4beedd5d73151ce213c0b155286ff22cd28e3bb88e0cee39cb859900d1e0fc19f6a7237bda8e51476f4844a316752fb347492a928eeb07aa39abdcc0164d1921b61352ed4ac94b82c410a56505633bad53a3e649acaf64c43c1acfcd4715fc594af6fb9e85b0b7ddd6e8621bd12a2bee48223a97ec8502c16b550b03087b6e87c1a860d36322064f8febc52f2b7c31dae7430870259bdaa5889852e3ae6f61013f5ad0d38727cf9d90c67bd7bb3b82d303c6c35383ed86fd5b7ddec824ea198ef780be830a1f2679d24ea6e2feefb979563f511d188f409f0cfd0050fd418414d01e46db3d23b3a90b24f4e96edd4f863bfb333d6a826d29eed167738bbe22c516c59fdf81b032bb55473a5ea2a1defe71c95a1eeb5c028435ad0379896cbbc76877501b054cf1fd2f6d7a9deccd70d0c07111147ef568dce514de96eed61600029c8d103b31c8b344a700de630276ba2c5633419c59e66577659538a6381e45584c7e1d6ed978ab0af89067ac83bb70deb6f2c58e339a5a66176a54d985da6e02002948c62be6f12314240fe18b09aacbce82ea462586b8316c3e0aea00f9998922f8d956120e53b4178223f4d2934a20976fd5a72027c8f4cb33e9bbcc0abd15395151266b6cd5b4a9e2fc1725d8e9ab2cbda47b507bb25ac995edd51ebda5fd19caf68fad8eac57cb5ef0c6fc861a73e64648ee3255db4c3394438f49377cc4ac2fce1b6bc812e5d282f122678713c6c6d452a33c632c0aa47686588752d72b0586fe5ec2464a6db40662fd2106a19f67dccc45692fca03685251d512642b0cee436c78d94c6f5f25bbcb41fc7e5b1aecd52b846a0b70eac93579603e9870f942ad4c1cfc9d49b1132777c6f1c184c1537178e5029067257a2da2827a2ec44d323d13dc6e4e1b9edf5949d4324228687fd54f02ccc3c4dda635fa546a5a6783959b1c48aa9d9c9f6381ebccd979253460857d3cb1c70893ee6f04709e35923883ee3c71c7f33b8cc28b9136b3ebe5f52b9a76817f2f74fdc2f12b459dff32d5a295be374b3fe507a0995bcacf1e7b24f4501b29f1e8b4f2a8cb394b3e459a4296f6439ba59ec88305ab045ff40b1dab4f672f878de1f9e46b9326cb3e2f3457b83ead8dec28dd079af0e984a69ed882e1cf21036578485dfc2debc9cfe82fce0383b4039d147c4c7e31e315fb57b9093daa811f4ee4568e32e5625abe76c5a1ae42a03441dbe766d0ef4df607406f7d489275e8c5d4470866f9049a4ad5c428b843dec3702e86e177e4b60181d2b5f099bebcb25f04c93d087c72436e87a9b3afce78fa31e2b892400b5c1071f8ae0f78ef6f7d71859a97c17ec0912d5ea27afeace739fcf66f489ec6355a3318f79649881cd6c7e96a881ecc4ff6934c3d10d99f1dfd00592cb037749b025bd4bc2832e206c1407e600fc2170c0bb57e5c7af0756830c2a6913e2b9c60575cd4a394f2a65c50e40a43cf5ebca6a8a32335707ddf4633bac7375dd53e24df20af30203b514d3793392e38fa8429b050f58b28cad0146f385809cc7faeff8b71b2bc93d2c6f72e31ae2d07cbb3cb7f43540894e01654edc71ccf4f361a847ec5b1d23c2d4680e29f0e1f992eda3ac41ecfe614fc010a2eed1bad87a7d17468d6fa5356edb25e9008a9bb328225f85202246816e1a542e1dd746a5fd3e064faa1248579d31cd3d65f8fff36f782622402db328c7850d82d8d8a52b897353a2f8b95624d2d958fc1c3ae6466eacca2a6a5e6add4a582d27e07633ccf697fa02e243a4fbb3dc727b718b5ac0fa6aab217e241627e69ca46f05ed6b496a739a29edaeef76992a507130715be555c68a7eead6e8ff3a378d8f4b7bafdee3edb9ec094440e31bba717a9c82a117d05edca2370003dfabfb2efb29510466f74e76ceccfc41709fac4cd8eaa998357170a7a293209eb0bb83dfe5e2f6d73c28d5409c55e95068d647bec42db8098f0089ef8a5fc5976bac421c37dda6c4227bc1ae5ae229f067515cea3d794c8d85564af208ae0fcf836b6c0af41477f99c8773d9dd1923c5c07e1fd508c7436ea93383797f372ef3103546a5278a4f59614a5d182344f0431d065c35620d63d4d001d7f626993241362e67d1bf41419858eecc2626537d44e2e23619381e96cfa91b3d8054681d298509d9b99e7aa99cf8742e37637b24136f8e1b487e9571e4c24ae5df307e4c7c62e55c47132ae404b33e5367c6f24d6680be32d20bc58370145486fd5eacbcf98eb7e7fb6293044067af11879e91444025fe52e24617269be192bb71bd9f95356edbed9df352ab56a854f9f531889a88689d3f161fe6155c6c1e8011d60a46f59c7d08c477fa652b559a80567076b4eac29a85d54c66b35d6960dff75a696cdb17ec9a7b74dc6c3652dae866e8758170d055c4bf60fa1238448cc9e29160df50160c4b0dfb36bca40af0bc5f7d490e7dbca49535742eecb90098a0a0fbbbbc7af25c0ca9bc039dfb555dd8431af188f7c1d0ff786d627c058a0b9a15f26b58aa2a5992bc8fc5aa14025ff95f294203b45ea081e28f094d0d4ad671c885e67b2e9e800f10048158698d56648f67bfa8cc73dd5afa15c1e48936b2596dee34459b484336c20cd77e58bf682479f9aef2fcda86e4f3a2fed7046e5a3828a9b3c0dbffc25fe699f25629a2045a51242e310cb369b730a5e81167758d7fe843261a598e4541b02d0db4bf5616ba07a440665f7fea6213114b6b1b38bc033d70e845445dcd18e23d34d3d6f4a52f5f904ac5d8feca5af1123658d09613209ee19954174a1ac7a8c7f9ea288bbe5a0705f3ce38f30ed5ee69cf5208d461efad51c456507c3729eb338ce15c4c253be21e81f082b0847c6871ca0fc8b3e80115fe2bb8cd8afae69a3c1429d21f149b7446888bb4dcb639819efee665b6d6f69e61452b9328b4887a7c04e9949390980a2609a667267035b11bf862c1131533ddafa518221627e0ee7e4009cd48e4aa9d0753a9ae82aa0257b69d569b4c53f05a75a521b327322c60398db0947d205d2a33ae51cf2cea8c9162dd604f8edbe91f5199d19efbf9896a46389e7bcba54b4aa57cba0d4f9da117f288133ad01a9a9b2a824d54f74d4172be2b1e5f0d3de60c13aa5b668ee6a45397c2e39573ebfabaaba48d1ddb2ab6453fbbac8dcc05349404889c7de23a16eafac8d5e541457c32cdce80cbc00000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 79","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028c3929f2430e44097fa6b3688339cb53168afbd1cc53e93bc9c0b086f663271686b79d1dd8212bc309abb1e2a95207ea2b9695eb32f744793a7d66cb3c7368ce6f45d244b5b53f92014ba55a3b93744cde710bdac90fa0447449c684ac599e289e3da47c116565b4e3df3df46c52035c97457468b26a80ab8dbf09f5e7cdb1a8aad1d13568b37991b1a89c7e6d05c2200d7a2c8e6d1d24c5abdfacda79374bd5de25779486b423ed6f8730be6fbdbd4fb9ee8e32db9df1d54cca074211a1436158b44b219fcd2a8a5e56daa0d09056f70eddb519187b185ebf489b50e5bc547a6ec4e255a585931944857b3390629e7332ecbe15fe877bf5bc0e6661d4c3f3665209220c5d90ed8a34e14e1e055ca76808a3775ea1b7b4eac40e61a3842d7d3db3492bc8695b818430767cf18b1cfcde27af4eac2d39273fd6ae46f21baaecad45966ea98bfd6b592683e17a320ccc4f7d5f55929666ece29946d64795302c975248c4daeaea51503b371c8c10929a2376caa8acda7ff783a58ae7e2f945f5693ccc86c3ad1fd12374b88a2b99d0e7338f2b3e88750a5e0eba47e3d43c79067461f30cfa5462d1e8232d107434482a1b7ef56c3fc41a91863256cde8b85cfe7dac9c94ebd3c801908f21bf1ce3086366cfdeb20f31eb5057cdd3995295fefe498fce2eb02eb03729cd6b38d6a45df4c49ea6bf27d4b8f04fbe0dbc46a52ba4131ffea99057e28767a6981f2fe91be5e7cd5ce1c16ce7705d638dfcd722d17233a85ea3af6d9c87205013c1dc83a4a8b93a4bfa4c1795aa87ccb99e8dcadfabde93d822ff45692d1cb907853cabc9b2f23a826f8aa028702cc6b184f3fffa44628484cb3c126ec1f96c08ac0c934e89b64480e613dc66d195fec8de7c919d503bfc2238379ae48b78da4109d2790000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109b3a59cdabdadd5be753d87fe41f35b2efcdac24a9f34ad87dbbc817e91e8c9fbf00239b7a890614f8ccc3a9ea4691b02631d2c6a708388dd05c94635230f906f5dc285d5662da786de4960eacc7d56f0c5a3d434bad03b14c0c38f6ab0ca39d8a0c713be6c2607298f474563424087ff43f241252f9cbe1401af4727691e0bb056740a98d46cf94f57c250f347f8005adf632fa0d19cd6026c364769f1e68aa05964409e81ada1f308d67ad748a87b4a8d2b139d44952a7d7477b8ab88b0155922751ba060f0421b69abc6b3f6d3d3cf25dcb61cd682f6693a4979d57b409da0ad21f29605ad74a2647d5b3b9a764230472b399928946a73f9844ad03136f692401285474652004e8090791e5dd5fac65e0e9408a3ed6d8d1a4851e50345573ab2c6b3639ead5ea418aa6f003f910cdadb158a772e18fa653ea70f9fd442454c65d72c59976838287a6dfc329bf2c6deac72af07bd5edc584c56c0f307ac9b30d6598395f26ef94e4281581d009dcc1215667827128de1d828ba4e66e0c165ea111824d842dc42b72c6abdf4018e649a5e02d6286cc131853b4ad0da10bc621997475d893b91dd757501c0b2d8b68a3ded054dbce7d06d1d27a88a21f5c08e66141c1935c5814909f4c46a6726c54dfab35ab516fc4f7664977d298b506e9480eea95f5e4656bbb08d4f62f220d46fa929a5fefa3104117a88da8ed0b008958f2032d29d2437267d8ae45c566d13a16ed532d49ba396fd1190a5e23a1047f1f1012dbdbea54227133624eefe8af00a0780f518da511d8fb95c3f1051cfbd50be3679cfe58e07bea649fb5539239eee97c4dc947c9078c0432d2e4f2c95b7922af3a5a17b85c667aa19ae37e4e19e864e3292f69969f504b6eb22feddf8988c8e68c482f70a40132534ab3c611d6424d2e2df9b1ced75e8e5fcb8867390766917226694a4b5114c47620503e4c1cf9e1446308b0cf04786c216ba0c282e426b596f171667b2169308a17c70f15e7b4d96a45d6ec8f441dca43560d53036a93158c69ab2fbede3a58acf2b3fd196792697725eef348949366bcb8d80108c3ab2f4c9314f96f4b073088334a26df44e614c019dc5fbe523d1b3845f8b92523c17dc3de1c91f0d23c54254952f02bffa422b80d1444be2e4a0c42c5bbf1dbcaaa001f199c4ef157ad15179edffa359e916bd26fa6bc297a09ee04be062d97e1e0809d1d2d0df9e12105b32238aa886f36587dfdaa61590076ed77b892a9abb6485af000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a71aafa792bff719a3b794b2f8198ebd1556889c8c61ee6a51470ac9b274cb162af44a26e2ba5ea7663c4c78b4b66b322ecaca8f2ebb6a610b51d7c4399f4a64a870c038797cac80f709ca5c3c9faff7d797963e60983b584130c1b99328aadb2d261217cb95a535b8518a78a6d2f6cb8400c2aaa2daf451391f7b8ab0277a3af88e1ce6f1d3dbc386cbaff15308f073d29838692e645f566d4b3db4186c259bc84606855ea88938cec4f7211bc9b461e39dfbb9e44cbc273e02d4314a037e0a26d60985ef5a35f069d8b51f86e9b6801ca067ab75565d73581ebbbbd98ecb5af47509c8729d82ea0b35f0a376ebe6d90108cd61fbd0cec966c17264f6a87864457f41162ff7210049e6ce2b5354f8f19161e0866d6bc3935815d9267c600dc529521fd092b126ec440d49b8e3a166587657b52ae9e2923644f72876ee94a61d2db0ef4dab33abec0c47a6a725d4cdabd06d4f6a30bd7c90db3778c17b7d8ce82a5123b798d8b47c7f3e968c9e9f82a6eb3c2bdd8fc06d282f5cbf3050f6ff71e2edf7a109f23ab47f427bd75163162c37722bf70a6bbebebe8fd9c39152afeb78c37d718014f739f20baad1597b1f9c4e0b59fd82b834d83daffc935de4a3272d7c2454508c07502943e90fdb56128d6e6009ed09ce80a9b60d51aa2e4e162f7f0c362f6886bbcabe29ef6c7f38b742000b9d152ff709082fafe809c5dc9bcbc6f300b0a7840d0d36f39567d14d8227e7145f7ca670efe917e0f18b0570da3e05dde56883ff12bc0c76c2a1e9feffbb728d991769b7d0b0d34853c76fc0655ae200501c28755f57934bb9f46a3c6ab1dd8e0161c698133f4f2d7caf3392576b4bd2b6f8735d80bcf60656e132442bb7fcfdae160a2dfe3f3fb8209b5c933201785a7e8206096b84a222a68e62501846273f6a9145820f87f450d12c64ff79a843e897c8394ad54aaf4f3b886fb00a6c37b2efd0f6d4dd639c9989e7ca30e4f12eef440946b61d7a28904e1d74009b6d1aedf2fda8b5991cb37795a8ee51bbdaaea34a4c7040944761b9b4b4c12f455c536992a0852f7f07a9aeda8e522591cb4831b0c79fa977ab6bc49c9730186855986035d2c6e5a6d93da43e8825753721978aaeb433ce2f2a7d67c1ffebfea6f6059474d3022817a7329d9dd0e4a292302e4a57174b9c5346e4b6d75d65882ca7339a48c6e7af776a8515014a20e4390f6b4f4a19990fa725f5a69b9c3bd4e8bbaeae49979ac19600a3cec6de154985e236c3d0684269974bfc82301ac7196675f618182d7cf15ee5ce3b7abee0deea5c72f54cafef203d556b31327089a0c0de94f74458cfecb481adfe3cbb5da422bd3626b00c4572b4c2bd7584acd9129a76c616aae51f944becc4682aacafb8e3bb1a42a6a8e5fe7bdeb43305a34a98308ef2d49ede4f41361446a9ae4dfc1ee13d12821be0b01e55b865b563633e5a19dfb6425cb60159c147b18a6419f5085c5d0882656ed533eedf97674d0babb6cf32f696dec0f9921cb3dc9e6021fa198d554b1d83c42a0bf214fe4c0431547384f45aed9190cbcf98ed8278e8a03d551fa284c8a26218f0b0b58d99879db98449cc99b6b399dddad9924e6a7eb20a0f1fdad2f8138bdc7b445bc01503c509066b1603cda76fe41727ab5e027dcb15032e8f66bfa84544d22c501aa6f62b02c0f8764387163ccadbf1ed7238e7f16c80e6c37afec2e10ffb95ab0a39784f9fccd8ae263758abe392727e9ad442a44738d77cb61a6b1540ade751130489015ae5917c927232eed27bbf88481f3ca0c5ed2c31dfa943b2ead4a8c80b4946e3c138a61baf43a72c7a25e16874cbae254d3f14c154f7c60ccf665b566799a01e0f769b60f73c17c840e0018c6fbc10eeda3e35a77586b3a5936b363b2d5cb25c78a3e3aabbb84f1e64df47f97ae1645650fe1751a724ea9bf80744d0f33da6f313a3cc17d8f261585b62a75c167126d899219a26210dc55ab6db2b94e6993849b4986f988efb07478d6621cbf4b8ed772e61b0246a5582242fa20339b2d6cb89ba1b9210a318eb4697fd21efcfd230de9680514a442a13b29d8cb2627a6970bb97bf09c79c6ed7a27247662b25f39c8d675b0747f1a6d9ebbf7cfa7bc51a7ea3a7307ea4fa2a463bf53a645fe701fbf26628731cbc18636567ae633a49e59f6f049447803fa3d4f1f79f38026de9b07d8610c9f01befb7054aa46e523e001c1ec3a4e7084de0cce596dc63d9c1f1dc03f35f9b1918e62acb2640102e1d520e900969d53e83d2dbddc80d1dc54bee99531faa5a8d2dbf8346c7ed123587353dd63823453de350545c176446845bb3522a862f5d675419da901cf7d2d1f7050abfa3237d42753203be251b0364379232d2d9d8642d52a60f6f4cb09ef29fa1e6069f97a1175f8447fe98a813cc182e33ffd8b8cad93bf32a60f1a9e63a79a7f7fb9162783b89bb57f3e73155ced1d0084d5ba967f76c89c61c1a3e944f3b6f78d6cd3d1139a315c5276493481f3fff9b6a6b40c920eeed9efc74108c6bba5a15da736680a23db5672c5a32abda24b49f2011f44fa8ff9c73609ec195025f0456d753c848dc6296920fc32dde2174d37bfbcb86cf618aa0d486ee46c5e1ea14a3bae4952af5d4837f9b8122a19d1e59b909aceba6c849c8b452cd6cef877a65fd83e6d0c6ee35886688f1d877612cb8e671d83216a1f76693d6a4d6a2ec13eb6ca2005328b3c91f51b352a707ef8180f320d6e1685c1ef4d87e3cb77fa549bc12727e59c11bdf8a9631cc272998253028cecee8a2914182b90f586d80e7ece370979bde683f37123090012ab9243a4c145d6349c2791dc44e54956c5e9b59fad017d3ea27d85b48a896671a0ac14a73b5ab9145d8ba6aebf9ea25ac2e8e2c4d16c5009a83d0e84ceb80e95df2cec4cbefc7f5b90a84d408e8c4855f9aa2987d9fc9d8a451f32b367bb1de5271ed35ea153b5d400a6d8050ee82f519bd930245a96c9727fd24d8b94dc53d4b4f00d03172cd6b7f2be163b6d16fd6247b01988a6ee6ce7bfeaff78e983b8ddfba4242730e52b57876e3719d1f9f6cbcc81620f848d23c31e3fff7ebf2afe5011e6466b1889e7ef6281faf8b18a012ceb96796fca9b28e78335dfcb85bbeafaebb0fa75ee2d0d391ca97e05f0fe43475135b13613206a0d88438f17ec8e604b007afdcb9fa1378b7cb96675e0b19dc6fb02508e05a7fdaaf09297a3884aa051b6389a52f921f8ff31970fb082df554226c2613b80cc1adff770024d6bf011c0f028a012597ae56f36eb6b3e864d79639810b8ba7258b18192b5caa80dea4b140d3c6f1d707acd2256d676ae90980ba80e10b44109211aba830ee96e1bbd248315c804d391a86ab7d4b3a4a37fed90d9867da4b93fc32e79403e5d78ae99af1cd2acce65d4f3384d9ceab71b1e93b99704c64caf17b999234361e378b9362d14be3fd9e6c268013cb1fa2ea8361749d635c0429f796eb15a685e31dfe7a76ae870eba120331ac830f8c486f6c0c4f07b658ebb9274a463e0eea101481dd6b58835a303ace802ae79ebef51add98a67b7ff7968815acf4504b9d360f7c0120a00aba1fc558e6cbd8324ec35e0985294563a8d7eccccd9e3d1557a09885770836eccc7aee0f18b81e30f85d695440b5bce29945cbf60ff402b281942d38ea33a4b03e9fcbbbefaac2c455e8a03ff3f35154132c538ea16f0605efb788c3ca8435f6d595f776433585094abc75ba581ec59af701f66dd6091623e4676d167000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 80","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028f3917abd3d4a5cdfae84674c788e7c11967feb08e6d1da8507b63d90eec9c018650ddd7c23cd1804da9b1c3292493edb6788f821bd24224a8cef50fcd7562fbd3dc285e9a252b235fb944f1712615c3be915cc69583378a3940de99bf863969dcf81d6e6f86819626b103e5cd257b7c959cae312b33512cf6dfb8914e3a7ceeb58c45d2685759651f75a97c37ed1107336b37e789218120676212e166490d6992c747bad396ce54ee7923f094a79f0e489d33f547c9e09269fa9f2b201125936a828a75115f57ec2fd5ba8b4656a18bae6567bf64f72afe224b0ba7649b56f4835b4e0ee5f5fcbd6fdc0d0753434fbce4e2a2bbb9cb66ef58b3f3bfbdad5769a81a44b896a4aa11d2673558cee2d5bdf66aee68b18cd72cad4246533d0401d9bad31afd56ce8309f5b67d93c4843b0c1e3b1afd9df4eb64f712535da16a2488bbd8863a9c7e16826c8463f06ff46ba5355832ca3c4dd0adfbb13e5e76159d6d8d524ac8e93f7029086a9c8a054d8b6928700ed10c9c57090b38803c2d340cd2d2a77de84a6bc8fb6316d43ba13de8dd6ffb6e4421fda641ca4a8c86417db1fd877e38a21a9f214cd04d244688ec768877110e354aaa8ea5a6d26ee252c7b2992e04fd0891d8f6440a2cc4493d3799672de461d0422dfaa539643a69af42f3cef6e58ac476f1ec6e7595cd4bb4ba3af76d76e9120264c33339f87e6a22ec310c751a5b46a3f3d1d96920b927f5866eaad22012a4b220e752ee52aa5628536da8ba7b43a3d499d3350377723866885ddcb755ede5dea76c633ebb57349a99b6bf043133fd2cf14ff5719b36c9574f65548424f260937a5af164f35376e8b9276ab12c53d6e13b3b285a4021cf256b9517c834190b95aff18b93213686084fcaa2250efbc3ad3e06254d8f12774e39e940000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810922aa6c4a882cdf3244f1b78bee7408d03ce840d6463cc5b37b4d0b92a199caf9efe7d3833980b4e2605f3acab79b8b1dbb6cf09479ed4a4bbb7c4b480eafff2b35b2c6f1518c3e46a2c1f1cb73822d5657916c300a1e67abe44d205e4023f089aff032b65ee0ed913385d2e94a500fd26d0a2a612320f732115d329d598d651007b9fc162857ea60303718b2b3e86d3744417ca1c8574123aab34ad629092e8f894b0692dbe59596b069416506a4cc2b6a0498b1d5de698c2ac4b683c89b902857d68d378110c3c41ac795965823884159507c669d21c0a7143a2a83e87a2280ae7c3248a1c908716cf6845c0a66ad562aa9e1e9ae84c5ea081e945157563cc4516c0cb988aa653ae5efab4e21188498903296a6d8212ffd27d82001eae8577ab022c49eef6fa64dc5d43f677aa1781892c650cd7e4813f82f6a5144c094dba4818072a8d36205cbeb9fdecc30c7001f8efe93b1b004e424766ec775d1f66a08db66340e2e6ca105283fee6039ce9a394b9c826f59dd162dd15a3144c986f460fc0db8c736bf2c03b67ab61115c4fa422057576511fb88fdced24b99d0371496300a918e57f4e298dc2fac7e2a320adc5ba37132073b531bdc44e0fd58682d4784c6c6b3dbacf9849d5bca1e210d949d7942949d71997156e1221a5b4926fd024b0f27247122616f9a405f903e654e4b69b3a480207b16130be1f1a1932e5b8332d49101d811b11def809ac05c5ecad9c4681411bcee94097aa399985a92c3409e5d4deab90376c8a509715f9308c6d55a34deda61ef6b14bcfff6b9df73156d3df1a6000a8021a7e3668da017bdafcb16229f20b93f472dc32e32288e8b86e6cba8c28041a0ae136221d947835bd7a9344d728a2817ae4ab0977d5d96b90249d088d9629000c774626ae124a13e3b7eed820084daf31caddd725e43317b03284b55a35a94562d3c7400691ceec018acc327a454d750a53da0162c423a55038bac96832c1974355f60118596fc86e91a542ba8a227fa1e644014ba05ac21db9ad9c53882c31357719b5a5cda5b08f280cb1a8c0a4b5c970956870202f87d109bd4788b013ac5f75ab780b25a633396f5aaa12003ac1e090a2c8b753642d5af55697bd9c1af7160c01009915e9ee926ea6bda4a68ba5930d82fe79f013ab33395f40f641274a5015283962c359f2673a922e8b3fa8b9303e5806258627d793ce06b15991b384e2707bb5e1d52e5394ba1c27867e4b280f526f65912c4b1b12ba3000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a9263ec08b711ddf5c66036a13f574bb7be76445a1d1f83c7732b9f4c25fb9e799d4afa55817bcb39b974af92f3730767ce7d863b6a3406450dcbc5e0145d10b7d532da6e80196157c38d1b6d3c173f74d67ad8df24ecad4d9b59921418863a38270b982c4392225edd1845aed2199e2c38b36c7e0e5d2f3cc7f6803926d977c59ecdac67ca290658e72bad633358fcdde2a4b9c40169a0c7cccfdd93e4da3c3838e9308533bd468a9128c5a141c4842840e45bc8e4610a7c5e7535834c5ec73312a50197c76ae984b3521883f549be04e27d97580e6d85d0ee84cd0b8c65bfb1aa005c607de82da70021f8f90b7912c67dc5657e1882cfa6da3de1ba4ed823789c052649debc9085c74528162243133a6ae5c1c6bca3f730525b167d816485e40c208affa8706e3d74631eb4413032730a7647548b77579323eb03d36c2ec37d2389d4a17305f607c78f3073a2f4b4395bbc94af163acbe3c990306ba3f89af9affe785c3f6d102fb2bd55f0c1044034d6a871293b31a1b38e383cb926baf3ab4b5f79a47e9fa7b77bcd58aa35a7f16ddd11ff642069a8a327dfa800049babaab4afbeec9fa98adb9796fbee925bb70ee9e96540436e1473e3ae4c56d7099d8dbdde755a7e101bcceb596b9415f52374c8a3a73ec66b229dfd8cd7ee7d2cf1c5e7f490c7d9381d9321b15f84f640017851eced1dc80d32da3a0a57adc3ef37e021031866e278c7d51ff5ca8e9ecea1082423b41d772c5adc61a8c71c3d4caaaa3433928d7931ee715875bde2bfacaa0a7f799b45241c21bd2ece4a5944fb6890bf24908de58dd3c76173373254a36b0b2ac7d67926948cc0136dd9a5079d776c297fb6a585c290d5dae1c45e91153299eedb731e527f0f62e83c1e93c75fc74f9c7e63311562b0a55459a0d41e034c3af637eb29bc789e5920daadf265f42f2707dd1ad490b5f8a8d24a9968bff11a0c364a779ec385a9a33edb9cfc7dbc672ba60ce5f421b40634270b982d619f8e7960d32e1b8a76cecd13a3b0214dd34214cb5bb7fd530058d5de1fb9e4e88adca05926ce1f5597100f55dcbf64d47fc177ff87c4bd9f6ed7670fa7b7d339edcce6fc1eae069e0c303138689ddfd23396c145b79afcf68125989c8477bfc318cdbd69d1aa6d3ee41f4b1f9be4be9fa58a072412078cb9196556ee56fb7b2a2761dd04120fcd9ae9736f599c8b96bf8f964b305530a6df1f94874f36f07962f87acc0b285eda64d2e4857e26bed40e9a5dc0327f1d91259292c608d6c6d59804dc23a34d1f9f1b69331d68771e41542fc5d669cbc3cd7f8310f87e8fe8f6201e57b475de2318ea6ef9f7d32a728a44334cc9df28df77038c37cba62ea8cc5ee80e571879ad111f35b6a154fdf8d40fc93360d547d02f0743a37ebc4af178c6ce36c92ce6b80b6350202d2978621684a19afe1474155bb962014587b1f5a477092f42bc446d7811c0eb439a6829e538077abbbf03f515f1e6ac018efb05af79069c2569d2cd7140c4b1b47886064dac695d59fde2d8fddb35318d33edad94ad4fd988095b1156fd59551f0658ee666186369bfa84e30672e4659bfbf7963c377f0039e08de2c2d9803fc12d97b5e67ce9536af12daeb3b9903d8d95f336ff53286284bfe8d7ad13ec21c2a9ba93c9a97bd7f6148de7c8cb41ca75a9ecc8f9cc68d888faf6b3e75376b5b16f41e7e6b76a686eb365365e2074fb1d7efb1b285a2357b020fd3e47b89943fbc1596f3fa8289ad844386a691f33daed4b7a6a6729526160f2d32ba7f68ae6678564fca05bd811f208a8fa62f6731f23d46027008246fd4bf3c454a39ee225245e74da5910e7937b36661548a55a2270a9d27114ddc94dd9b9d4122289df0a5700222a977f15fd8e36afa1c4870bd3ce9b658e2d83882aac5f3db814346240ff8c8fba3f36e52ac9b441c76b6f104a0931bc45e202addcaccfb93a486a7734a6d82b9f6ca911448f988626846d413d987c5ac860fcc0d5f734269aef88d41a055794dce832babb7e306f622e5eaefdbe1cf195e320a1aceb4834b3e70061ec2d624c12eb35b16e5aae73053a3290d4bb1f51ffdf48c1a7218d365db7fec15bf0f710954cdec54917600014bde3a901dab1dec0844d7ff148eded9788cc85c0cff26e5895d91c56ba6950c0ba8fc6c773ab4a6091a5de3ac335ddc2110eb0144fd89b3d815ef4a26f718c1acb5723af1da5515442a03cfb9d90623fb21d78daf441000e285e9e7c235c0f31e258e6b3feac048db652b83e07848d2e9357649372b1a55975b2ec7fcfed19d0b6613bfdbb4b5b01a9aa3128ae137bdc1d8ffc3a38b597578042cf183ba8383c289c3d92f6b70aa9b3364e9fc5d43f3cd3f310d229912e91d5806c2a11e0bdd208a2af438be77b43680e2de67918fd414338a763910e1316965bf96bbf7df639266d075e90ee9c073011f6783750764fbe4906ecdd94ee9fb7e4aedb23ee88ebfb018c44fc8bafc66e6b454a3d0e332c7a6b34c2e8d1d26416ff43d768cc36ca9d3168355f1a281a6b2eaaeac7b64aabbad2156a1d781a78a896248c56f3491a5dda8c22c231aa7ae14bd558f66e6280fa65f20b246d815bff1d3c6cee6df9b4aa7f750307a7bf73850e6bcd22ca0ad74b4afc13cd4aa2fb7e7b588adb3a46a23ec88a34f13214b261a283ae8fbce8007c6ef6be255c33218aebecd3ec27edafd252994b70bd67407620d26e8567f4c7f6d636803b6a27eacc3b853706a8d57adbf7f7e142ff149c35119a6172d5884ede7c71e6c34d1b485a684dd56c9d670576b75cacb870a68ea7ff2bb461d9e2fdbf500b2f200110265a3cf24370a3f480da66f98fb5327b4cd796eaf0e559a5519f3c643b59e3b89d05d2a9f9da6732cdc2996408b7fab5a734310fcd73fa3fa5cacaf31ab04ec0b9734407c6dc575350212239ac9092da5812137bfc40f7735bfdf9827f768fc0363fc8c5739c7df828075ea2bbe6321d5a8ea2eb7e397c3d58a953c7f0baa69a96ac8110b125ee2e9701f43eeb87fdf58a6e6266be1136437599e26e8e6e853dbb6ed9df3931c5f402fd09b7e203ab36eaa6eeae72e908bd2b9cfd379bc9b407f0c882807bbd2e91f920eb24137002a48f1aaa0cbdf89fde5c51079f1d8cf7a014207f1b40773321ad952d77ce18ec7b48f2ca054e65420c1132ab67c832ee22ffd8672803cce3de7e9fd0690e55fa1af5f11611e3e2c71ced55e3e347f4cbeb9c93bec2b98e48495585392471af0ae589257ed8d01792112c798bca5107030f207ce567594b8433490d8ff1811f21b03a42ad0678927183321355e3d6908dc1125cdce038cd0469d72458b6cc5e67eb0d78c20819c6f3c4518b15cc63754ff8679915e329dd46feaefda5249ed7e754e7bd55c75cb764b6cc36bc06267b2479cafbb3f0bae32a93558190b65c85dcdc080cd56d51d4105c5b0717691d4db1893ef8ad550f55855b4123a38d18fd67b588a3a4c2a6604e874d721359352b235c17ab1da2758712af8179ff433211b93078735f909f985f557d0de52cb9203ddc67bf9dc8632acd8d4f90196af6bd2e79834371c5e9fdf5992adb04aea186af36f56271f763acffbf94df4b0512ca6b7ca8ff486504e565bda367e044fcd0f25fbc2a6c720867f95bfd92109780d2e6dd60ce90a4ca8eeb8c4cab289dcf99e687b017b37695c3b99b4fe97d7e5d52bb9813c04d03c9ad71770fe0986c7f3a3ffd3a261ac771de88c7acdef253e5ce2b50bc5c576d132b68ccc694ba883770b80f5ed7d527cee816527f69ca2c101747a0088879c3663037db5b0000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 81","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d39066b7fd6af8283a781ccb32fb3658b268680044ad7b15a87f759d02fefb8bd5a089f529637702c7de12db83e877280dfa07c12890c262976d350483fbef8e65deb6d1cb4ca8599b5625a2a9524a9e61cf217c956a9dbcb9f562697c28884fe0d91d81b9bc20fb33fb6b86f46914212f9099ed3cf2a91fe37a167c35b8fe4e5a4ef2fef656bf4f21d26e14e57f2f8aae7b1b4d7da60b2ad9628645c99f6f3e4f449519bd1a264e0c43d4f4bf7b41eff53fc884258cc4b0cb7b5cefd0dc6ec6eb3394a97e6efa099d28bbb0f8341e7493d0fbbccb1f14b31a6c395128a88e9bd5ace41488fc85d7bdcdb97c28bb256921ace630c7fde8b82bd20acfb9cd67249feb0e44df04de63b0db94df2881c3453631d135dd44bd060dbfc75d1ffe26bf1c09f187c7cb052d854146e5fe52d06da94771ba8a131edf2fd5a8aa7109aa54af29ffc24b9d3749169bc2bca76427324c55982aaaa338b3f27727af34b8ec1a2497434b5e8bbe927009146a0581e5c86f71994c168657e00fa45b7d69cd53ec38faeba4d51d4f150f07a644a819dda79d4651ccc393af9612edccb592466b787dd5f785ca51bf71743782cc9276836d49408db28441120ddc06a59d71ba68b66e08404d0bee302e8e8d2a24d0bceb3455316f1a77fedb62133f47c33dbf8b9da64d3cf2f1eef2a44ae1a38e1cc8f7397be2e1bbb38d4f9e0bddd0a853090b9d3b8c6323f752fea6cfa30574d4b873cf7929b121d8b55a6756aa9378e3227eb733d79d8c428ffc3f225bf0c8f612908a65cfb3069ce88ad7f2c770e6d7d0f47e4e4313da82239658586956eb51a0c622ef767b63e320d2de697be8ccb0f4575a4174514c7638805da90d971d92e07d69d35f962736bed376bc179529f6d69578b78b55e6f66148755542da13b80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381092d51566b5bad4d881d17934a9a620cae4471c2eb5daeb1b556bad7bfa426376634e3c1ae86c889774b46a33a10ba176a5eb3e618240d5f4c04290af9742a652815a6a454afe282f43fca33007d1f8c87894b6860ae1c05c4d090171a6212f3976e7b96a2efa1c0e604b6a9328bbdc9478ef1ac890beefe777681c04999a47681fb7999435e3c4c0ff0044aad3ea22ae669d8c1acf4077a73d2d19a404b63772821af0c3119720f278c2434b8daad3f5d5e6224edc7849750306a2e9e1db2588c91dde676b489e5ea8f9f069506bdb2074a5a96d6dd423f1bf09daeb383f29ecb215a3dd3542273568de29a87980700914b10ed04bc22cdeb1911945889cd0823b9aa2825a6895b240d56a20e9b7b81c7c051cd88fa0e0c9d69515dd66184538eb06352a39dc17ce8f597db6a3c5855accbeca39369159f228d2dbd696537f6110eb302924851a85ea767f0a7e9e540b74c45f2f9c4dadd8594fca87e1a1d9a047a87a39655535a0bc568a9c476290d65c3c3b89e45a643ac64d5ab2a4388b89bacbb16276b8e6b7c7821cce2f21dfa68b830c5d8e9c19f3a96608e6d3590b2915a78ae513b888cb41e287042e12de2312d3b5356b156a2166943858d400b2ea07b485113579c4f81d2c8e51e9acb94b678739d83c24391ff545a6cb6282a2cb4f96a36a90c94d11f0c75707872918a2bd054407ce4c1cf0bafa89099ced89f2b20c89588af7667469709d7de374f80a1a7a9a23939e1e1c92fe28593b1d8386e532d9a04f29bd086fb058cd5b2db93ce810572c3e9d820b030fc27d4a66d6ca5fac7394bc39bec95aa39a4cd85859ef1b7897f27c9b14246694c039e2e0989af8278d19b02485df2843a510353d6ca652a3c102280b7451d19c0a39e42be89ee296b4acb7004ccb9a6650e99466e58225847b5a8e13842432306515287564ea787d2d72bfa23824a3192142782cf4bb148379ce6cb0fc01089e8256927b28887a16fc72632190b52e3c410a4b3906b6234bebaebc17ce0a395d452e01825968f6cba44e2ca4832c2d01357434fa45535e31cd6f8be0d812a44a68d11ee8c374a8a8227c2b950ae553445e655266194a48ed6d1c9ec8b7263e474bba192695df0541a4e0821bc30c90b13eab23924155b045c6372661ca39aa944a8141b58d5980d519c5088d4295779e5fca8be0312bad6961ba285ce5b1189bb86e44552d0a627efc01f1ee96821d9a26047b4863526ebbe91e9b29a2edba898b01ae21e05ce000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ab37785a08a3892c97d5ebfe52475298ba444674086d63e17e1faec96f6b10723447fc1b8cc758d1724a33e26518798183a4b3c99a7da54038b86473dfab8e626eb3bf54de5581e04450b2821f5020c466505990b173db9f030cfcfa505aa04b37cf0a063876843a042f17aeb1728787187428f8d1010d532c94c7ab2e1193994bff0cb56415fcd2a96be7f7fc2c57c8313e795367a22b6a17ce3b803083a74fdbcf030d91c957128099d6199686f2bea618cee111aa9d55a6f9e8966c102d849ade596a1b576924de0e92dd91fbb01cd93e24aa71eef219a78430d84965672fe6af091d46dcfa9ab906f6240913c1286ee0a152666ecfe2c154cd3fb14dc0f9c173e30fc9958a75aa6dd74822af7acad243fdfb743e47e48280990c2870904ef1c902261d0bd6bcfda91412bdee9a28c628f218e7648aa0027d918b48ef30a9b18390331805c6739bf6a2cb69a0de8766a7b3a448910d181f6449565a363430ba1c0fa8b11e1a151f6cefa3870c3b1d8cd800983ebd41b48c5624269efb440df23ff9bcb31a4b02f6505dc862b2103f76137fc6560f893577bc3fce92ada27f291305f2345ac82a846854f172131b042735d4b76c6ab2dcfd32bb6258b23ac790af2af7624451172fa7a29e0c5fdb3dc3b719b274b2838ff7a8b25f272ac8ea90fa3c8010ac7f65633eb43ff7a0a95ce99717f35d3c416b0e0da30470b5aa20eb9e2b66315b9407a4753df8bf505b8066c5d57ec4ccdd2236b9c58bd7337925191ed7b75b92c9cee626f13eaddecb07173c8160540fb9f6a4d43a1e9ab263b300c08966c247514647dfab3b420202529e963a51f8d23bd0f689bbc4d67d5a603b876e8cd3ec0770f0d9694dfc30083991cf3989db1812b4ac5452358075534190f012f7c0e47734c3ba748e04910783c0b845484461dcea67a1ec731354b902557486b484f67183fc711d10f906c68cd01f46481d040f084271dd784e5b958ae05b65bf5d207efbb5fdeb25366d6ff4161ca3a1cb71b2b9f90f86a315d800935ac0086d85d907a036c4333ea347000a0755550b68fe3dd7686e416483781b563680146697d6fae8333c24adc8a2436852ddadf6061e2b16fd3829c0b55c2e9c2c89f64cb8da02a6706498cf0330742083e9ac4593a1762d32dc4e6cc2d9f4310014fb15debbea324ebc2ea1e1660782559b9b39fbcf34c85fda9ad350d195ad7587aab621ef7ffb63277ce35ab43b01977c9f8dd6c2ae7b34fa7b35d5fa37d8b3719e736f18734cb3a2468be9ca0832dde0b958925a377fe6751c4eb8ff1ad295355302f0a5ed4e8f8c33fd5162542b8ed7cd985dbe3c84401830f6a7eb9d955ec74c7f98b02388b4e1353317cdb5eadaac9025038cc01f8655c7fb9aee940fc4b282748b39d277a7fef462038833a9a8eb50a8719f68b3e858825911f294a80faede9d4c1815844c2632dd20387950003dab80b1a58e541a5e6658af7d4cdd91fd1c08735b584f5c69c5ca94f6b7f97a4761b127db394ac72e902db9eb4b3e0b884c448ff2763ff9add530753263688cf92bb746181c17294bffc2a0b3969a7bba429a481c425b24745cead66286f5df04f1e4421c56acaa668e87ba58e3b07a062d1da60cc6b411667bde6f466b72c9169965bc7781da78a818f779a9b3d7a577f71a1df49aac865a0d6f2668cfd2c77cfa8d306a14dbbde4d3a3818b07dc89d5f51e117f7bfd007d60f32bb1b6bb01e76862398371fb91e0a3d4b39fd9146c47f627a066618cf83c32e5c82592b418bd2f5dcd8d42234625974f988a6f729c60ba5eaf18c77b611dfb187a581e3a10268a965f650fe242ce2fe08aa71515b59a6edfc9cbdae22df3aeb22e773cc2eb373619e9cda23c236ca3f7845c2136e93849d9f6aa1477f4513358cd8cb4e21444c9e5709818801eadfca23f2c23ddfd5b4ebb6089daedd14a21ebf3f7a8c1c80bbf7d37973bd156ac5c4462d29dccb7eeffa22a8b6ce433b600532f33999adc39196f01230614767285089fb262d8469dc66d24ae0b77fd05c3ec02fbc5ee328319409b8e2d7b0ac6801c1c8ba86f793c2037c71e2a25f114e9ee0edb3b83076eabfdafedefa0548dae91e62cb7c29c03413235b8c6eb9f46be29de8f5d30e8d97db6f45687dc4719b1024e48b7dffd0d2b474b2032b4e69b6382e603d4777f3450e2e467c6d9ab2782c0ae266c320d36bf67bd6b86ea9721b22741684d9c0ccc774335430071a5410c1e34b4bc1a823a93a38f5ab4781cc593b13a593867fb634c0c705107cd278c6ccee6d842748bfbd2ffd205c6bdfb3ac87f693c25c832c86d96b00bba0af88dcfbc8ca4328765de27fbf1389c4ede28317bd0ee447f030990e957d223a5ec66ced9d16400af6da8663c4e4111b4584f8f0066cdf8258d90c5d7b439503e3ab3fcc55fdf933e06d704416187aaf86e6c39695dea8b8189ec1299670be03b6a636889cb7f10f04ccd67278e77886cf3f6e2a05ba8d25ab8664ea817642acf5db4d9b3ef80e169463edb6bfdf67172e88d233609b091bbd085b970db8ae0daa5048ca42d6a54042f42445bab03f9bf1accef341b7349109ba0073d3715a9073ad9bed258268aee9dd5202e0edfa5720a317ea5cb41706c0d235465becdc8e3ff0d628ee5eea6aaf1bbd3e18fe9217516893df115e979c4cffec494988b6f9b86026610898c44ab1547c5f8ed5cbf3c3a837ddb6a444bd3e803e1824e6ab931310fe86b36587f1b34b0b48d358f4b97e9774213de7d92571380be2199e703119c5b9836dadfc826b71d588250ac37de0ec05c5823573c102bce44c9f044507671c4e1723950a3c0e14968cbabbfeeb049eb723db9b23cdf0273525c29cc5165530a1f1cf830d3551dd6bded53954947d5c334dc9c71907cdbfa109ebc52d6305477c14159257af8c51c6f09d76fc0085c3d969ec60fb09145e66a8a7489611db3fdefc35202b8aae82d3cdf666034beff49fe49a45c5ec438f4118f338545532ced916de78e3bf82b4e55907474386b9c172f393efe895334f7323cbb2aa7ce7718bef5e7a23af734bd4963fbc7889aa5c50f3955b904b5e577d71b21a293d766865e3f8c212de5ea084a9d22748a8009a7d1858328a1bdf7ba0f4e3b83be9707629252b3339cef796696855a574b4a4896ca68c3d6a6824e3f593069ec0a571e61282f8a29beb8bd788f7b351a8939cdad9e257587a77804f2704f49db3305514b85b449aee56ee40cb2a75d51690194284aacd0855b02893f8dcd3091629dc548705a1085e5cc33de7726a0f521c149003df380abdae96bcda55c44bf9bfa1103150f049563e848a8750625dcfdd9bfe02e1e57489b5b3aa28beaa80f4daa562deabb4bb6a27125369415885020d237a92ccc3a23593fe2183225bfa2ff39b0bef9cb0425375e256bcd572175483f713bd38f937f2b3d4c1f686c5af60061e0b05cc3ebaab0ae8ba21e47a8318bee4a01516046363d152936a1344e17a65e08030522ec667233145a56001b8d065dc2fed0d2a9f02c981a8962f984916314805dab644a5112caa1564895121d8b1fd046f547be282cf979752883ec79af70cf59a88d960f3336f0ae61357877aaaa34699a876144b65ca5b77a684d850d09b3d42cdbfc4539ea103f8377cfe5f9e5432403fab416662c4c83226191eeb7f82b01e0819c081fc40e7b978669c7856067e8b582832dd0b92588103c2616ba2c7774c46840318ca2b1a3798ff7ed9fec087f01798ea2445b92e67e2446126a7406e82ff8d3711311be16e9171531a95c966e6befea34938e6f5fa660f7c7cb533a119377f1d26ae6ae51d805ab96a64c8b80d6ee137f634b384c2e37700000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 82","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e000000000000000000000000000000000000000000000000000000000000002913961a0df9912c789f1d81d818b9433400db74f95782903e954db5dedb5c5150caeca3a16b4229be97bab66159c96451e439717de0f4b976b5c7aaf5dbc5f9cc53689a564d3c3eda073cffb88dd3a3d9ddb2a5ee0b8ca7ab65d7248c51e2f2e3044009554a58b1535ea47d0c5474950b14e73491e271eee100a2e332aa3cf63d9c6be0bc94cc8df237d82f45962d6fdbdd729efbaed57b589c8418a1157d269c4da9e55ffcf115c7eb332767ef938421b980d5fd6454d4a89b8b1529d36a93d4690d7f9b265275fa66a44fce5bbbc99b1b63f50342d91fdf1654ea69e1ee6b32c30fbc77c9e1a0afdd9ca4e67097fbbe9c9205921e33a648780dacd346f7661d4287455c1684511c3651a932c09a541e0c5618e274a03b523ce1e8fb5075c1578fb8a69a574f22ccff334b11842c17695f35ab15ed4bd24daff77c6a12430fbffcb8a5c874b987a735c45b5489bd8b7b6c8d9fc582db1640c916e1d6ca63bcadfa7175699cdc4d8516993abaef14dcd43b658f718f29922732de846de5d27bd47fff6756e2cee3413d9ff4e168be13eee1e4a11b0275075d3bd1a6fad4cdd1ce2762879d30d8db4df398863e99469cf47405864272e34abbea5cb28d8bc5830d8dcbcd86c5575f87661f60bb542f28eb4d23e0cff7dfdd799d8138ad0455b39c63e79c080c01564461f167557f80f16ac48042b1911e2a9ba5adb1ebce7b7d444a19946880b574eafca18ec2a49e4c354ace5891ca4fef1d042f51f90167399d08650754ab468da7bb30e2e8bd2c3c6ab58e45cc12cb84400e9984e855774f1429307fa72da70bc5129b356cd28ea01aa47a27e6b7b9b9895537fd0b419164429a35b8a8011e6c50a41c9adf9228fba6ecc9e3dbce99132589d89b133ddd05dffda02cc2add663160589aec1ffdb38924d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381091f7e16f467227515e29af3d1a17f2d1e5c3ae2c8896a4806e96acd393ef413c5922c605ffe2242f604c9657cc384d82a9b72594810d52bf83ecdcd34405e6760f98050b2d14fb996479219172d82823a9a36404d84246576b885fd4f86f6005891994be0f64a2f2c1f36b9d6ea305d8a8c065c43065ef4129aeec5b96eeb2054b7714868233cd23e88dfcb8b68d5d26bd8db4f07922210d2cc86b2e5b8539f12178621b2e4bb24bc16f6d30215d7e15e1a2c29362ef828a0325b35a895ac05b34b37ed80509c7929ba9153b28cb2f67ba619045556f5111ba711eca6f0949dfc358d38e27a06771082052b42e700be423de31dc4be60b2a15acaafae378ed8b5c093fb6d39e82b2f15ea8be9e03052a07226c51a497d0be255c93fd29b59289b9a61686d97eb6c752a897564045b081ce55f8cae01a82c0a32916975d89ce5fd96a8903603c7494c5737228f9927aa282d18c666ed660d460c4ff582268e9ce42b5586aa6b67b4eb1b53c50f1f95694a188ad8223ef33214d0763dd893b9e1023579b51d157e9ea965c1e60a22ce7db379ff1849c42f037ef860254dfc4cac3af575432689dcc5248186820806a63311a4ada396e0f1dc8d7965e46a238c2f549640a708ba1d15be4c9bb1a7d2bd93a8b620736ace01b0881716215b240614e821483a6144d0bacae67958cebc792b9e7e596efa01750db625de7a45f6a2f7415cf0b486597c1eb65b24fb1e1aa529795a2f039363a58fb2e22111a5cd2e4931646b2184779380d2200b4411756b4232766c1fb1395a2840e892c6ceaca714a28f1a73ed363e650fea9d4200854201126f2f11403474d5f8a6306b8cf425a21b9a0cb8c03af61b99630102b92d93d7bc721623f6d18845de62a7d3070f27fa5983604e3070b08741d91f7a8f0eb0e6d9da30674dc16bde179e557e8a46d26eed903a9ceb839f264c765c4661aa97a8b550535c85fe905ef395252e05b69950d940606da9724c74234fcb23b2ee231d827e384923b0da6146957090c39def8d2af5a08281d1a3751af861f523c81881b2f0274aa21452f35827e31d02e0896b9b4d512dd0b89654436316709f98e0ad0ab5a444e9d0985c9f19a7c5618f261204b3b4711a397185cbca45996841668165a3d2f567885bf4fa8eb4a3b4d14852c65f8be1c6b18994bb07a8ee315a2bf50f504057ab95904a06cbcb438c5c53b0fd97db6a499a3138a5db0a126bf42368a14c5043f204a680d5396b952a80a826b2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ad4ae3dde9e33719040345df8ea7e4c0b5e2cbc5cb80b34fddb959e2da1d67d74d2fbe5aab07c6357a9f3e5f6ef5379b4c75008e9077a1eb025f9023fe32fcd9076c8d2b291d0becf2dc624f9e752b1eea2cf0755fc9d4b2e4320dfd042c68577d58e61dad075bc1c3931aba78b473c0726ed495150d6a11a81dbbd1c840f5f1faacd54e3470e0d994deaca7e6e324a9fb4e581ab447a4ea026da3dc3c7e6ad55e88cb841e069eca63404cace0e3d4c8b9cec33bff6aa6341aa1eb69ad799c6cce358ca94555287d01b0192b1b49eb6f705e54fbc86465c4ba70134afc9a53c1c3a732e21b010002b49b7cc6f5237b794bc1d1f1e30a7f1eb95d195d5f26b46a704f77f80b092117ede1c340622ff32302dca7e7e43c2a4d8852cb508403b1aa8aca27a86936350264811550dfef05d72542c74d6243ab9d259202295a63f54c836cbf610e40eb85e9704041a51bf68578b10f7985c752dc35788e7b7754358082afec9e4b271d36974eb90a46f7d703b0cce941c3cd072a88f931a4ffd098634be0921d089e46637f88f9625b7df900a276b4bb75fc75921c8a8b6668df9946290e11fce4565a76d39d8fa55f324253ffbbf81536581621dee664a9e9e4f4fcd3a9765706b8ea833125a825b1cb30314b7c6c78b301638ead4311932fd4611d78572180ee441648f8bfab869874611c153feeff88a45f7a98206d0b2d97cb7ec2144f045225af5a9925ae7fd3db017e37259b7a2ff6c66820ddaac5651b2ec2e5767ddbbe18256b1d0d0f96cf5ee04266b8adb29b0ac5d55b73e1eca8fe724ee174b76ea1c0a54896e2bb565075f1669d3cca171657b66f343a634f4250287f853b52182b9be50df29021673db1841aca45e7263dce653f0dd84338e49ff5c6e3bb42f1a3c7164704a2a000149114d36bb9231606eda06c712a904c1e323c4aa3eee0bce6062a9cb956e004407014adb58eeabf486b38570955c30f2b5c28179f86cd5ffd603cd441a1fb06519368886bff9c2c127abd079346d762e51c311f196d5f825b45eddd4a48c7c2123e10a3d369d772750987edb96968c59441fb2f47f8e33fa4ced3006766c06bb6b339ed94b8fe57b20d96f1a27a61966289d8ff5072fd11d7ee53defe0014a11667d0a6c988bd16629fb53f269130b22a13aaba2e9f70dcc93d3bf6e611efb006ba585fb8e8720357e25df69c6df388fac792f87cce801fa49a8cbead1698c11b82c4f85fdb4d52a2a808483dca7334295bb3b2658aac18857878730831622124f5a254a464de459f3528c5194220e5bb1779c8f5e3866b0d60931a1a47502d99e2b186785658def57aba676626f9ccaaaf449609b07af7b57c78fa5bd06b2ad2927ab491ee461a94ac37a079d9bfa02203b09f7ef180c1c1c430518ff2d3f2a3582eaeb6668060a2b544e973e8a2b88733a902a0a80f8e4f30ac5d0223c1076482eb2ca5ae67039597514a4866061d5fbdd99694a060d0d0ee43a1b7290ffd7d796a9f1a2142db6e0f154aba8720396b6de939e668447c81cc828ff9d2a014fe001ca718c1d6acf4c08bc7796d344a29fd8913e4ce71e986c46bb66c2610fa797c9e1639df423c338d7192638f621d83a6802e72e38bee3aab064fb606962329997fe908597e7407cef098d4591e5e6011caca701994e4acf572f7c91057d3da06058a7dffd3248ee3333208bff27473e6f1ea3914c5b2056aecd7aee07f8dd26b3c2b8b9656ea4260d38e8d5f23c925a4476754240d0702c5859aec2329e1cc3e426bd7665b2a4ee2e75b41b561fce79690f64d1068dd35a294a8e8cb43a6aaa901109f0e09d985b6e323c30a017e75bf01d0aaa739102c1a6667ed48e60dd4499eab862851558dfd17229878f5bef0cc29fd19f59835579f3cdd4f85684e0d46d9618a205de3b29b0bfa5fbb36745b989211e2ba711527d32cbb5e35830df4549fea652377ebbac6d52787f9ebc3cb687ebb641bf51d3e22e98fca48f99584fb1f3bed3f97f33ebf656c5795055268f49985cea00819a07b8f4b0ecd7beda95eaf11e3498fa7aa414c54c38a08a841b012ae91763be911daef803e2ca385c9d4cdc642a0b343db6534c10d9e1755b7b2de543afe1d3c90981a7bd907e9cb14367243d9fdcaa8776aee5f65ed6dc02f633bcf9f57dae39e8e8261dc10029df7b7124beb67dd753b36892481ea7cc54ddc3a60ef8d4dcec4d5796dde0e7453bbf0fd93fcace97ce5048d75ed1f34b69a392e1734e262b2b2a1e246331a373b5cf1fee7bb46096c76349b0f19be63fe539dcd33a8450be894c2dc21beff0de6a841a533f4c9949289037d161bb97dce31cdff4c1e0ae36b4192594dec3b021e8f3d5b500c244cb122974f8cadf125de0cf832a920dec3a6f7150585d0209651b0faae0f74a36fc8779115b96136805ddd4f6f3a69c06af472f369f481359ff834a0fd2f9ae899ea36b9b061b63d07c1d4ed7a373acc40ead808564b05fb0c6e656a80fa3865aabe483848d14d1dfd66d7ab1f353642ee3417869da21622f6af551659d07e6c827c18ea36e2c5e806a9571a7b05bbc1ba283a8984bfabc555aacaeab2453573f782a4087f0f903af34596e83282a2e54773ac33543bd353a3f855bc46810930c3635a9b70ba7ffbeea95a129ccf9e9538eb11e119a072f806130d831af7e57d332ac889d7d9e6bbd1c65d64e089722f6954f126e64ea939d98084d434ee74b55c549bed21d11264f8b5e023277db52b03d7b8a8e75b12b11d62052e474e435707272d72d00d92288ceddcd1abf8e63a8a9963a48b54f492487b309f69cd90c9ff54b9c5a55cd2bad4a2e0a6b00b188fd6c527a8184bb63670bf626a995815810cc0f280131f5f652ec20609c7d3b910e4168fe273626bf0e2cbf05bc9ccd178ad91bc25cdf178b387dff0b6b40a46fdb6c975349b6cd8ad103cdc5dab8d09d9a5b55622e74564c1e789c5c185cac04fa0ed6065b9ccadb1d5dc80e90ab244ce1aac516b346adaebaf7a030d66fb90fd070ed062a41e0b70bee3b07f1c03887de5f79d70f9955b25b8c8201602784ef8a60147260d1bde8e152e8d3f992cb8255adace9d5dd2e9c856c47537742094190aa867459d20989db11841ae44824979c0a2093d7edcaa13c9de25e6eecbc5124055f17466467e123e39034502ba966cea873997ee25e52de2dbba874dc9ac222b49967b7bedb5c81be09827cab782f458795b2903d72ab16f4423964f82dc69c138eefa3273bc10376939e544964150d9df09e14be08cfca06c10bb2c315b1b676c40762f8209c0ef13cfe5fad76cfc17fe462d8330f78bab072c5465f7a26d047fec4bd3b918c9c761b91b02d820ed7ef345e79a66fba61ae13d3050a27488cbdbe693b800f1e76c188ebd8118c9432eb9e7124d35a1a038d237918f1db83304d10ab5dedf58c6951a92aab1a1a40e180254e730eb43b566a83cc71fb6b9749bfcd3a90b964966cae90fad7406a8a89b1e48c885bfe2db41c1996f20dc9a8dfcba1a6f2f307ef8fba5eeae9631c2d6328d90f17679dd9e8e9660d6bd4c8a1d79c47a5fd46bd2accaca2d5c6407b0f7f31d093ceef0342c67dde3f1ba5067ed1500dc45161b8636255924bf007c4c870990c5dce098c5a26386ad84d0f0ce4860349a147a4e7ab80151fa63882590b91c6ad3e70a68e6fec1a2cf65881a6dc38048fc14de71c702c934c5d3c4cf4c474f906c3400364bc400a7da087f94f1accb68439a9a6ffa8c6439b2cc5c0b17a7d649033798429f211d9de12b24d117583e1c425c2c0348c625cc44e9b976d319e72d4e09d5d6f36ee243f5fbcb190e84de56eb680dec8566f5a2c7d5f595116c628ca09401d561bd78356c634419225fb01cb637c46a627f6026d39ec1c62e9a3e85fae000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 83","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e394870f89aa188a6e9e051e289d3bfd3328374fee68f6a87551fffc636ef26efd271adb17503ae02feab84e6d863990387b42fe1ea6276d0e9f376d3dad2f79d7ac0dd6adcfddbd5d5d1bbbac26d153eaf6167338dfbd561cfd618b3fd886afbd1b981113990eebc2c8c70b8096eb295a17a299a2a573d1d8e0a4419a9c6bd7afcb524e3a3a8e66edc425c9601ab6f363f2c6357a5d1e2e5a867074ea1580c0a12db334fc213a1cdcf7ae974bb6c767dff7a7f8beb19a4387c021cdfb3dc0b8b0310376ee383fe8fe9f9eb07a23865a28f638c8d2b1fedb6499143b468ad917cb463640e1b930c89dab6e8721102cb36b1855c6de0e9e748d4af8d833cf0d42eb1935ee3f0dd78567263d086c5141702b3f3dc316d621996323fd519a35c9c92f79fb393c568fc429cd4e68cdbc2bf46d92fdf0a066b1a5f6128b4a62a24f14c00b6d3141d28dbe6d1883947a86ff66fdb18c6ff5d88aab9b539de7b95f4c26aee96f8b50201cf2433d1b0e2c6100d21d9fdc2e32a22f8788da73dc18742195d7122c30d4a814de9fe215c3255bbf440a3f25efc4b8e9cc5a17eb56ba05948ed2ea101edc6fd4853076aa2c22aaf5342cf19449f2ed62d8caef994cc2298654e392884dc173bde847f3dcc8c12bf4a56d42f5307d88ffb93ea02f71542a0bd76bf1321e275e27bdea690e123ed4f2e07e6c0b08c130d8d7d34f383f8a4c455ca4dd53d6014e7264905f02c5c9b9f11164e581428a5cea3824bfefcc7786a917acd4fe8e88af5c280595bcb826e5f7f3cf72497f0bd456b3a8720f0cbdc465895b59c12da8cbdd7c813f916ed5fa2d53f838cea5f58ff62cca3a54c505e2b7658a1fb263e7e55aea35b84d3741fbf1faf5455f82fbc2fbbced6ba8ba4058de052ec39759b40b735c49fafa5bb5ca0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a3e69b9aec1a1b4d7d50d861e0e1a2210420d047e1314932b7fdaa933bd000f524e2d8731ae13a8396bc54586706d189eb1659808853a37f1aadaf14c41e0e2f196851470db25656f0c754a3565cd44d12ca1617113c3b9703c9dc6a5cc494f091317ca20713855a2760b6b986086ce782341a51c8cf1a17f04b784d4fb62e95e4331957bf766cc378450a78876544873e20d68cb12d956b96e97985f8a177e1a627d5ef599ed5eca7243b53d2591a19fa92bba4de2ba53d8586e044c93306b6709367819b39a37046e9ca8d0e0fd9196daa01f45618ef91fb14a485951de27d711d03d3c4963d599a5a22dc10d79ec8dcd7fed9bfbc3a49eb36621c3e9c60d01f5d162de065db1c68bda2603ac3f0a57f86aa18d45a64c8bea0b6b64acc3b1e01bb22d9a712ab7090913505b49b91eee02567f81ae199f7dd55b7af3def3009d9413080e431e888946d25f6a55892ecb3a44d5b37c3f25cfe9feb0c27336b504ff7760a294a6ec8cbb9dab21d60771467af5997de0b79ca8a9c2ca5998bcd895e5509827226a7144b0c18513619554535856b5360460d742143e996da59b2fd20398b13934c7a48135f2f6539cb03a64035b581fb752b4d0d86ad18d2f14c84b4800ca5acdd487fda2b71001edbb2d579e2b5e0cf45f1b3d1f9aebb5da255108b8b0e3f9ae8717d42b06a0ec8135a9fed5e8633a52325af2cf073d894249f65798e13e5abd38b297e57471084bd5575930c474c95e4e6b31229406cae5d091828d6422834a8a5a08c4ece0cf530ef2a696282c1d44dce3f0acca569273401c92191f15347980d6543d75a60be8e217be8603637e6d2588299095d71e11b2cd1bf7a3929c599a15780f9bcaa41ca4a490abc2bb65e4ebe5084399ba4804a4d036629d72b5795b141c28e9c9eba2e5b0748d309bcf0a1c9cf0455c97535c9c99a3e5113b363022b1decc0006746b814a5c2011996aabee1ee734e4ef5534cdb9aa0afd828e6f14b6f52ea57acf955eba034b52ef7019b426d58097ed44c276391752f98b7877ca88942e33056ca52c9d8c291918e86588b40a8220711fe4d289018643491dd641f47503d6817da0dae35647e2ad7ea292c2a0e6ee77d923854392f71a5e5617501b4081ddf6c80c8f91097a1ac0b66fb80c3c7a352850dc59c254b8620dcfad94deb73e524c76bab305d3eaf638b6c3f85141e0bbdc5ed8a4c288a81ebb722dcdf084951e346ea317084821e459ec959a595cd2945b26098512f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000af5a7e941d3c14e2ddb4f971c9955868aca753a73e8ec6845ed6e9d3b444c826480f03ac771f92e94380bca7e50303fb79cba608e351a1a67bf217b9816e2af9f89be8a79f661470ca16bfb2c99efde97859ad1d217848289eaf543005f5c231599ff74299ec2a7c737ff94b7465de11f80e17d4fda264de568d8767ce822b3ab9642d95bc89533ce05fb331b86e3c5a296e4ea4c637ea458bced1f89355c0270d083d4920e72112ca1ed486191748b4f730ed52f9803d05a0f2f065be03b2603d6cdb154dd7765847d656b919b08969e41b23f9d376135bd5d924529410392aceb004849550e6cf2903181c9a395fd469b7de2c5060ed22922aa4d7c782a33330714a0af206b29b4fcbe0f12c18948f6634ffd7f2710138020e273cb0dfa735bdcde9bd6cec898c5e564ec71aa7880d97cc711412f28603de293cd5e904e9156d4f6bfe2be15347b9ff7848eb51cd0785d6a649ea3514e02695c7e3c4f021a9992d67bea1d68e5b17db2e0dc061ccb5ababa49d110055467f9dee61aba8f3e5c713e94a8a96c3a8afb698887c1fa4abc5157ced33a834dbf0f5af9eecbb5f2ad7b63b4c2ca94a117c2b92f3d51900926e26b101fbe6207ab0884cbfcb15f9f98f95b0d08e29390977f4d3dc710eea3ae7433d5ea87a5f710f1fceab26d516fc19fd272f6b0f01ee167f06e6c33273481f280ca64fda0549c8db884fdd467b93998360766d4cac4c8de783752fb6c6d7b1e47df23ceeca572f2ad3e2b628e31984b9054448ed1d90658bc658a9caec0485512ce084a535e7c8196b8bbca5d26c105c41e083f8d56f1530a8c1b36a7f3e41fccbac7f342b2d026064b304444192d4873fc57978e44151896ea6c0f13d017f683b203ba1de677ed00f2b737c4c69e53ecf16ab918939e120e9fe14b2243eff0116b24c6654be09c582f1e62e75efd8593e62e45ac36f717815b854b47a4ddcfc91fc533fa85bcecb6e560cf11e46d2f334b396d68b275e7404a70f2a805a64cd458a8e5f114a89124ba1866f917749ff32e59ee71948bd97f2d4128beab8bb0b6b06d84c6d466bfa30fd8100e48d951d0b3e787ef9611a56ffd64d970dbacfb1b4df064b1cb5da9918f5c58a10f0903b64286b1c1ae5cbd00eb8b363bdd7a7aaf2111c0c6e86e15abf6c1e761fbf027425968cdc19522b44ff3f56335c59760fae6d9028e76b284330f7510f2b55b6f46adf90311cc785d35c2bb49272be514cfbbd7a2b7b2e8c0b6dc28cb683d3d581f547f83bbd3b8c7b76925e44e6da89d5eef17ab0bf4213ef9c05b7b473901d483c647f416b98478c7100919c28515b617a27321841baa174c1a2d3494395294cebd48eea14bc3106ca9c69d9f6485d6abf1c2b1111a8bc602454685ca61ab4ee4db9f413caf8f0f204f04d40cd36fa5dab629cb53876db3e16372e626b6bc892c63c6b6c503c9d22efe113927395206bdaa4b83d4fef4feb42fa7a71f7ce2197fe282a02d0fe50f96b1f917a67e50eb79cd3ffef064542f7beb51ab05b56afd7aea5f4164cc9ba37d8fdb35a3deacf0cfb555161e7e41eb798160798be9d01e3de0c4288e0bab19ae398e94353adbe9a43524ace35830b82fcfd4b1dc2800ca4c38a56b7cd28bc3e2f69a0ac4655cd79b5789a2b72eaf93b018d4d6f4c983d08932b22c85af6fb07df0a786d98820e1b06bc17f62d6e39739790a13049252f1b9102dc692ceb20c270ffe9b902ab7ec5a4eaaf47f7e2d31b2195f5f48ad18d099c33384141da14e151ba57f6b1bb97901457202cdb83b5c713bd8a13f6e3e276c7d6c130ae287ca8931d9eece06ab7cca124d6d02d497d55ea9151a95e8a4dccda72d3f51a7db3f2879918753683b01ba1b154da83e6d84ddc9492f2dd8c128a30c75174ed1a6b8d93d08645270bde247782e882418ea158b2a2153b2d8f75c09932f324ec199d26e9f3c4c4cecd807367e3981e137858b98bd1268d2c894541ec99bbbad19a6856ea16a1e56b7b193baf79ab89d4e76327405658c4ecb5a8626302b3a4618aeac7e11a1199c4bb08c60ad78fea4827b59cc883b2ca7038d7845106de9174b2b8c17267273d23418af560265000543ed9886884912b4160fbd372fcdf706ef642cf1829493884b6cfe946ecf6140106dcbe11b3746e33fbd4b5852b732230b9047004f4fafa0d4bd7043c7d6595accd1b2771aaa76fe05a0c80b7b221dbef79950fc69147816cad0e52c05e72ceccf55fb4dabd81ecdb476417dbfdaf3b555cc90573cbed9474266c89fc55ff0bcc55602a51a1b5f91e425a1a58dcd4abd09bbc63933fb4279b9e21298f9fe0cf1a93c4a19695240e8978d604047abc7239f5053ea650d781307c50dec4d5e2360adeb9aa02c0f6fec5784784a271169ce456e1c32bf984c3323656ccc588c97e0ece5a40fc7b4ddbdddb764edc512de63270f07891bd160f78b8ecd3a4d11ec4c68ea0a0fbd0f23af9ab261a110f431f926c4995b05462e0dabf29d9660abbc660c9a675628270cea7ec5ae9b6f298b17b2392263700b8ead9c845ad29ccf109a2ed66ed5baf9c935754aaa1b84be2b5339f9bf3cf5e80af16967863fa8dca64f5fe873da4a6d33e39a592749b721fec203c0cac527ca96de7a96ce9a540f5da1902c97f960a05ebf0c32934f9b81244c945a60fd3f176dd8c261690d8ec98d19607129a50edd51135ffbaebc04a0961acc5a32fd058ffdf2c6866bf90a3e177787e7061bd2011ec08ec118ef0451cad010b53c68d0bddc701d10920d697ea3439b1a0f96e6256b7712f59c746d1c74c20b17d461c3df635eec83e3b8e098034f119b9d9a79ada735158eac3f434e805444d5ea2ec85cc8ed8f5bccab7dbb6ecfc2e385781579af1263d9fd32bee32e01db94703b5c756b894def19783b12bce2a1a8d29d96f329cb0791d697be7e0f05dd5c9dada52e1b8c1e5f75a0fc90ed8c05bdff86644b1ee61989caaa271061d4222818c894ae9eca2da7326e5c24ca1eeebe3720d2127ba997b0c572ae30615f8bc4278057f4762d46a39b934ddb2a0903fe1568c1bcc6c37e1f7c145eb7cb20a6a4b3466a7aba58b48be94f7e14cd20c87b2768358d06e3f607fe5e9dd1aaa8477975660f1e379b9ea26cc00cea8cfd6420f2fdc7ee6393aa17cef88645b821f8f42fc7dd97b0e16c04631f86ecf1cb76a6502fd1c13917ceb26a83596b117d5336387ddbea56162e8a5bf2fa35e697245bc7210cec13bfa694ae884582924168bf8ee2f61a734e37876f363225e5ae19b7c65ca6afc31c8b37bccb308a9c27f3e9902de365e288e6cc46e329e78be914b85eb980c0bad932c164671ed395d5d8317c133e2e000a10e0d20d0f408019b33d9a87ed7725ea4c5abad67e0cafbff31dd236e59defab7ff2cb40f479b56b261a32656f016deca5302a336ca15d10e0afcd168a4b922b79c11cb21881220374492d64df21453b41346a85174a0a4a3c1e973845c856ca70d6d25bb854d0c6bd3c75cd73998c7f64e35a58dcf593c85c2440a6aba4e470f87e6f9b4abe127b30f8992d8aad0be38f008d9d937582eb3aafc68f516d5aaf2503acc96e59a151d2d4b072ab6b38c54928d6656441c709f1c1b770ce6efcece11f8b3602eab63e0c629bbd8a79a96be4cdb072780f3d287b091fc94ff2c0d347fe280bbac308644bdb15a3c653863edd945af0ae725507507b82c283dc9909ccacbcf357d7a19703401b6e4474b94a6cbae575b942501a281b8166fdc70e6b4b60c2f57a4d66fe1197d301d0e0c7bec12cedf9496bca2183d04632711a79c8374b6de35c2eecb0239391c2019c720894bc7a635df18fceeb9aae16b3ce92717e2c56903d20d0712ef80131b8c48635163e97efb1fabd1500d061c93ad935be9a65a45a92e4a4e885268e712efbe5337214701baad4c73e81e73bff19af131f0aba105baabe849f0000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 84","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39af7a5eb57cd14f7f59b24bd95a0dce770e68bcfde7a0ddb7a1b21e2a244c80487b46242b5541914c112255ac0334c1f16e2490935f2126d18fd248671c766ec080baeb3a1d1b7139d9f29cb4ef492f0f509242652a5f57786b751981aede670a7b2b1e42d0e56bc49fa3e75129cd6ceb5c9d8f360185e85e15a40730d2411279d2a0d76ae6674b18f0c9e353e16df4c71854e90a5b283bc2f2e9a6d7adba5a8915c88bf30ce3f14a3f8d63fed755b52f65914a6d2bded608a366fe6c1653b10a14895d9e4320f8f63e7492c0d66384a9ac66736e02529b086b1bcf60fdb92410d9b66da4ad63cb68304671576750bdd368812ce490ea318c28ae230505c7d9d7dbfdd940cb6d9add228d9625093b1735f36fd95f6fa299d5806d351b19d2d5c627b6dcdc648bc1c62081d03af954ef1e3d5cb736e6a9fc7972df558646a1237479612f6962f34e329737181d5c9951cceab4afef8355c89eed6c105b1bdadaa86dbec7b14d87a0625f309024cda68a414a77545dcb62707b730dbac2a368db7629c65010952a7d8d874627d236495273ddda9373e1b9df19e5dff78966eeb1ef63496ff23cfe790f3607a24a10d5ebc9b8666f8c734161bdc2b81193b70f5edd863d1b256c1f4d03aabd3dbb1b234b57908d92f9954836ef072fffca87e7c4ed007560a8dd03664719b240b8421c866602a1ede47cfb6cc6230cfc23c8b71b5e657a329d5a772b465197a506c274ae7dd411b84d71c9fadeda24d879ae64faee5b2304d86112912622ca7cb4ece4607d36a6aec9b2598b3a05d3c4a26c939d09681f6b27d624f37731793904a073915e47ef9eab397429b31b699021844ec4e4bd743f647c66945d440a298e51636dd38db6c171b50f2cba27d3776198368d2ba5eb2819e57f8f832069b5639d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109b1f124fb0a62681a8c9e93fc123f0aedf3e751224b42b4db79c95ff086acc89803d2be1079eea9030dacb22a24d9c6ab374401e3906dcc2962e5ac96448ed227d01d361c475892052e83a0e0611d9e213825ef3556b501b29821658a14ad2b2e8e2885a85f78236ce157dcb0940965412d8173c48668d714dc61f43096659230bf82d70c6c3879b210688d4a180674407b604b728a8c4b50eb555bd0c6e404ef193c0130c7cbcb0a48359e8658e6996985525761989fba5983476dc0759d554da8c20953164acb136f27225f80382659115a4c04ffc4e597a13d7075d4365c32b1204b28a051f0746d84571e00fe8a240735c661e2ab56d8daf047706c223ebb63aeceb53909c2b0dd3158f0ae7af746576bf5fec2364ecaabe9ac93412e1d5dd28117ef0b156302cff0ed6dcc78a9d76bc9476f3875a54303a0047cb6fd643c67c22631345b88601535f2927a2a496842b693620689f904ad2b393fa65a71f1124b78400441e9eeb5d55f4559b5941990cd88272657414c230d965a01c309416576c8a7a3b247bfac848ae7656b19537020a9ae53c461319ac05ece0b6da8b789b12ac076e9c340b0d3ae1af65773181d47bc9991e4a3981a75094959d223ab9c86e93069549f4cd92240af4ac9b09d8856ddedf76319150513ecbb13a9764ac699063a1d321450a0864824e3a61bc036be9cc458cbc5cc86fed26ba8836261b93747552bc9801ca31b3c15592e801e2a3f093a950e83618325959bc8b4162943588a1224f36dc737ad5a00da06d5461362d5e197548c60866fd5d2299eaf6eef7354e6816bb4c2c16357492e3e7d389597b5735122a966d3937326bc324d53ee3e8161086484761426149402403a70c1e5cbb1067043c5531a295d42a3e99ca9ad60ffb5308cc6fb9dca59dd38388769300ffa1873d3450b37ea80c8c5d9e9a7a6ae38cd827dba510a31c8c3264c5ce155d11452ac41c432b85e6ca794c5d4e665843e5dbd5468d1f9be913908530087893e8cd51bef577d20d37863eccd5f2c96b8d413a557085e206801cb72469a632f62e65b58dcd35ce1a614a668a33f664920cd8698b5daad6ee840eab095f67c6df3146a1c3b36cd62d38adabe9ce88bf672513fbbd51685ee97785d32724809a5548b823227c9476540cdd927ad96d71f20dd88d5de356826762a262fa635a4f2d4bc04e51e559707f7c3fe114e56d804868c79de08d45a289e4d2c96652cc7bc824dd3c910ea625b786871c32d6d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b16e43eebe157e43d9f54130c668a153907d65bb19856a1b7c2fd5e2c770fd6bacb13baef951eb758485c128ece4f3e9377a58a45eba1c3a9ca5c94b50714088700d6fda933ece3a6989ee77a824a9e99674748a90b7f227b589250c9e156a8e50b74a7f49de036fced86ca0d4c02e217eefcaef7234f651ce4380b86389d7331c7657ac283f58c781f904405acbb68661310ec6921c1fb7483e74116378086d4a0c9a52af9847bb3ce0fe97f5a7c2cf588db3b6fd725ca83391656cb38fcb6d79531e56f5d42fc0cc20d04ad7bbf57001bf2f8e6b335cc57ca2db23c247ef9b75bbba3159030975d65b9aa7c10e0fa4f615f77126d5271129d8839a3f8da30c79174373c4ba643e4c4f0cb26bd5b8b9f7ea56de459eda15037d8772478fd9f7f7e06f3b422df0b425dbf1e91d3893ce20f78cdf1910c5d4674efadf122f41d6c7d6290df59fa029bd82e792e758ad4388f9d352e9d2fbe3e58810c380d1cc5768865d24bdd92145dbd1ee0d4724c769ef5cee12db2ae2708b4c8c7865e70ca31386388d991d46c4dc4dafc5ce66cb24d455bee01488a7c764a308c7054572fca0cc74a01a2b1f191c54146fb1aaf55b834f998b50909f3d003271e6504985dc836b5c44655b938769639799f2575bcfa92f13d32b283a5bda11177ce1f66d6b30788415bef598773e87b4c8c41f0ce6633b6c945a3b4c46b74f30945efd99cf3709fdafaeb4bd4c6bf605f89c7a9b4eea1a6599f0a32ce3f2c58587ea8bb3fe6495d92f2feec52bea3de2047f5eea7ea1453c762201ff1291afa87923107f7ff586e00d07824ee021649abd2d6e9ef11a1d31726ea9277134341ec57d790949590a963d25d6fadfa9ca21e43acb7e5ed4cb6e8bb36377c2618997943cd100a927d395376871acb9619bde9b1ffd5e48e271952613875fa3acd3e1f2e872f1d672aae6e2a575a4fdc4fae2dc6a7196e7eba94ae5b49be41e7295433adf49a6d2d945f43699d444a726423cd9164b9e28b0aa4485b0c767a9398df5dc5f23d27889c14b1abe98880e7bd5df9ab3d1321d5493a0a8b91ea4827627a9b59308cb0104cd8da7d9def2d47b27074ba007401415e900df03f251c8aa425f0fa59d74c41ba7a9288c8e280141caaf6c6932ddc4184f81f5c33f0fda005bf3fb6a0a9169a709875ae475302d57ce96d3db332188202597ff29d1f9ebad2b0ffa27c14ce9cca58c923283ba10e9fa1689d6c2b8804225d706e09ff97ae9cedc27d256e8736daa54382040648f2f6bfbecd6c3a9bfaf5d1ed23ead00eab351f1e0bb4c719ae6a1f5d12e7f09ecea62a2f554b18397fe1400da1eb6694635d7c9c626e0fc82cf8df6aa4ca88b69f78cd065c53f929baa58507fd3e3d8124c4bf287d452af47af9f4d926dfdb529a8abb8bb57c5c7611a97053a0cb0b01c754cb479c6cd3a3e867bac33e45ea0bb6bf77e0b2ec2f136dac0e259fa309fb5f6d8e7005e1696ce203c5d054e5927a87a1b4e81e73f22fafe61d7d64cbfbe519d39e716bdcbb37657e71b9390ff04b3c01c6f6842684115cd7f5aac208eea48906890248e58d1615634cc1263cd3adc14b67f1a1a8ed2626e7237af5488f5d269973f11458e3e4fc2ee35a4bf49c2f5f2361939fa243fa8f33b54eeeba9b0453701e367a7bf4d698c62da64732652c68c20a956522826f8e29a764ba93dbc98fcc87e59a1423886694057e131333c5dcdff3be7a1f0d344a2debb90051721e0226178deed353a136f69481f83651be3281c562d6127914cd24c38ffb327786086b08ebe89d03a33bf7b5dccf90de9c4d907d308e08a616c5343c116a098786383009dc70787aafb4529cd27cf85f946b8b238ad2f00df109fc84cdb48bb52b73e1de066636176e8c6c76216105486c553511df1f0664ec1e04ee0b0bd74a08070207486b7f326c3ee73188ab5bb7f8f5643093916491d62f0db18675ba4ce90b2ab310bba4705b65a581fbc5e76842a99d4926ae5bf7b8eabce5fa30cb98c1bcf0e0708da970096234d47bfe23a4f9ade29be5a8b6bbb748ea1c13d00388ac90b65ee10be6a9ac422ebddaf5482422aece19e702f6d26ed954d4e489cc48b2e39a6f168e98e11c1dfcb4a843354f1afd447962e5090ccf51ddf6643ce0afafcf3e4363187e69c31ab796132eeb04f2d4976a576b9bc8d9b1d491b74613c1af32e3d2def408abebcc27e4a915c983e10b6090fb2de6ff9e60c96cf4f940b09aec048e7a174711798fd76db15dcae0e570be3ac147e2f8777a522555b0898bcd7b04abbf060fa72b04604c9a583fefd02b2af9fa035f97de4daa4ee777f9d6985149db6c2f0a33ee1a1436b38dfdff87f831e83399c6a884273e612433ee3958f37c99a748df151e3ea011f4df5f0050597685e0230da1b1c7095e1203ea7099ba5c43e58ab0eda60af65291c3cc9a07257d71ca6c9eab93cef41294853a67a5b11f9192c96a36c701f142dc36b046218bebad9904fb765550598f8e2f49f5f0ad2608117196751e7e4c5cc4c3ef425a921c1ee15f37a1f80df1e24163ca145edb0fc4d988b8c7167acf9cd94f919ac96e5469859fdaec54e1970007eb9699342a9aa044a8ee478a3ecf8b59b0109ea7640c218ecc1e8cbc5e2fb61a1748b7c038efdadc2d096bc29d95b1be770d097afd8b0fe02173a1b3d7110f80d6c849f1afd1b01a60894b16140f9b34d96071a753545159c4ffa4dbaa938bdec287c6b83751c5e699724ab355d1fa0e081db286ec83343877c520e856c4adc65322aeb39cd87b7d8e4ff9222e085ed84c58b7ff513ad77f8a9eff2760a03f69ae5dd14dd92dd3f2d3d98e97b1987086b3eef2f2e822c851b7add83903786c050f30c4a4f4ba9361e49acad503e2a07ea119752e12d4fa09dc83f7a48ee3dcc1f09475960b6839ca736e498a128f78e58279063d839aba88ac9e5bc24bc07bbd2de1cf2e1ccc5987e63f83780d0ecf07eae21c8c752529735b37c980eb320dc949468c69b17da8ad612825a84d0529eb97ff8c4cd225fdfd1563bb6c5360abdcb3339434a298ddcf5f36188f3ab501e505828e8d2fd6dda062ad415c56414fd7557170f0f57bc5a401fa648699f3c7f7fd8f1f058849b817fadddc24726df851d3644414f55cade30a5764914675d574ead4d4db8725866a6c51bf0eb23b12fba1e101a6f3bdb98a2884d0f2b8deb3f279e9c38ebd0209dd05c0fcc6ea715257355d0d6be2c8bc7835187cdaea43a8ef9c59e88af6aa667a697a3df8bde250eaf4341a835b5ef93cff97656133b49e13213949a3f368d985e0d6c793319f4284dfada383137dc5b000b7fdd85f27865dc633562949bbe4fbff75417ab109f03015bd0f67728969435efae791ac72c6aef99a385a3e8b4c35f58380149c653fd78391a7c3b26a3550d37f9639164979288beee99e36ac6f44d0fcbaf0d210839d563a6249059a30ce6f047f5d541fc8a90a18610a8befb9493c5ac804d34d40881ca82e673788870705bcd585044b11f1d9bbd6b17d8b82b7ccc0554d1e3aa7f2762fe01385571c9fa7a103d07c1a209504876189de4b3c5910c26c5f33ea725a7d57cc30a6ec8f3eecf2409f1234a094556c0f7941cfb30fe86f208feb73c8e8ea8623640afbdb1cc589768a714cf945731debf4519b70870fb3a50f1fb368ada3fb217704a5d46d879ceff9bb72667acc673cb196afaa0db1160cc2cd7b260deb791a94d0988ed54b7e45f33e7cdba0fa105f3af3cb1521ea382b1266df304c900bf53e195ced03871a22c50da166bb9441cec83607083195d6cfa17297b678abb5e03950160130b47e25713b0829f64d2552efcf404f65798a86d5899b72150a91ba00f7dfbffe82531497b60c31c28992377a2dfd5fac8a9c16c835ce4dc24d0389277e6355c655c8a33c89bd48f55c13ede24b9bb348dec89612f0905719743c95c0e8b5653855676ce171f812eca405b6f96f2212d1a5369a11379282ac0c5ac41d00000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 85","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039574295fc2e0cc7f3b1479988d668f76998c35850f48906c303f71b687f83910923643968f21e458767e2b53ecbb434b8b130be3cc5baa96ef268a27b67966199d202ccb7b2187220f865fc36af8729b572bd72266eea98326cf631486fd6853f985c553aa31f19c3b659450e6b395b60b29f6c8fded43c79341676b147501257bc48e17a320666205c3c8ca14d4239b96e82be9d5a507243635ce1c5cb1b0fd511fe03d48e91b469488124496f564793d39eb4589a22927d1115551007e54dfdd22c8f1e81407ad5ca8a0450229e19fef06ca527a9e07bb7ed5ce129d53105a309de6b4cb1e4e6b4be1731f39b6d55a4bfb44059dfb6d223049acf73991ff64dcbcf7fd3e4a237474eab30267d11270759a362c3489a5649a90f7427cc4357af639b36551eeb4a7a8903a2801b9587759469a32c6e4199cc4aa089f63a8441085dce83e3fd25f1ff1fb706f64bfe0d4efd49dc6be46bdb28c51ddb4d7a63da4bd4ad9b51ca6449d9ab43696b6c0c6d487bbdb144a56c6a62cc89ce12ad879ceda27aad99676dfc838b567d7b58bae4544ab237e8e1dffaf4b1d4140be4b9fa19fe8f76ef243f4bc59e7ac97b7538b362c9df99ba9474c45c744782e706e826bf8a0128a13fb2db7ccf2286b66419896ef47ebe0f7282f66ee5f0637328c33eb2d926ddb82a7e1c14c19638a946114d635f6a559e13f7f15ff1e8c07a3cbe3d6e67bf784a157bdcda2cc14fb36b1230c79e0c9218a6d7b8efbab2deb3388a2e61be5e9781185e22f22592c580644807450ed3196b9cefa6966752cf7421b6e3b8ad3782c4a6c310056d356304261b749e293b984d6cfd6d90d73bf97447fd49a485dc50c826aca4dc595de25344acd40b67e4faa582f9cde26b74bcae425442a0fc3d7c557b8a51b8b6285700e460e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381093b0a2e2a51cc164119b7147853c200d1bcfb2f03f3bedc78ebad09db145064589682c691a865e31263bb77a9c2a1e3d20660019530bb1c4a08e68e7994d37f1ef25e73cb4cc574e01831b5ad64689da2faa419f78dfca7c374c1e7353c962510cf468f7a9b23440781aba6271ba919d1772dcb3abf2cd5447de6d8b5646a25309ef0ab639a105d771bd0e1d7baf9f8a30a4343b012d04b6301d4903dd11117ca0244289346ec4d095c058c631f291d5d1284fab7ad4e66b20cd1715b15539ecff272c199b44ad12b3b44501e60e980edc75544ba3b3301cc0e384989b37708015e9ca6c97f0f88b4c649b7ac9f4e6c4d8bf99fc7f751a68cb11f9fe90cbe7c55f9cb342a149d97c9d03d62b4c429dc632c077d52fa4b50e41c5c2f18cec36892d992d84320de6efa39d31317d1438dc9255946823b9d494055c2f67242eb4463d5eb4344d6e48e17ac35e1cfe2d3149d706dafd9fa250a94b587f6e32a9d540447059a9bac16b8d986ff08b47509f1ea5069b281dca9686082e86dd86a906e4dbeb5785161ca17c312140c94d8e84717c4b3e471599d8d5dd5418c4c184a3081f5ea0a0d5c744258e44b2c8b9c76c547dc5992928bf3ee21919b581a478c462d50f23773398e9fa05e1fa1ed94d64dbae9107057bd238ae1b40bdf582209a5f4955b9e94e27a366b1112801e71764ec75862f434467b8d2b95c5f8f9d7d307795d9a692ce39f043e0ef0dc1bfd8f457f2a70aec27f76a355cfc7e71ffc15f9412cb3b4be4d76a6569e25e92299dd58ef8df17302908d0b2352d11bcfe41ca25e19b9f124b688ee64a317ec8e35366782fba29da7099010eb8fe715f44b961e686f5fd6737b5b248036320b93b26f7f2564ee57601f3a9884975214a9587a7cd6263e98ee6185234606892a04baa64300e7bc9d3017faca06837156c759de95193fd454191bdab609907dc0e10d53a14d4039c71fbf0e1984672ae00936aaf7bb01c6f568b80db0cba9480a2eb4e793df8f1ea426d27e45558d68bd38bcd676ac4255e9366747165a9ab0c802701ea85a837c6b3b36513a760144da34040f96136a59575d7b6900c9244a2ea73ac34871926d368023a72f95c5ed89912e161e282a98d9afa21ea0d4d68ce688a865ad12bc6c0f2fc230c9dbdafd7210b1e572ea8073ece4464a1840886a76c103626217c26df87dcfaf846d6f97916d2a5e38b27b050a6c4c98babae1943b162d2e0bb7017198da78853ed5c02ebe6fd5a6de72000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b37c07185e0343df2a4201649ad5de4cffa20baf5dd43f5e4a6c81cd5143fe72865a7c036a2dfd617d96626995c12efad019ff44e0edd7028f29e3657ee3c0d02e9ce83ef0a648fd7cf183a7bf7c15095e0f9278b14fdf6c983cdcf2987dd0cc085400906dcd0d14aba60124f4b7494adbbae3a8d6052122575f99792f7240eb17864dc6d231721140e43f1110e73eb2e3c05049783b33aac4e4ca0a248775baf81fdb03d114508928bec3169a810296b5a4dac27e7c7f8d01cf5943cf4d8cf6ee6f9042bb300e50eea3224d35c9628e38c368ec3b42393fc820371db6557216a2c2d5a230fe3a7c6bcbdd89a2be5cdbe7f783ba379b6a4237db051e6256dce14dcf641190a956e8e85eb2638736b899ed045636ddb7a351f5a4f4108d9d6e0413f92b9d392495299128a5f4acce8c7747c675efe05ed7182db51c515b345029440ab61a904d2a390122680c951ed4575515144c5ca80d6f14d1cfdbb5373b78e09d04d0544151cfa1240790cd31165048d1484dc4d11d05057071db3433df071b367e00fd38c386dab689e4dff6fb421b2a95ff54dc29375c9d1c18a76c79acae3d3f35d4cfc385199a4ccaf6c9f0421bcf58d296ec7e0d1b95a6c4bcbac1271f94e438360a71a6440275591e41389b30caf2626a865b9e59552cb198a1d4453eba6d0f6fc491a8a7783b4a8baeb81e54f9189ce493efc1c5d830a4f637f2bf43cd86b91637611415c95685fe79966174312fdfbf33a646625f97521b5cb1f008135b824f1d6d8373006c7158e62b1f794ae34548a0c6dac8b60c559d81580ac0d84034a501516ee36cb4082732918365a5ab787face591ab02be6957ae4bb96b58e2b173da019d3e0cabebeba0af775779f14bfba8f595697731522df3c80cbdec16f6acc32659cf5daf193178307887ef1be1b48b5806d0fa9868a7fb853708b26873857786b974709c687d6597bcf6c7e476c1e47cafdbf30b6311ed434c0f998c4065399c59073c1f2bab1d46104e74ea6c976d416e58bdfd24ccd957cb431870de5da8763992ef68bb18075926b0e4e826095eb3b8cae086fb1759c94b873a1f4df477e0ee9eed8dfd7c77508b3f0c67f69be04355aba9344960639f6dd6b3a956dcd66370338617a365579c5993986b4f748cb7c990344b209785e22a40fdcf8f83061d37c9f1351b4473d6c74abe6b3eb2a7d62ca0f0c88a0aa8a46973f781df0126e8d55d3e9c41c2e3884f84fb0a06c484cfa0c9a0dfb8cfd573749c711c7c236b0f2f144e1ba4db2525c093deed29434fe43cb3040c5a374cfef33214fdd2d660398e91bf070a4f5f9746c2f08c41256fd5e955891146ffd38b155987e6a0fc47ac2a5950509b9e2c86b9dd9929378f43ef3935f1562672498c5640a22315be15b001d4b01418df8eb41dfe5c570e850582d8916c2e7fc2b728048e24bb9d1e8283615e039c16a2fc61011631bbd8f2beb24adf9552cf5797ce05d9d1a7e7f3f5455017b127d9bacd32bad0cdbd3991bbcaea5fc988ee7aec0b1003732f25489edb0a1f9897247cbc40e60f1dd276259ce19deccb90067f7293a68b683fb5232acd2217b8929859109d6852a43892098630a67d72b1cf4bd5d58e20c5c18b85d69df74ee8cc69baac7da48eb71a160f03b68c6be87a4919736f14363f004ea3f41dd37fd8e621bf433bca71e17565e060f3c0f889515d0a8c17fe0d6d734ff756256b0a62058b95422257780de000557df289f47910cc272a14bec737c0715f204c49f03150082dc904a5d170f7383f04f1e355f50f80d5461cba53490bb2e9484806d369d61fd00ed1ee5be518d04a24503b1c4c08c7ca084902a3942c04143807203287a985eb3fcae3c5309410cd9b9a548f54ded44321ce8c2a04679841daef7fbb6aa11091d240afbb467d9969c31c1cbf6b24f8cbfa20cb4cfa404b1310400271664763e9c1cd1b6fe5ff2a0fae22ab14efc016ccbb19c5dd5d047750db4addea3e7a193128a5f4d7bb6358f21b39a44259695904de3440bb28cf9466b562065c387189eac2f7522c9385dc2a607f6f9335ff8add47c7ba932659aff69b1f26ec8655bee4f97fbc846e48111cbe25524873d1db2f2282d0472a2aaa3cf491c26ddc5e1be77866a3b692e417e6717a4f4454c56f97f063b9e598865b6f71136d65ddb0f3cdec57decd5a57366ba96e4315a88b4ea3479321468ffff508d23b0701a62ce0cbc0fa37c91cff5c5a0433fd61ae11a922575f5baa714de46a58d6efc79bdb10c9af7e9950a61d44b3e17e3b5298501146485b562b1570ff5798b47641d67091cdf90902b2d762e3efe94c540de4a28269cc416edbddd4d43ac2fa82d638dd9bf11f3bf22fd81cc4bd4759d7d864eea0e8e8ab71796254b278cf9b650d1fef38b8437362b2d69ed84c54498331c6899e20c596fee7cad9ed8d83d86774afa6e56a4ed34b0b0842b21ccb67035406dedff0cecb0cd089929ed5ffa0ce210822444808bad99af603082bfe5c98ee4653349f8a43db64cf90190c96b0446cc9cd23e0d75b47f54a731e8bcb0a4c67401dee87876011033d2a526067fb73786fbc1ce696130fce5d5379cdac6788875d27c04783b1e2ef41063d57e3d6560d1ff48882c39131c95bae5a9c9392dab6cd17eefbcf61c464a4dbc08447443cbbf3fa80481f3bc1a5806042c07f7a7ad435875ddb1001565eb6b7b872cc6c853f771c1dd5d9c16bc27aceb3c7690125c1907c7ce904852108cafe76351269a3d3ea8812fae4fae35f0daec8e8b186f760005524998bb5de475e4df85209da915bdc972218ae7db7e2efa05a7d752ae61cf2f3dc26ca2d282c8e32b4838524be460971e077348290fa0043fb7616d821a71dda3a5fb76bfce0dc84aaea432df32b05133a26b46165297ebc45024777a868b8b1b0dd6f97658be799bd366cfdf99861e916f7cf06c034e4f79594f1bb6ecd9b7347911488928e1e473c4b8c73297f7ed845b9ec59020373eda57a436c1c9d1459c6114bb6258543d8f4f97b10aaef5a2e082ea173ee69702d83711fee6aee8f6b260d03ab74c3b5d8fddb81b208e16458511270dd1da295f25cde7e44a8349b60bf0c59d4b425c1fba60d2bcba47b906d2830d8d5c091dba756e61620d78b2dff28407fdc9da9113cbe82219bb2cc05e11c70d040bde821aa17b3e981558961ca571e5d5041f7de047a1727d9c904deebe561dc6dbd8876bc77c27322f512d6171bc03871eb0fdece70f119bacb41d1852220cff26110eb0eb78e39aa1b2a4c2e78679f53683520c5a57fea71a8e96e0aed33118dc4bdd035fd88f535b011d9c7deb6f406a072ae6c091016ed10a5a4ee9827882ee27c535262d1d745aa5231736f2deec8a6017bf0da36b416c98ab71c6824a6eeff3564665007c9e850fd02a1f5e201b534627b92d21a493df293db9f24de70c7b49a6e07acf2db6c90b448681666dcda318c08aad08d3e257af7e774c75debe3b3c07af683735e87f205b0fde07351849c5afd07d5722c6aa17b6ac2cc3551c305e6ac31e3601a236961f6618cd3a0f7dcf6f65b8ec82e27e44c8518cdc16ecf79374f796a3daabe2d5005b25576b35b021497c5a8f9b98da68d80e56a1cc1044c04dfb11d36cb147eabfdaafba0a93fced8675d7d6a9f999785c0e7346f4c68eb17c0a2409e2f5bd4ac5551ff66a9857c66f642f2a385131377b6372884c417e01bfbbe1ca748ac8969bf2c0bd8944767746d1d57d862795e8ecf9e8a5ca122d0259ffba822588c5eccd14cc6ff4b7354cb572f5bd695ed9d85de131fdd97dd5d6ce7844ddf9f3d112028b5125ae7a77a4aeb2ebb554682a26f457c43fe96d67c90be7e49ff443478e82d3a48680d737d1260b8210bbe962efae6505e496b1b6d4f1042a7b971605e2dc50be3bdfecc3010b9f5618d3a1b2c1f48888b859e4d6b63ca9d29990b6d502fc22b738b203a83d597b48d73c41860e4e99c57181f5b02f108ca193451025f3b368cf2741244f42b27cb9e57260d2e127ca166b32e0b9c927b247b31619b1d4000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 86","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028b391790c21c0d8d10efc63e6aaacad12df1592971e1845675f8fe28359ae6b7c030d99ddc6fa287f7f0dcec7c88e36d0ac760e5db970bae44b0cee69b9cdfc6606e3f868f3da257aa0b1c9928448789aa61a652fd352367ecc0af35ed149b18d8e363326b3e5708fcacde79e284ca2aad23c4caa5ad02c4d5d729b610fbc217790b3cdf53f4d9c9d665289d6403ef1f686cdb4ab40483f06ac469c8c358258cc190524f7b7f0227ea9b62674cc27768feddb0486a3abc362bf6260ac9bbeaac04becab0f851998039f818c0e52f915b5a3a234d2e636daa2a0ee2989b64b15cdfafa31ca792b8d62547615cc84b026a6b4bfc9b5d51c610932f0866f6a826e3735ed4e520f94816ee1e80bf8aca467497387a9f88c15939f52b057ed79b76b59252b7c7c89b0df5ecb854336f1e19d6adaff7496de3935245a4e90d3d9dfe21991678d293bff27b5c3f5a7cb71e9f75e9a14ceccea1d58c1e49f5d4be5e30c89c0536c32b6f7d32e4d86910280e6d0d4f9cbe265e79a56390871f5a97a2582f9f9f2d17638e666bbbffc6d26189c1f4a4620c9248c3c7774b22c705b93d501d6eb7e0e88f81d78c9aa476f6ba509befcc9d4afd2535844bb78c96f76ab19f4435944328da69be476b24d8e5f37b2aef00c33049c488e776dd468c9e4bfcb6492434c5665479850de3543e5699014b8d2693acda4f8193a1ce5add99623b2aa6518e2cda38769391459e6de3f4187101affc30766ac28d78ac3e0bfe68b19172ed82be41992dc59e64c0fee04dba029a438bbeda8c97b8d1a5f5c0dfaad06a569dae431348ed5ce0b9cec629e2d859a089261c63adaf26b1e541a2110fbc0e1750a04322d3078f15f18b0a24fdbb6cf5da73528466f2f904260b61eb26486a3d37ae37ed37c2f36a251edc81000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109718a494087ac0a08560ea63b2e04b9b6a766e45ada7e26f0a5b5e745adcc9286bfd7467f91245432ef0e180a5a56fb9a9d7f6a69248ba470a4b671d649148e7add35698ad60f27915a7315ab4832b060e7f648ed5b852fe280dcf3517914da0f5ec0117e11fa8086666ad97e3885aac8203999026fdc2d5ba9fbe243efa503c4aa99ec637d13ae05c406d9d16972641a5f9aaa551050376b89e62afa20076a832514421274b6265f543cffb4034594bb02bc28179ff15aad3d845180ae0e7059d9008360320aeb57139ea3a22530d844932d205d40382622e0b605fd57e688cb53c57a415fa0e14c466f47f2aa52ad54ded0804fed6e6a92431e0cb54b64ba70ca2b12a91aaae6a027200a8c697ae6677c028054187446172372aaf609924a4d95ece5f34927a2469d3182cac3acf591c98e945803d0cdf936894e231653512a82653328e621f9ec5e5b8e7a9a4e11073d42c61472db6879e03a348141ab24907c81eb5f44074d68425e55ef2332164383838f1245d89025df5c6ad186958c45029d3078652613a37a3521e8051bd11afa06f4928ee847ae155ac1882709260fa12656e9426212056ae36495a6af4a178a259870b3b2d35bf812594b823b9d8a245872e7a30df01372e34b6d4cbfaf71eed92440b4142940d8192e57a4aa36fbf318b28b8dfbb72dda085672bba0c76eb9a72e33b939596d9cb9a1157b922fa52e1dd78bc80ba6b44224e2a4d968323c80944252264d0591f79db4ac2222d8a05233bd4a193a31d45723d40640a24f4a3dd58ab65356eb81625271e7d2b6a229e9508157f7aa50582a0eee5d20755119f10edb5604d65269ef006792dc3596032a8fd088f023856295c2fd25a9991616c0ff620e0b17a782b42698e1f4a6da4865548ff8072aaf976a2e8530644767bf6ac422219e9bdd2721b1e4be021e5a283ac01641fc836e2f2473f6a3a6e852bae3514291feb408c71689ac118c02b7e9cf9caf7be227c77eddeb37451cf5b21a2a7b0856c40dc2ecac15f3aa34c99c93ddd3aa1f45315d60cf108e48f95c5e2a3b11e36b12fd99297e8a30a13236d320d02da2b944d025dda11b490ea3066ed83c3895dbd7251d693005e7b0189327c4966659cec73c9860f63f61d81082c258558664991d38d8652d0a84d95c27bda7e777d6c3493e926b228a0bb82a95fbadc90259af0dc2053626605a89ad8e1939d83692c784268b6091455b8be63c448a62303a60ff6b954b73bf507b76526868000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b58836254422c7d13f1120012fb9cc7cdaa1d8b72f6fa3943aa7de75263d3df814bbf2e80c3a204bc0f9ae33e4fa82ce893d35c57e41c7147602be12455b00b7949a3195264a3281cecc3fde34802b28c6e1f2b505ab6087d453bd6aa067b2370124840bcac4605ee4f14edfc4b4ff19a4d7a828e60156b49b4027ac18dccd20294f89ccf03d0cf47bb2f22d3749eee69ee17ab5d8e4dfccf36824d23e3f95e959d0494ffbc712ce3975e3a661b3f9e149a0234f691c2d820000de97cc016c43efe958da469f740610fd22b64d4bd2e30075e22bcfd4ab41d952d2394fc629f016ee1cd61aab4581f62a7b8648f8f8cf02462c81023cbe2755c91195a5917fe5a8b5058ecb8daff91dd3f73fe38665666dbf79cf6f203faf94a5ca3f3affaa2c2bd5f5dbc011daf46fd7ceb74b5875e4b5d80b6edb9817106b91865267e78731662218c8ede73e588256fb1ad57232aa5533d25bfc54452612f0c2aecae6de19355e1d508b888d18ff9f6d7d68199755cf5c210172f65342269ed96c77d80af8a244b43a99deb49b97a6f358aadfcff6aff72ab39540d375165185f31e0f1a6f97722ee365620bc5d642f8cdc59f7e84fd8615f4a336ed340be6ed8451997d87b7904c1b9a3a0bd1f8a01afd6a2d9f5b995e3fd0d44df8fbc8389b6cbb5537816c91f0efc3d2349f15eee747b254c5bbf9418bb979294423dd6de4d13484408362582a86d082350cc79ebcdcc05b70110a038736034ce4f3dc1d17e5d11c9c7620d40730b61437906933193d1272f7c89c701d495ed682f1335b7e1c42c994e090a67d932a8e825f4b9eda8f2a94b9a1f11f10e91396908a9d436dd01bae1d1de2c6acf458c0880e3f81adc2240a99e6083c9c188982713db243028ab07df407218ca6b3c4c93989ac96d92375834b915b724f2a105d6240e52b9d7003c67ff76f7a325d84abbc229266bb40d1dc8784ce1a4a6bd17972cdb26c274b06337d525f61b5bf952d23fa13757460b7b8a3b99eb023831f4fbef72d62931348622041ffd12634947579bc6e16bd1eaa8e8b2dfd54d74efced79ef4ff31ad42036debd0fda3b7f3f8e7a3f45955f82936a67122cd42e38af646cf565e294f422fac1e7d274185896f58e9d0fa1fcd3f4d379ecf5b566586246216556939bdf86d6a417c3bf77c64f95d7de8197ee25b44eef00209d33159710df001372c3e3d09f24b9b08b8938c522690674a7588933e1ca37d2c14df50777806ef6fd2285771a44f6de90475c6cc314df140c3962dd9d70c54e58cc5fa3302d69c80c6511d9d42a51b7cb7fd7fea8d8bd65a66fdb2ac80d945fb7ec72e138f5566ceb570968d84b60068df20c6cda2ad48372dc97424793fea8d2136923070c25f47c3d10839d1747b613b93530968d5e97a3fc0f563bffcde7b42c839efe66c3a8655d0ceb5af7a37d23dbbb52d05cf6fcbffa7c7491703349819ad94ce218912557d6c87937b2e7b0473856ec78713c29a02cf7b2b38e0dfe16804af6c2ba8607026892138011e06b4af179d63dbd97cb917b6507b798e58d74f485d3f063c044211e428fbffd5af2d7941900299602d3b15d5d600b435d9a21948b8d87a35205a3af9aa9ba491d56573a93c35af6683655e04a7a17f1b9709ed83e70d82a3df59a2fb7c051abe508601f322ffec089c49dc666ba04366c038ad59d397022f0f6344255f4d98bbb17120441cc75107005a74db35459c63770547a4afe59f2703894deb67612448ba7c4f6feadc1717f6ace410c6be62ac319cd33af285d17d55f500e364a0abe71d357ae0802af464b6d2732f3fb94bdb3baa497f2e44727bdcca5a4b65ae9df189ff1ac640940ff4d479a8072d34ecc523dc8fc7c87fc89a540485ae7bb3f29b041446ca427c0b48ca7515a1e31788e8b53e1122d372b6557f8d2a97cde893b20e60283954e2934af340a358a4376dd0cfcbfe305a2ce7b72dcfe2de105cf44833f548d1bce88d34b60bd29b69309dd87f4b91de10ebdd7d7f87d6231307d0ac784e0496db725ab97656c34e60b34b230f37e30fe326296c4e1bb88c0bac261df0e5f45e6e126103eed6b1ca146d58140a8893d847e92d9f3a0a883e8bf830147cedbdc7dd42c1a58a826a8a827f9ab26eccf64f68e9ca6b68261260b659b47e0dedbf5b077982b24ed9b36e8466dcb21ee69b5e2bccc49a163b4860ec2ccbd65032776dae601e18ecdab8e35c2760d5758592f6cc074298a97fc5e82e7da84036fd10e0725a0e4e58cc4db30499abec0c7d95d88bac2c58eb093312779bc1b8619ff2762fd1ff009273456d829394664c31ff6d7848b27174b36e59fb65d6bef6d974d5038a28f49ad465b28857cc12baaffabf3652c2e22b46b040e579fb040a0fb4b1daf0c157d35407c0b78e305ceeb232e7b7426c95639b1cf7b079e80521faa538e51e69255576650c3a16e143d0f815d2cc89eb00aa13af20394aa23cc6aa99a9f297d886ab9af2655d53816e066a02cf21c277daddef3d7d0825d094fd8fbd5386139757efd0b7f8501829725a4b70ff1dabf2958e07ed21db76266a88483ee7c51a7d215e1b41d2464911abbb1dc71f9613ed5446e4b0c97bdd47f22b372fb7662956fdcf3b108e0107f74301a054fb004925b041af354c04c20fd370ce1a014ebebd8311f3265a2f78b48124521a4aae240d3ba9f94fd33ca4a92d24a029e0754831869b58f670435a44dcdd7bf75ed9ff06dba52980dce49c1c26ba0965de3623f459e36127ac6afad4d5598fc45a95173d039cbbe2cdc7dab2865fb6bc0fa8dfd33c4a826cfc77bb7f45cb5aa73377a27271ae41630dd3d4e2722581537fcfb233e5af8f04ca824012b5c429ea498f4ad44afc249de2229fd7266fe84173a5ce44632b3650d6e1f278625d564b374c10c1afa3f17432cbe4b65327c6b6e0cd2f99b68ab043c5c6c99d7fe7fcf940f4887d309d7bc0ffaa5dc4b90c79266514f46ca2d5477f2b84b04e30dcafd0224170fa6d4ba9ad2a6dfa8ed73dff9d5d40d43f02610032719a7c5646ccd453cef409b4325f3fb6d9b9201fb115e4dfaa0b4d29959a44518774e94b2d4d6d06c7f065973becd203f5cf6cb59f869340ec6baf0121049db3e1146234cee4657c1b821af817da27bd4c9b1103c81f5b5161e6a9329d83d6e4dae1f3299858cd201222d34a85e2991bdcf32e9771f3e701897f647d62729c9805cbf118c9fa727b056a7271a23181b92f033de1ef113a856a884ad527b8deb92085af3db509fdb0265fba3376b31bf753dfa477dd5e247d939109f31cd430a692bcec4d9fc7c5b4630cab90c64b75496bc7ca54d5621fe3315ad03ebf1afd6d436bd2dbcbe707b35f916cfc147bbb5b8ad2e80abd692834e42e0724c8b901f5924212c4129f7451b9dd860a85855d1ac59f0b6b87a66b6a395dd81990aa3debf64c91cea6862b5793bafff81677fa2928e950d94a6333b0e77a15ae461e710be70afcb9fe6e0c21c5ad188e439a6e5138a2c5ad17126e759d48491e3f3f93f81eeb77b7b3a6add96917cf0beea202eea5adb3d5593a3dc9ff1f8f05dbf5a2707edbb6640eff5b65a0003cced2eb480942a13c1f1ccdf9994f1d11dbef0d3ba7c3801aa508c17bcf287a928b635f475195d88adf9f4c1ca7d3d1462dfd0f6939b89e5ed95f177bbb12253391876492bc01aff1c1daaf0a1c7821c2a4e33f52badf51987e010b391fc984328e020206ee98e9c8e6763120055f99725e48356fd800e11ce973d00c800c353a5df8b028e1e42f817c7433084c440e47532fc639172533df35f0ff43257841c3e4ec7dd7f601eaa81e9886fa3253844c195a62f89fa5d292536be8cacd80c94bbcd1a83c985936353c9233e512431a8863d7d8340e89307547bd10b16bf2c7e0bb01ab8093c70e4f4c8fd30608fa14ff072d81048391c07ddd82475a280d4edf81f739ad1a13bc6483c3c37bf52ed52ce8d568aa81864acabe225bc6467c79fbf43781f29b0c508e6825d4e56d25e45a8c0c6298765069fdcc66b2c5492fddfff69d6f5975fcd81041f30ffd7813ba3219b3139583eb588ddc57851e581fbd5e20127ebd0000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 87","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d399ca20d4e3909bd093e8ca453a92cd33e6b85df13c9b5c4e8f2f98a6dd4f8f787e81ff4b8b38e1d8e23bfad106445a521900cc3ad7bd733c8aa8a81455a4a77865ad9a1f759bac389786649da39b7dcd75e4c0f876af1a9a53d533c2e238ff2edad1a852e3596c82ab885f3f24c29c8d27b7c56da263e83cc36d2456e51b5c6a2589bcb5ffd5d3bf9c33d7384c3190630882a8a0c1482edf611c65902c9a31ce475036ab335cf7f0bd77a95c7b60b4f4dfc4a73f06aac5d306873f586b78e9363ab53ad41274777ed4c38bf71105703fb5b49a515ddaaa30039e639292789f4d494480eece5f123366cb1efd4ab18188be9c9831b5ae27c83dabbcda71f0e4a0c29549368de3fc6575f934accf42e6f1ed7cd0860f97ae0dbcc6e6646e9c0ccdfc9fe87ff1d92229037ce83407dedcc258fb8503ed8d548ab52bb08550b668a789824df2080f4520804248f7f9e31a9832db49cc6723ac35b35a48911aec8ceed64ee6b3ef52bc2a6f3ce1a4f691ee3671998854ec150bebff534c50b73595ad38163926ce2ba17b75f884f55fd618a4da6d70cd4d58d676ff0ed53f2a0a1ef2b3cd5624b8d65e04cb4e4f99b56d9fd6d52f09741f19656074892f2e428051906e5b9777c4a25a65ffaa26f7690e250f51b4d044d7c442b2681f256b7b27b955b343136653357602d550a4162b0689a1e4479c1fdde55347fc35aa45e0ba5d6caa855f7100fa72d8af057183c832baabc9068caa3a66c27d69d7bf11c4fc5d7cade4dd9b90b412868ab577f236717bb3fc95d8df9b2b58f0308c9c8d6cf847614ea23c79e4e8045ffde016589b5f366b5c6ca38f0554c6b364f648d77c2513deb9e7dedf0f7ef524e023cdc56b3052d71ae246f5b4bac265a9c5a37d96830d983e99432f88e7757e892d0a4c8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381092570afd8692d941916614a94c3939f06e619580011938062f40e957617ed0f60776400b256f6a8c4eeb70722c83af4ebd79ba6d4c13b1af06cb48536ad6a669b110569c545087f2c6ed21447740844c1b28ea3b40efe97f8f81d0571c00e825b0fd8583d9a441da7f841da85890a982a28b55f08d8caea58682a96f25647ba1a95e01847d31149a9817bdd9e650a307584c3d075add148fec91643deb59300d3d0b0a42f50b70c946802175a9f6d4892144304682a555f6eb372cb1b6a81d46d79001800a4fc54749f2f13a976eef54e29e87d5d34c69dc423602ef1552f0647ad945cb7790aac565cf590bb5a45af1a0e23aed48c9accf6b31349186fc8f907d196426c517ce599149e1474bce81adba513c062a891daba2261ba1aed9cc8a362414a131bc2ba84a8f0319ee628b69b725d278d5d74b19b9fef94a15521783b58e079ce55d67a4c655da0a5d86b0287883970b87144fe15e80a685613370845e8b535ac1a29240657a294cfabf65a12649a6256aa1837d84b041addcff4b2564dacd435e84d17949af6865578c69a866ca675bbdf0081bdadc45c5d4c572dc6ea4600077be4469316c4d5abe4b7e4b1630719d4b51adad73a7d5ed39563d4e13feec954f4cd3faa699261100c800eb83620abc3642c7aebb1e126c1bc783b9633a0d2993d03d57f2eaaa141ca3008d3065f34fab18e297b398edc92d9eed69b71f169abc9189ad80bc6fa01e8ac2c3ce5119d28723ae81ade66a21d743e038c4b90143aaa4b79c68041a99cd51faea2381282b8115fae919812f6ae4a41be3ca6472513c3abbe66468320aa53a60f92f12fb6b47af1f5d7469c46066081dfdb1a0ef4b785931bf0763c4057f943c6ab16add81ccd0060340b80d453d81ec259b1d15f8d59d6f16013a74faab103580a239b59e93ad364ce1f1b91f9aa488afab4c0ff68dbebf24de143a17f970b21127dc4f083c0b12ce3b02680357510f1d9075f0e2addf4f58eab2d05008e3321acf554b129c9490c904f7a7e178518087b5dbde3f4239504febd6918287b6f968396220a6d9dfce7815e033183d8a5e42194ec2e15e377c55f69107e620136146746920383d5cb7a3a55edaa8a5f61ab7ee8b801186c09ed87a03e840d15888bdad6df9778795dca03232089265c1bfb433a75b1bed599ee43a9308af83147871c5572611fcbb1b30aee20b8cc5813c1c5045c6719957cbdf73b67354da5ee760c4fe802ad681b07210f9aecc0500d6e86000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b79bd2b4058218a15c008a4bbba29592079583f684fead3e6b3f09abff0dbca23670ae4496077d47945e5f1ac3cd4add5763581285d80dfb43bba9c0730858293ff6a15915ab203fbe65c118b87ea37dfa1e06cbc0f24eba3f43a8be17ff1daf4277cda2cae8aa924e852c9d60524b98306927746c4eb26dc9475e8a0d0f920f33e1aff9d07ea5561e70865b2d8161b86fdd7638e7a72345dd72ee95bae1ebd2c24d2a5510abe3fc2ced397a067d215f6088d63fa63f2247427917e5c4fba14f0a22a04fd0ac1d948507751f3523be2b0a0cf2f96dc61f8187adf646d6914667759d49a6df9a327830effc9470cec6c82ea127a8b0c6510203879faac4323145931e146d962846bb1a6e84cb2c31bc686e388c853413ea7d3ebf7c752c6aec774637ee01f2817a5af133928af35f23fc3541fe7fa749a863a048efed2f8cc2ba86520b97fde0324c68d1ddde1e430c30ded0b25664ea676aac6b1f22925a40b319caa37dd5dedb99de4d963630a6fb0e8b00ad8f2a2b9bcc497a00099a70a9dc190a2ab2a058930e63fd6df342a625e9a095ee79137caeb8885117c7a9fb8df7a35d5a300d6f7eee40578a7507edc38a0d6522474e672f156fede7e1690c3bbdff40342f1f3ad3c34325bcdbff0a68249858c777551683a9f3af225163c9323a4ad5e666e0a9f44c6496269038aac5dc2767966c1560c5a09207406f3c47157d2fe5909346d8acbfddf3e3d19fe48b7c60e1c8cfb2eaab19e736b2595d33a0aa034726cb6146a01ebf5cc72eb1182b9a4bcef90a1aaf74079862cd775f8f773bcc490f6015b4d5469ee0bd95c1a32a1fbf283fce1fbf6f8cdcfc1884f4d2a899f3e7a95414de419d56462f502ee703cdba007c3bb78f20243c35b882c90cb7de3cae3f0468079c546645977347bc183fb0a6cd24481391cbdf9372e2d6765b6caf8eb0145bb269a47a1b4e2cdf9901d6aa284d919ba57163ab9929e715341bacd81f35bdbff36d59a1edabff3cad2c122386a6335348a3170337b94e4336b2b74e791981656cb5234a6f84db4142d3f323000fa98be61527f7548dab6e83928e9dd2e461f08a5bb52f241bb42254e5746fcce0f3620abc69a6e275b5e06a333360f9b809562ed116aa6cc2334694aaa4169310ed6af695678de22d3e551daf61c0a6c5f6c0f36fd3469a3b977f6d295e75abb804a43e1e7ac4708208a94e8368dca40856f1d43c9865d98f69f1c0ba9c8b33ac9ccd18d400d2559b1cdd82a0c875b5e136b97c02126c81a81eb5d1e421221564100450531dbd97bda77c1b0186527ecf526ce6bcd0add5668382d984af9277a21d40c06eb4bbbb0ccd6f64e90272fd632d47a388d301377ee745fbc9cb4c02e1f096ddf303bca4e1fb4b6df867676080cdfa6a29cedd15003ee636db8c74e7e293a087b1a5f62334585369d12d9876ed0f334c6711146643fd598f0d69bb3475d219d1f89066644897a9cc5630bc84c0cb5844087216038c8fb6750d0968d3d3e2d29d93639486c76dc045900ae1a13529e74beceb3338684402bbc3eb36870e0b37584e9f309bfb0dd9b966f0be1298dfe55d1a94a6767cae5eb3120133b7d7b71c9f2a538a97f8548fb176b0e8923b14af28ae26306214f1d392ae63c3736b9f9374ca10ebe93370c11bebeb45d066477f374866c8a7208ce6dcec404194bb1f833de0aa4700ca29681fa0f72d98679dc3e1e142852347b01daa08e5cbbfd242f7223600804e066fb5c98c8358370f5d390898fa44023a30f824f1c6a95b8e23308b4be474d03e34cf72be65f90d698dfe0d2828a797bbf8397ec87ab9ee00c76a1c7b3ced0100d3a1030136cab9a69f05cbe58a4a56a9c700bc591b87783de59369f2e62d5b885da09f25835a6dc06f954c19b347724244fda69e3356a4ef60f6a41cff3bb7cb22ecb128415cd1b89a9aec12b66f1ec23b14e7d7fd601ef7b000a0c96f386216f75710eb2c12817daba1d1295e7535331cb90a9b0d8f7542e73de2d93fe554063f57274df27bfb39bc4b78b72a88473408086d8df531e53b5be018e076032d1f8ef86d7afb8e8867b9d7728a25acfb6856d83592cada4494977678a9f4d134f49a8598a8e0f23d3b7a09b5308243410ca6f47e0bf8c43871600817460bdeb74e7d32c2ff7c40ea4bf924e795516ff7c7bc8e5fd5d64cc489f1894c6bcf0e9c312b1ee7e2bc68739372e7402e6aa2ecdca39c18d7441f0ff373946559c475e37d4ada64b98283e5a64be7bc2d1a1c148d2cdb4eda35f591d3a7e7ce15162f50ff1b025f87cbb82289fbe7f9c32db8f23012cccb87aca7d758d42019b9a8c15f508cac9284928f46f0dc1c1b6c6b4da030db9286ff8d3762ea4a83d096ae04f98e9416d3dac59e04f9e4e4359ad76926bbd9570a3d5811f69a1c4345b646bd946d0168ed62a7a431d920d707d8cc7e840bb9cf13d8abae8196d9177e8c28ce0dd9ef647eaaf0d3c97e52cb31b560ea7067b45aefb5ec2b7c7bdfa3996d1c7e467636bfa1bbe11d1ccf86b64ade9faf9287a23502e9ff711ca97d6cc09de814a67ba6123a8e4e67cf6e8cb6f7b36621bc6192ecee94d61860703ac8411b16e19644a6ab01813402629af52301c9d76a94cee22b1dca49f13b130028991c8ab383c8461433383da92ab34f1ebb4124b24c6c391ea44ee6e736bbc7a2d4660a878a600ae39b7dccaa51adbe90bd705ea51ad13c05e611749d43de336d396352cb0673abce7473decb0fc708ef28dcbe18c85ee0068fef64685acc3a7d0da9a21dd0afb10b95d81f6ae437022218b6094ce35d01248ea85a9ec6fb56a7a2a8453eb03e6ccbea0f2eadb015d8be3d09739eac07ad9e3f17d13e5f71cadfa220ecae90ea50bea87b19ca6fc5df31874d51723becc80c8845c9ea718454d2817ef8afd99b63090cba6c8089afa78770222fadee3b3b829cf36a8153efaf2cf28dc4651ff37a8921e402ef81a0f457fc1802ab06a759bf4071f082bfdc100ab612a4584b5ae19354854101ab0173d7d6a5a0637ccb58ae58978a8befd5a2c51d3d53150c336c0c0c2a27b442e2bce120c4ccf8d97ea4584434a6f48c0245b63b2255bc52adad4eda9279412d70be457f7dcac492fe53c06edeed766b46ebc3419e6da2a2847251f75c62a5fe7ae74f0dd5af50a447da6356dcc828c5f1a2c0c873e57041eb1158296c038b91f2e13d3d4b2887b284384a9ecb8bb378bb311f4abb19e1b90eb3a399c03bfb4ccb29aad80c55c1636559fc79a6c894b5bad8d529bf680631541a45eb0e57ba5b458a05f456c60fbb593dae90ae549416af96642a486f10843482afc3989bbd1e8e4ddf0791204f4b720abd2d8995c87c8a388ecb14860cf83b7a4406fb6c8c9393475082d24e516c5f1af91ceba444d8e460d0695746be057ea8d76f8c0c80358f3db2ae5b996272737516ef5e4ef5a1fe5967304cb6d00090c9623d29f0d4bce8ca3cbd54a30f9597e01e5845c1cdd8777e18c5d5d86492fdd0606f623d11a28dd9f02032e3a378c71b757b52021dce6ceec63792cea24d6dd7150ac8fcfca6554f7b08a5529d59628d0f35122504dd1542f6291bedbee09f81aa744a0f6c6dfca6207fbfab6b9e17e8a4040741f6508471e72d227d0fdc50c13f444310245ad17bf819ffbbc4e0485fa68cf1f0a4423f251538f25da989abcd008c803d368f626438432569f12d1612370e4c6c971079371081b37d8df7ee709198aaa2fcbd443b96732aaa4e6924a461b60ca4f4cb13e88d539aad709a3db84d2d6d26671a9f3877125b7a358389bbeea846a32e949db9a7853dbc7d5add92729ce1b5c00680974f3ddc6a8235c7319b6cd1ce5e0b66fe7c2f1115206c42b4c02990d79efa8be94927543c19ee93d0ec8811f9330693696c878cfadaa2d56e877d42a3680ab2f6a576fda7bf7957f781655cc664a0a4a0d16ce34d04d7c98a9e0c93d2e6d42870fe66864660b564ed4f881693d466bd68b6470af03a5a6e703dbb40515af5dca7142c4c8d79f5be4bb01a1b56be9d0936396a7eed9a84da86a4f00dcf676b4942d5df6e1378ea26d9118a54e17fc623b83aadb417ec82f9afcaceabbdcfe2f0b6ad4bc1601b4e24f547d61d1c1737adbcb46d98287372c00000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 88","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d390993bada2925f8dcb73399575c058e13a00188fafcc94b4a93df3a33f50e4737ccb6ddb493a6056f45da2bbebe9b679c42795c4d9bd4ee5471f065b2bbc1c7236d6be4ff5abb2a5bfae8cdbb330ece62852eb0daa13b4ab5234f070ea4bb798bf1c8575a6b1c884ae0b6f7e4453cac428d177bb0a85f90f0deb276e415eebb5a39fb86753794fc196fb57f6aa712adfb8e75d6e9061e6420fad29b4898cf5e2d8de13454603d3e0b6adeb6315cd17456b64a3d49b490706eb708e642bd28fe4dcfbc7b2da4e0ffe33b839f1ea6a01d34cca4ba702d9a5886f40c3927e77f22ed529cc1d0da8b8172f2664e522938e3b0f234caa8cc714d7ec9abc19d8450ccaf0751795aa7d199bb379df0f06f31b7c1d0d83db71dcd1121621699d9aab299750e0a818fa40c97d39a0819b2fedfd0e6f98dade2b959df539dd3d974cdbffdab8333b5ed625b63f8e9dadbf6d6528768f55dd4dad9e788561c28b69a7bc02e487bbb4993c7191d74f56d97cef29382671e669c892ccb3623dba7772cff502a5b298471558f25bb0a45767322e123ea74dda4b4c1a54817ba450b95e9893bb7539d4aa935e90ea9cc9f1837921711d588d9e2849a0f299c8235a6523b3e69ebce3affff973988130352726e7fdcd200be648b84857131ad589f4ad5e3cea2c93c1163b3d56e6cc954555cd97b69e55f91d0c89c4d0270795b5885c7ffe8640b6b62cab1918cc6734ffd63d3a8dad6f1556b391388882508520723d2704c222519709fefced74c92bd98a3551fcc677d699be17581b0c4d7929aa4442729ec7353c3694348a35a8378a467558e36478f9d58719aa4af55ba50e84f8e35d1e00d62bf11aa69b7d4e6948915e8bc1648f065d67d371591c308b1b485dad50df3dd4d6ef388ba1e9533a46cf4cec80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810912a19c5afcd12328c576d6a38d0366c455b7db2c6350e99577ad9bc8a729ddbb688ade4fb257eb7f6827b8eda7e6aec2898c995a844125c865e0c8996ee8362030d720772bf892caa7c2345e76967ec8c5118bb5a5115f0b345ab96f71288bbc46a70ba01ff274ded137ba74d02d69da72d5d46316e74991b5fcf85206002fa299540c66362a9dd434bc9851555d66c72295515b51c1598b836e9d66ea8af08c8f3774f01768d453764cb815c4573f8d894621461e5228097dd9aed269b015e235035e95963d33c7b323ef63f903d327060e0e682767cf05159a4c9cd05b286f64eea64ab5e16587817456ac01d81382614722c2d563deaf228081fb41de3c667f20d6772a8cd829e988a5c86071271e2879c1ac5b022cf8332d2ab608034ebcc2de8735019f28f1a1992cd22d33da30757342c28fdafb686ea882a1b24760d3d2395b30e603400d8c038d57c6d6a9ac0f294694780ce006a62737f71f968c463bc1eb17d7a2b230264086a261f5a4644bde1f9f90f1912be8dc514962f11381f42dc6254883042248c63129f8cc68b6ae11eb381a702e7e1018c206f215c25c14841a3ba1aa0283242db22b7e149a8b19357165b82788866228ae8e3083c92416406dc3dd9eac11a23d97fa2f94a7200d687d4bb202205cf5fd00ec17c432640ee2e76bb84ec512afeb643d59a3c7c63f02f93cd11483634f9c28a871c79539cd54409feff711c14b689d8a206f515637b89fe4194218933bd6fa02ade32203ea15a2b9029812650dadb583668def8fab09e4745c8d87084e5bf18c9da11160bd1567966048a50e495bc7197fd57e0440e7652d78414a74aa8f1d010d1237ce488861f455bceaa42971c49ac008debce2d0677a8bfe70d54f672f03f346e8b8f59c2c0d49c144762be90164d57f76eba31e436143958d0061a9b29e85c744698f2a5e200cace7a881e727d6d764bea6e16ba043566f3419f37d5817981d88316717cd62b092092add7a4e41dcb7d5c3b3229ceb3389c08a41459647c8c737ac58dde821eda81c1e80c955d4df7cde5cc714e85142f2dd6ac56af2bf08b60791eb4818445fa7ca5de4523c84e7c4e5cda5604d3254127d4f864d953edc388549c4a2e7ea9e0080eaf3b7934e321ec24087c37ea729aaf8b6205e733c8d09262f2b4041ea882b1da173c6e599f0cfd32facbb1af32851288d3337c9022c94968fa5926ac5999441b3a160311486fa743721fc64d915e556a5f609c56543408d7c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b9a4d83349dd620dc2cc0e9ada524b9be9b195973a839a042f4342d69e6b38918507a9747fcdd8b751d7c75abce2b482b3313d4c74ea4e7a4a91f2e08a059536b651508307b7f4c3aff5cf1579f90f32ba1e847778673e3956713c14661afa2d11ccf61fd8f9bc914d4b6e6d09c52aff7fefae325c180147153c9ae1924c9a2b8de4900bfbbc6797558b000c5adb9a8dc4cafb458ad328f19a2c55d5434bbfa7be5057e56511529709992bd6527e913b46abe38dbff90d4ab3c024a66fc0f8fb34afb96e22535a0ea8f313a087aa65355d7d5989c486e103fd526a7a6d812c0e4d8c081bcce4dcfbc64b68436739451be0c4b67bfca71be955ba9f9a23c223c7d0ffb1b2196c9c9845b6af341a363951e2008bdc4f3296dd0e1e3f480f2e4b0ec77a002eccfdabcc58d24cb0baa26eace96decaa0f6bf1cde0175afa65ad5c23c5e71b50df778208edbe426aa6e876c12440d7c4fccb42d039a14509092784baad37d9b8edf186cd4fcb3d9f8b0397e951777d602b8af613060fdab6b358302b3fd28437a06694f36ce12a035f09d677e48d077cefd1676d8fe51541bc19e3a6d6a5d879c4f9eb4713b7c0f3a652f3a05d74dabff79a302fdaf147531fdd57924f49e52b298219b03d6df166b481f232fc85c7cf52838969ced2dcfc18dd8c95891c498fb49289d1a982922a0fc02c849ac3bb7fa92cf43a64464d5bd919f75ada287fe657bf61dc07b3808c0fd0d71ea24de5353268b2c17c989c29465ba49111cc479f51a8cc623cfb6ff68149e52c77a7d85b5ecce66c05900ab9957bc7ed39e03649a103b5b6bfeeb168b7c1f30dca84aea509fec2b215dd95558a2708839396552f517a8fda28c3ed61f84e1b2e0dcdfa708de50d44bfc65bd4e70260c437c8b5b7158ec7e2301d9c7aaa68e0adef89fdb601711ad2998379145b29ce3681b513dc3ba9b2eb668c1b53697833670466e21e767361c0a4362e5b8ddc38ee6a9c4dc5205eb808b93c72ffafb635b4254e4f4496bacc753c8ed0bcaa88db683ce77c8165e8ddde665392cccd57bc07573d83cb3aa10648281efb08f92aacd8ab6f9b5d7fc66d29526bd57e421220ffe375b26c61a0ddbd9807022eb3b4b681a43e7719f5ec255c1e19ae6c542d6deef3b94b6960c18d0d7c8110b88f995826073b874042faf97f1ff034b8257418ca269f5ca588223393b0179f9817e08e7212d0d410ea259ea66bc4a00e7fb1190a732bfdbf7adea0e4550be90c3e37bf33baf436955742a2632aede259235702ea2e079d99a22c9755ed34c1e3ccbe746e728a932b1852f692b103112b303033ad3ce1172aa066860df570d21ebba51fab72d5afc4ae8995f532ae384cccc3c4a295af76a803fe076ccc920a80d82a9b614760ec43208579ef5dee164356d62ea33953e55195eee9b2e2018e6fd9d19a9f49258702dbaf6edbfd093919917b1b6734f012e2beb4f758dd481fb8a8d7796e755c6647501e28862b9f5b16ffa1c5d80dcb07141806fc348881a5a8891bb632a4ae4292a102d71504d0fc12c79d15bcd0799d30c7b9e72625a7df7dbc7ecf9eacc627ca9ae5d71e264f2f2a9d5db8593f3a90f3915ce480adf800c99fc2c8692f2b57b492bf9d84171f8c29af8d5549f82d3730927096ca18ff0b0c0c0b8b800508c44d5749b92d7d48f7fbd5c86e408ece0eae639af475073df5ca2cd5083bc4ff8852ddf5c399946a6b21b0841d137f583e0dda3a6046f082872b783eca3e14b21a2af61bb150847026f2371812b1a2be72024226f4613da860ac2ffc578dcb171dc27b896eefe49f885f9be4cc8766f37038e01cf20dbb661f507b2ecf2b023203a6259b0a018fc00b2ca9b3107b605f04388d5493ae7cc4bdd093ce761a92847c2a167739e0750b427b2aceb3abc5ff751a5f32d36b589787d4da509c85ead751353ab2c68a9c14b8b2c8166aeb6f27c7f101221c306aac74aab6b4e795525fe12038725d7af3d2a6d60e1ea85f2b94ea24f1b72fed9ddad4c8e5da484e80a2150de22e6adef41153d7b4331e8f011a3cd48dab02876b067312d0dc736e465f99ac3c9c56321507e79accf652e3857c749ad92dad15350a6b4b67229a3905db18ab2053e2d4f92f156a1d76d0aa891364002c991e632b53fa217aac1709f37f3402f43b0753361eb2f595f9fae3d7d96ff050dca0b9657f4c3ab49ebdbfe8816051c4e0aff32c5137749d53b062cb61f7201171b5dd716e9ccb38d00e50955596845dff602200b30d375a854ca4e9a7276ca1a1d9ee92a04bcd78854be251f7080aba6d8325d40b37054596ad80211a50afcc1dbc177600a70e648d8beb4fcb8919214894cddaa6d63b6f6c445469a6866721d4bf1117f25dff9d65fc8fbe5b0acc8b9039c7f94b2a5cc6068a0489e2e13a731dbe1094fa8558a601addb9e4dab04fa744cd5b95a9d57c52c8124ad950a5944dee2c55e5c8540dbee5823daa624f57fd5be994bab3ad4e74ea9443f8b6024bd6b49adf3972442d88e61e04fe8478ff28916584ccb65fb15686991d5781cb7eda067745258ea671e0a2665f94fea1b5490669d1ee8711518bb911094957586c8075e3bbedc47be059053a7658adfa0aceabdd46e0dd9647b34eba32e56b6305653ed386c50e79e15084f00f003b1d12504fdd8e47d03d9f7572276047bd22b82b8e81f87c86e6f20d2a756b16f291179a97b010f993c0f839c9a1238cfc9bde8074405cf1b35df423c7566ce965681f21c969e4f3f8fdca72a18d5daa80287f53b5f8429fea81612cf63ccf1b7a13512db4d1dd2678fe1189398032eaeb4368332972c728ad726b7290302c3c5acab6e73432e825b9046f846adca9d93780a36095aa5c51e354cc6e9a910cabbe59130e98f4acb3cb6d4efda9e2f78748ed58465937fc81c548ad038fdc32aec46b078cc5a7207658a9706f1c9653359de6c4457dbfa71d300f98f9bc5daa14dbdd5ef20dcede7e9d3f7da5c932ac3338ba40e46b17d89fe38f725129991983d4a81321b394f2d7b20d66e3deaaeb6fefc8cff0b68a766e27ccfba66deddb1f541deb3c1892ed2ad5d073162f0dd06b82e8878477bc96e03101c9b5d9d0ada10ec060b45e144b31e6b4de283fd43538b47178398fdd15b01ed421ee2c65847f7a4e9aece2f1d13971ffc0157040782ad4b591dea0906370820dde1000490ab1c27c03d02a0f4b4bfab0e56d7257288441cea63175cd6bd11382e6c873154332e627ce82e37c63889efbd8537ac35c21ad7a09c986cfebf13b19d5677c1104b373f3b55198d075aac608145ff9d0c4c12c83bb41036ab32227629eeb4922f172281a66c23c35b8a3e92de0a10d5e8c18b9a54d6c30230f3a8263986ac535b6bf63eddaf6a02c9100b712ec4bd49851a22af0e647f259c2e19b9acaeb6147c476c90745a353f6252ade8212a9f7c215c0b3053bf2b4e0ad225e8b344ec14c1b839877349c3743e8337d9c1eb128b06939c5a08f60a46fa700723eb6652fc26440d9bda3c99c10ad0742c2f039be6b66749b77e14f8223509365053e87ed870fe3906a16da6c62945dd2112c96a23942b1e14431aeca7dfce3fd4d6633e0b661fb34b0bf05c4d21e689cac9b6abd9f507f08e4aab94bbef1c629c0e1cf344e66d3a3e100b615bf762dff0cefc5e4cce0dd908f46c94e7411a151e713fe0c18ed33c4c03e55e12c0ac366da5c757c7090e0f94e2c34d93ea3b226adb2979d23e071f18c2eff33bcf41baaf52f4b44e38675dddec89c7bfe858bfd1ae70d96d0487972d70f8d8681982656ff734bb6323aa91ea14c6330c71783d235d9f094cb111abc4990319bbf163891535aa5f870164da65fff395db68b390084d4f2448b98cd56103e49caaeb6cd040c3aba8290284e9b2bc423117f4104d89b1b1607c6d34ac30aa9e79d8753b97cae90ecada6cafc6100d3d6d91e20393e0dc95b981fe0edbcf88e046f74184a96705ac226fd26089468e432d525643293bda781b64bacbdfd6c7301ac42aed7dbbce7abb9d67af315bcc3509cf03523fc887e27edcbd7c74dadfd0f126cdb49e28ecad38080f18a775e6d824c18359935d921744ea72fe293f299b530d9dc9285ef174ee60e2ddffccffe89960baba90d955cd2c96672513c758142d29a1ad79ca9291bc6782b64717f11a71e6d65a1a71d000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 89","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028b39701ba570358b5a80994bd86f960109ba7db348be3aa5fdee6d034434e30a2973d072bfc44fd0e375c475a93219530ded97cc216b716ece9648da51b188caa133dc4ba10c4e75697cbb251264f60afe9aa14fa64d6b91e335100903c0eb69f90ab6efc706815d797fe5cb314b91f3fd9cfc013d88eb2144efaae82cf0fed365a5633b9f3ecc852c882d2eb51531258e262e1924606ce99ac396c168a24cb78210bb9a6671f6a9e97c5d962710b16abd369ba19fb1dd7aba8591fec1bed14ffcbe3843209eb966498dccaa5ef508d7b83fdab47f034f27cce430ab4b6870f6050ed01865810db0a034192d27519d410e5e04ea2e8873c199a266be2cbc923302e9367ca8cbf5654c239e4fbfa6d288b7e4392e414aa4d1b0488431cc670576eb4961f9a8043284f4af93fd6cbe0067337057acddd36a764a2573338c4404df08c7889caea1ed42ae8dea3c9e92b378c9e3a868d615896a73de64b0ce751ced1e5f3f0588f8553f840d9371f828350bb6916b341446a583b453b6a4fa822502d2b7a2ba496a78bb2474d7bd29533cf0facb25322dcfc5566fd68b776dcb17154284a185f513a2fce23573647e619ace22cfbf8e6ad65e6dc75f55b57a68532cc6b2050b9476ac794d4ddb72daf6b70a47a29a4c1e661350dfdc922b1a9696c9f85864507a67b82a8ba76663f8d2a7f205956d0c9e60f9997439f1565124f1288d7299aa8c78c9b97a0d8b891acd328951f957ad530c0a29a9c022c33628aa8e4faeb8b3a6adb3f9249a79647a6490230c21d59ad6336e47b71082396fa67e93b185e48f6b0ff089a5d0bb1f6d863476fa4e4f7c7e9f4f3b3f72b8c8b4ce023f1b71a57ec9ab60c5dbaa1a6c41aea761f8cdc74f84fbef5406c3c5983779fc465dc3f6ab681cefae5e22ecf200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810949680898e96b8fb7ed90c119dfb3402d2108740e002906293327462b7818b404f7e46cbb6d502741ce023000720aa4dde4b486e4e3ea5329329d9608bc46d446e817e2f54753561d95fa99d564a8cd2fb82acc659c2d2ac2695c740124595062539399498273a8a25a91fd58611844e7b7b801e42c65a32d7e015a6765ec3f556456f2df2b45054b2af862c409b06919f96c17a08064fa8047c23abd1401ca476d90d0438b7f9bf923cd4ea3b36960656ace0adf5ec9b70618a41fdade658873719b0d3a1d358bc7e1d12f816a928ae5a4671b5ea3a57e90442091a7f8aa442b0230bdc4b34f5a8c0941a88140291056b5616fccd884c249c75a250108c6a636bece5f334ab9e4e81cf699882cd5808da2068dbc8325032469bd9ca3a386f15a4d33ea22478223eca5830fa066242a1d7aeae045011e2000efdc791be97231e9c9ee416a8b3526e648bfbca279fd8ff605e08420ca1011b78a0fe2f68b98623a7eb8fc4d8b95288f955c09f643527f078dc9712d9d2a21780937377494ca47afeb4d6c232070c5b91199ea23315fea0f093f668a413ca79c7c9806cc120615743a2557d123d01d8ac7aefcbd769ef777056150544530b586f588819038df2c2703393ce905a41a362177b7cf1b321acd73ba528a1225ecd8cbe72a56a9adea9821063c64f06671878fff18840817ec46e17d1498777a275c350c9436c6095151bc0e064b6b2c558a36f6c311007048d9542f54ac6c78c962cece25174802b321810b5dd9f2b93bca521a2d991626635b0a7adb25b5874a7be68763298e477e9d16c63dd21b70b459313f577d1058d504fc66beb012cd56c4ef4391f457523751135a480ce45454b579a88092fdd32c7a92d633938ef730d1c1b91152e4777896f420c14519dc3dc6f9eb4e685e27478e479ea006255ae61ef79214b7b07283d8764454c58929c59a362d58dd65b85589f508d525308ecead712d4a206819e506569a401e2caff85593e3a23e62642a189a7f222aca0ade2099981a05331e4b0c5ae219c91f805c8abac20f97d0a2a6b34976ca2b3eec14d273897aa9d40c84ce40b619fd3695ccd7b92c00890a32e6f9752598196b0898654926e7dc4ff78c4d12402bd9f4736cda21d826da29587980458b2a41c4d9a92195c48bb94ca3ad01111030ced20c019f9d190fc84611673b3977f90f2e182dee9d630f2fd39f150e5342ebcb9116e18baed9acb4087282451bc13905b3080063365d4a97444b2506000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000bbbe0f434dfa04ec225ff6b6db802a047e221bc064e5be89a5fc13937ae9d3f22b4439bb1c1bba01547a64ab3e810bbb09706d01959e2e906a69ffddf0c56726bdb58fb039d66ac5d77c7f0e9a8617b0c69176770da328d38171f39b5220279186250139922c0dd0f7c3f96d48615fc66db7568810931d257b230258ffe9cb35f87859e08139ebf7432e948ee3f962bb9015cacb8499bc69597abae4b841b606657e2e3c51ff5a8961ad42177a9e73950e3fa150439e2063b6555624a6d8e3af4fd5710fbe722b8c6267ba5df56846a085c56444573d692d5412cb70e443761751e58c41953bb9faa3ce1f4564c825a02f0e1339cd659ab1480804dd2e90e3086aaa292db39c6e2aaf1b001b47a21cc721c0c502c46ef0479bb7d8cbdf8e9c136397febc2d83c0fdbb3ed4fa6868068477206a26d2b7e0d20507aecb2756b888fcf5b446217de14ee6a20cf7e7b732fab22ca3abbe81b2be18463acaa3132773acd7476460536111cdcac98b1cc9b2c36aeb3fb318340f7397b4b4ad6aa87eac94ab7d98cc12ea5606162877465fa2cad276cbb5d36c40a0b014c53d2d3a96825e237342dfefaa6b9456b5ff1dca859c5976f77c3d3cbc9df355237ee9b4b4c90a9dd941294431db76dbb539dc48669e7aad21808332c8a4fe98b8f043fb756b526890452fa3c3527fcd584cd33e38ff9ff783538d39a184b7b3eb649e1c04c289fb65998f6cf5d5bbb0609fc3403d85c6df269017032cd24ac540e1b294bdd3c3a0c7117cab02b1a0063a174ff26fcda687433a667322320c0dec1ea3963f3b14375882b3478aed43c2c74debfe3a734f8b1a5cf92007f8fb627cc3aad5c6ae4c31846b72e7573041270ff40e762c0f8dbceb7512d44dc260a97d5ca7d60699981ed8476d8651c35c8ed498fc2961d1e38af46f3653630773209a63838a9222b813c23db0cf4196d6654126ba2b1840a7180e653b3d6e10c4c7ac3cee93b0399d918a52e59f0215b09a119e634e6e8a9886c877f157bf7b7dd827adedbaf03c718ae037c0b262588171839e952721de72180f8eed00b01f53e098b82165199c53129576036fc753a3d33aec92060dd19aa078a496a2b214b1bfbb747a1ec64071b0a078d74d0212e6203c9698c7449326a42bcbbe8d9501db916c64307d5f1083bcc36c0ffa18c0e4410b0b17d443481c3673d17bbd7a366a5fd1c3c5b3391a02eda7596b4f869a91a32b5a02a05611371231be035edc716f534724b5225e1a72a2b2cd357f4c326f1dee963fab680721d40dd70b750a019e70885515f43946a0dd3dd042969139f61eca0e9ee3107d3d28ac606ad53f236303e1fe986c38825318b7c4597b14e1a83b81295fef49fd0f2c1e14a0b146540d853db9706cd224b376343317bf7330b0c2721a409b856304fffe60c24c441d5e2797d4696c0fe046d305aee93cc6a2d89a81eb19643636a8b424b310034612105df16516ce9607cc0a2bac5835642c6ff9572191bc45e44d9b40da36b607f570ae8c39d490342786f31ce6764f3f7a764665b6cb93e54922c6d89db566f494e0ee069811ac82e8132f2f388d68490cb1c2172d2979fce3659d7076b4f457232eb839172963f8c342e2cd18969f086f451d33bb774f3d00e6fa2be02292f2e5cad3adf5dec28932bd784801e69364962bf39e25455303e1f289052d2f0cd4964e0ffcde29e7c074e5d57e43739dfa42aad636c352d363e3a23bdd134baabc7cd1621ca638ded7db7051f0456641ca872ecdb4d3c2603ddbbce16637010e782c4bd5230992e2ee7dd904f8a83ebaa7b4c3cee15b10794ace894118304bcda9e9b1376331d2248b802557aabcf913e95f783715bb5e90a4436e4bde7d651397a70a24257c39e0516bb1f548da36c1f1f92a416dc1114107cd863f3bfcb360286e774b21296259756ea6040cb61738eefe29a67895ac69797c640e03f0e9e731647c2da93373920341fdfbd50eb6b737bb0d9fda8ec8784920407d4f41486d8fc616430768d6431ccd789deff332b239ffd1900800cedd9661a55d6d96089007e9089a117f03d7858eb4c3fe2d07e91d8cab88d2ba5421846069fa6d4e5c9161a140cc3a288100bfbe61c3b0f0e820ab12d8fc54b054a0f4c777052495b45a7d1a883e67663dcf50c2230ca5319ab31cd76435dae41ce1ee25ecd3fa0c7e83b0168852b2cab674127cd7bc9ddf9dd4b57eb40128988c7c8994dc6a5fc939ff957f06c70a4056e63331f9aad254ebf2b8fccd580285bea486d91a0c2dbd5823ac8f6846ddabcde25a2252f8da1aeb32e6969276bd2a7f94cd7dd3143f3181489272b1589fd385ba844f90e35982b53141daeaed413054cdb935f3412e31d99c1147079cb487feee85e3906daed18106b8c407bbcb7716ef9d4d34e2ff04709c7457997ad6fadc55a8fa70bc907815805578a11a012c521a1325754cae2e3f7c9e1fffdbd4be31dc534961c318d1a894838e0c33806735dd11e408e500995b86b6ecd20d325347f792a3381d2a45587d9b6ae0aa27533732a6c421ca621aac42335848d9c0dd89f14eadf2f92ec532756cd5697ad752b6260c598ec9f0e9976a950b22daea8b74fcc87f28b5e9ed83c0339e566259ecf06e5ce209065de87feee5d1e9c466004b34583d6ae89b590ead6a96cd2951705ac764f329e28c996ad6db05f6c69ad2a39d3ee230f6501f1760aa41ffd936c9dbf20de3996917322d32b946062a3c27d8bf35ecda22403ab684cdc680dd166562d018d943369caefb9133a4bc4515cd5f9c08e7c22d153f0a7733eb4eb2cd8a74a4c85e40dadef6858c5927b6eeb2b01e9b7ab02f7048c8869991068b00fc19b9545ab42181dd5cb5488222a402e827f60a8d87b09ecc88350032f998e3c10a88d4733227334812ec97c5e5fa85faee1a1e28a58641531b139aa58bef49780dceaa408986cf3c40e226c60531945a20f91e5dc31ec86c9f9a0545e5fcb79a13b9afe9b133867ba7a38152abc6d9f8ee10090bb71e6adc6a6c2513b066f2565138bada60b0bd339f9be1aaddfc90dd272b4146d0f5830c6a53e295c849c15d001176e7774fcd7619d6ef1a30ba93cfe278ab4806bbf25ce4a4e94163f614e81dff7efcb015997f5138e22b80b2b00ad7579cd84db5d1c7fb16e9e8c5d9a5ba0ad0e0a7de79c18839d673632f3d2c7da2062eae844faccaf23590b2fbf1861405ac347eb9d723ecbde54cc96bc4d8ee2178f353310e5d69230c5db2841d2a06a3a4e03e054d99defc6004a6e405fa89b198a901ea1ae9f3112a29f3aec5698a42794e04d74d761e4aa5ad23de271969baf124450f4796da1eb1c01480436ab0f5d0b1b2e6717dd87eebf137420961f978896077e40b2d2ebb5664fd8ad89bb9333fdf46c33ef3bed21bcb5b4697451bdacf364f85462f5cb9f546657b4744edf757daaa4d3a9a2a6f281184c3576b1db0b540f3b36310020bc6ac0c6454a7cc8ec1182422b17bda202729c270194cd6044210d2b98731565812339edfe5a0dad79ba826d8c566c7d25dea9bff0badf1e4e5da2b884966e03fadc51c6d9bcfe877511157201dab48aed1ab038999e5cc3fe58ccd37d40050dee92e0bd5332413a7f0118724084ee5545fb51942df1ef399f734fb9592555b5f32290c53d7e5017efa2b61e29fdce90cc3e7c1b0e545425b1d3e1acb9089daa786cb0122db3ff27ea0367751a5462230f0f248147ebccba2e16d214e9a0baebe989bba020f95b623cb14acaf2be6f157dfdb1e32627133f0d26c7b65a189f39955ee31d9b507b43126b06b9e4524732c8621d2274438db7ecaf736ab7257ced950eb68bb868581649232793ec83379a16f40781e76f5cc57c48c3f5c2989bea803e1b63768436d39ad19bb77db46aae6e8473ed5dfec983f49e4b8e7ca6bf476ab2f0272c0c2dbef1bcb064d7400bfe1b9ecce13578a20b1d5b48133a74c5c59cae0115bc3b50574580bfa99d58bcad336ee2cca5b7994c784bb90cc8f1b9a0e21b39d5eba464de34d46ac0bbe436c2f419d60d8ab13786f9a841b52710d1b49bec290de317b66b6855abe156c07619a4b998cc582e3f54a7f457f1d2839bc3ebac937ad3ebc6a9e6e845379cf1d66d7c59000e3f6cf6823b005728a95bfb0acd044eb35d5adbe8933a3637887cf91ee74bb910fdcbe797b0c6b1b056500542bd39781bdf13ebfbfe949d7ba0b7f31102e63bfc6e22693f970000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 90","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e393ec8e0a20aef7617b3cb99a5d6df2796d2438777eedf5c760f233b75e844fd465ce3845447d1afc38870a96fcb5cc757e5391b25a3999e628916e6951bd0dd4a938376a3c0e1ab0c563eeb3a8e891fe3c2a0dc4dc762044e937631de80b1d52e4975b06150c2b0ea92c15c8529f1cfaa00a6471006aeeb32395d8b1b89a8b9da4fbba69cc58efcbfb8c0a49befbcd9b371323a8e2c397eefd8f71fe917613f8469e53a953b7484606c9accccd4fd4aa0a4352f8dc48862616e85e1fb32a4408641cb1b36c82764b9518f2bb13fc3e2a1ef9af553ff182e391b74b1c8425fcc343d01a1c7114b8c6af3bac0f45bf891322a2dfba9025598a49040d67e6cead1a8caae126608cde1d3b5070b0c49963682b31581b51bf9fdbf652475942d14c8fd14663a3d04369bf934e64992e176790bb6e0728edb5f6f36d282143a084d8133b1fee42cf27e66161d8b8bb2bf5fa3ecc3242d514a37863296b1a37a5d4d165187337586aa0dad9faeb8153f0259cd4433d79ee95b2b8ff373c081cafe0bb5a67aaa51c4c914b4f6ba8bdaffac7c97386eba6065fac432c929d208c66638f9efd21c0efb4e8547181753affbdbcf649d6677693884fca0956d011764907d0bdd672a77b8c65f1094b0ebdb3be86750a61279006166eba609186460ab492a4c3bd1c1bd46f05047e88065d7188e4f277eed7295bec9b6eed33276dc4e0cdb43a1ea578ab9162886550120dec2f56bbf511358e51d827269cfcb172a934986ddbc8d52cacba526b32e448d98313d292445e0b663524af3b2c8641d752f409af7d11993f754c32c5884cac8c02b7f99de84ff7e70c8cfab1b5dacb3d88523bca7ec2073887bc5585728308cba5193cd31cd34b54aa9e6f5b1c841194896a8938048c865efd6fcf3acb12382659908000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038109a8f58b45f528577b9632006357b119e82d9a2362b04e8dd9e098054935f1af0b6899de9a367ccb5964d7a23eee6421a6b320d83efa67671488a48fc92427cb2fce93a774e169963e2cb44e866b1f6a72da131de81480d972df80d79d42413068acac0e5d92cbe0a6fc84010454b4c7a500153923c669dd962c72a44f472f37292c029ecb621e9dadfbabdc2c48125fd59321770fb6386a7dd43129e14cd234c17f46f04997c154d367b881468366bd7f8c5c06461c5140f5ae17a6a572a09e65f42c5c6657a8b42a8b27ec9ff637da768a07414c138728ce6f3f59e7117409a91d66c88717423a73b2f93004af749f56594353d6036836284b35595980e976ba9520a97fe07e61265231b110a2ba6506f030186b8454e2264af29e3508093e9fc6cf34a5032477b248808c6b2e29709ad575cfc16dd61893eeacf21660eae9102c99b9aa3210588cf0b3f010a91e591902d61b6a1a225376d2efd95fe5891184a3d5249db0ae8c82aa5b5ccd4e8585c1191ec37baecf2b2e98fe228234203a59ba1be8c53b399821ad992b14489e7509f4baba27ea61382451fb7b8beb43e122341aa4af073dde72ccd12a4005e17457dba1b2c19620ee936ea9dde0aafb9dcf553d5312425a87203263d68ae7a6ad916283f2901e3fa4190bc41643bb7aa98b5084bb0c5dbec3b9e7c90c150b21a7afdd89b0b2d944845c56f01061ad5189a9161df2784417918c0fd5e6acfb910e47377ec9bc0ae4c1958515e18990ad488bead5266ee8e3a46bf770148736b58c483cc454c62f4c728b026f7545d34f53f5c83121a8a99c796e01756ccc0c9a13172aa791ad795b020eea4c754a11a40dea9000e1958932639c280428e0835b007db8044010495e0a0111c1170fef4cea5476cb931e74ba516557236d8452c3e5f55efc77d440e08205e494fe2837b128934f34553127199f006c9a751de9f67a6cfe7578c0dbaa78f0310f8fe207f5ab1034cb1c443c6e65f25c1870b0dce898db8eb3027fca2c503043be9fa625883f804174403417a6877105a86bd6c7921a8f5399070260980a270bedaa0fe2e902e516a687202dd45358475729bac9895e60b5b1239a17922a5e2e4630d000614db8a6505f434c3a995395f2694bafca3314b6d8d3793225a36b519b1c1cd0a6cde5c82df9fa81700dda8ec14c642dac238c4e0066872a976fb9c3573e655e22aabab6614b1e5a956ef453a1ff501ee635b4a0171df0fee5972045167d6996795309000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000bdc2601a39b6d7d91de539ef11c3b67ae3eb1607716f587bad5f60d311a9f4fe7f04350ca085eda6d41c4bb6c6e13e376bf8a314ddf791ae18be2ec0544afd3cc27bdf270c4550e9e78d497b92349ac07755bf9167b2958bde919123439d6f49c3408e8d88021e668a0a5fb6799330188e35ec5939b77097e3737c4f664d01d85faad0f583b3e95ede125587e2a79991750d5cf804325c72dc8ddf3471ee8fde02519d2d0ca7edd651eee30b3be335ccf7fb02059bc3a47ee3c056d4929ead4fcd82c8cf49625d5da460daa299718556bf0f77cc5cbadb99b64c8ead4474601fd5c79309d4e63aac392853072619efd7b958f0ebde5cbd40acd57df269a8810776d6dff2e637ea57adbfaa08df8d2581c38cb262dbb4d1f3c65a4fa068539d2056e08dcf03baff006edc688023a20728b227a99fed3b8f2bcbed2e3e6ecd8b8665a2e4d233b78d7c33f6e3bd9d0a24d13c8eacccb53a21dda9e7a34f9a0f031091e65f749c9ebccf3ddc4097a121d8c68eb7883405ee34f6a8b0208ea8d5a3fab53fe2cad1110bfa6e094f78d5314880bb67bfdfbc2df8aa250f1d7200ff9a3247c4976dbd1bbe99df02a3f246e5d466f85ed2f68e0b2de06b0f2448a7b98fbcbf5872bcae71bf0db4e70105b020ff130141e8de86dbe05b7d2a234ce2ea83a38e23a262e46ffbc837e8a71f657e443052e9a49dea4e344d497dd2de2afb4009d681f232bff4feeb173546cbcc4c80c9f85b1ce125be678e5ec62ef04433d55d4b8829b01ac165a440fcd6594f2c0cb456c8a47444ab05a0f0717b8185930d9738e885d24dab98e11ecff7d7a48a4527f94fc4c9d1b9d71f5e6bb39cf92b1a6d0509fffd42e77ac9ad6f50f8fc649b96b8ac08673f78ae8d0ba2b7243452b33aac44b06a2b9be1ad6a12583d3590a3f9af0e0dc35da88a257170d315f32f3a889601d6729433b7ade0f719386723eb2a008634749f5253cb7d9b2fc99a1ae1bbbe7f00a536cd38f8a7237d3992c3897df412f5b1d45e1ef5b5dc974d49cf8dbf785160bc527543458fd9378b3d4d3124214ae5676185794209ad0ee73b063cbd5b7830d00f817ca0d5cbb597c44d28e4885d935b7bf426c1339c500daf4f2033fa6a27a4196f233256650472f205d2c5e00e7087fb73027b0c6c9ac5c1d928ccd190b8a6bb33f512ca8e2369dae6111156de47a24469683f4721a25652ff87474dfd92a028b3ec5bcfc244ce442752a7da1da6c33fc22573bf0b13e371ca9fcc86c76fcf7a1654eef4442e47399835a06336e62952770c6e61c573cfd07b3ab631b8831fe3f5dd2c6df68ebf2f8e02ec9f6b90a371ed5e62c8463780ac453ab6f72d38c8f5212c8b650f63b98e3c0886b6a85ae8e7256c1efb30969532cdbf72184aecbde2a17b9811dd4222d080049c5d36c532cc0e910779d64af93d750ee96bda87562ebd3830fead07a3960cd6de7146603199563693392d3cce1332df35c2c8a2c251911d38e95815ce5a4ce5596e2d77711d87cdd54d22e8f0ab431bf8b24ce9c7bd6d077e436543c70b02f338841af0fb86b5ea4b6a47e27c1d83e1ab06801044f546adada437f3ce7d788a1c92a74ba540664658e70d4f2711979153ff1589792859c3bf122628479c7c35eee951dab8cdb0d4d150c2da338346988d34f8c5e589b231b5e00849611ba09711bd3a0516fd515e6c4ae1e8a3657c282c8120c97aa7a2e3baa22b6eabb8d8212a9a48e7759a9daaa51b538f662a05fb897067b7cf9d2ceb47a1897214ccfc225ce47cd60e86f7dea49e220f7ddd6894b30b66460decbbcb2e42b31f4adf0aacdde544b9124ea5ecb04b03c448b17e8094d489f516d23164d2317d3a1332e0500f1423136c8535d69065e880af34cf7e36db5ff2c18122e41880585b4d188411e86b370a024bd6e28143ea2eae52eb46be334a21a02e21c6755c0182b9a055a7d4c7b056e4930ce63edc79c9fb4e2fbffc58f776086f3487f02f8d1e7c8519c7f452e75ce5686a037b3642b95d7526acd4a81a47112cf96a8da7548016a22e9359198e871dbcc5852fbe14eecf3ccc5eb2fb5ec31d10474df7d63482a03e11f4aaa2eaedb714786e21d03af1cd644d06bb05ff7b3959601580bf50e5f7f82ff42e9cf2ffca0c67ffc52cedc53c7a5c9efb6c21092dda374d1cccbc78bbd9f5ee0fdf6da6ac60c95f7c2e96f17e3c379a52d5dbd1a92dd76d1f5dfa19ea0408e0e7f7867445445cfa60bcefc016e68872fbac9098fd6a8e84731c285570b1beacca6f4728958e7924f7a7b7730b9bdc9aaebd9e045f464071843c650d06c96d487cf8397286f81d93d0cc2008a62ee32421e5231998140909474f6d98541d899ea53714aefe652a3d792e4c72533332c3133707a49293e3b2e06ae18f2f81d601aaddaf2fd09ec59350e0979a5ae2b721771682a1bfb5748d000f9736031ca971288f34993df10fc06a16a6dbeed8cdaaa8127f3b71432e723558f0281459820a0f4a75a3b2716f976bdeb88be9c73f31623050d7c1a96c84988b01d847309e1b6d7b815883f83c9bdb7fcdaefa8ba69e25b824812b7d54530a3ecc96611897661158dae1b4aac112e9ac13d07fdc03dc7d5af23c08c5e4bbff737238fd3f1c06f94215bf2351dce9cae14b4dd4745ac0cd626054469c6a5286ff821ba192706d47ccebc443dd67fddb76797a8b78dd0daf850cb5d181c82298616e1d3a92f7fc82fd256857915773c7ad97cbb9710373299ae8516b8a1d647a13c7be848e0269ed6c8a91dc50d0cad21430a3bc9e718a13d1966a0182d9a24fff7ecbc7876c868af2baf2d8b782172c6719cf140e8cb877fe6d78779e1bb31c70c6c9a6a77529c51cf78a5e4fbd7ff6153b5195817f80603e5c5810c38cf43ca812eca52f73f045e33df4e3d04ec8c5f8b4a7399f6cbbf0d39dc951c476b9bcc002720ce89f09c3885673bba9c90d20dccca4a82ce5beb38bcd60afe2ba65fcfb01c8793b7ecc0f0b17a9da74f2e0fef4c90b5132fd6baf8c010fcb5e8e7faead7f2e0db29bfdd1811072623cee274ef2efb0f7d4191f332aaf20cf36ff89a2edf15f7b284cabbbef46901271d8c1b180f736125c8a44fe164ac7e687e9a58c3b1775238bf1a11f99bcb583d0e3c44bf4f76dcf9496a06f80ca52e24d55b54ab849d3040b4798bf5292b0574672e9f844016a52a4d4e4dad2053207bc97215bcc1bb93271c03c9ad2dfc7485ee2ed399236aa06cf9a12972e21afdc587a6334cd1d71a7539362d714ba26214664e3b4bc39cdb1db847583db8e002a2aab451b4e5bd6fe200730bfb2745d03c82b640f4ccf58701708f724effdf98cb04c78df36b7a866cfd596bf5ea18445eea0e34ed514d0dc2625039049a0cc82711dbbedce339c77f9fa1dc60eddd8d58c8f144b0f3d00227afd8710bdc66d29809728d7fbe85f08aa38aebe5605da29a09cc0526fee84691eaa54dc3744bf5a95275037fa2f600b1f91e502d5d81af48f8ec4c1834fe625fcdf2364067048727559047e07062b4d8a7d3851853bf28be9d2c511451e5fdd9459270328a2612dbff42e1dd34005a3da1226a023162f454923c0337e6c74b44bb27a3b1ac82dfd68b0a6daf93473d97a9e4591ec01a51cb6b47e2c7a85c1ffa73c35e5ce3003bc4534a2d9b16ebf9fed6464cb1e0cc665a451616a62b6a8481e4506a73883198c144a06331224d358196c815c811b103959edca35b26bcf86f41d9c7638547496787885ee62b14af431cab2ad4e0224d33476c58b8b0833bf13b50be2b1d682ca7dd194b793ad2c6e4ee25aaf95459302f0b4daed907a317bcc6a5f8d76ca9aa0d799f8ea39f330d6244bfb9f35e6223a0f665a65f55eab9bcbab446d7fcd424dce87f234864d2c27ee84600ed9193afefb6e7681bc94f514fe0748eb32d32262cab880d79cd4fe5cc963a4f688d448f2db2dcc5b0ca87ac26dd8506512c100273b8d4d902fc054d48d8bf9ee818ad9619f68a8904b613256db78c881cea3373f0cbbac336a78cd91ad9d60126e05cb8c16e9aa8482cf1b806b2f9c57bc8d63bf008ab2e49ede8e788bf96b9f1db2918dc5063f3f1d5b9b1c0327141acc0b4b248ffdcb8bcc127050d27c805e154a4825dee6be9c8d4e42b1f5efc1eecc6a45dbc119afb15ccad19789eaafa8b1715111ae32e2aced2278803b60e2fd63a43317498244a7cf7342342b60462510e19d83240dff5d58e762c093df326ea503fd347d2a92a5a4680d5e13b305671c729179fa21be83b0d83144e6300000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 91","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039c8179bde0ef14fe505c12577519ca2a4ecda5e4b243b06e526c8ba9280d0aef4565042157eb0777852accf08654731f249954a64be4d5280acbfad09bec64dfa1aaf1ad50f44483cf09b49d0da2f122c35b5282af18459de070f397cd7ead3e7d7f393da5badb3a0c5c80d4a652eab90f65d2d77bb646203adc09f287bcc834cd4d3d32f8c4ea7af39d0203e48f08cec5036b6392067fab01e1a46b021af96419024f38c738ba11cd82ef7ced432b79931a2a0c8a2b72caa82b6a89f3f3d00cae822c916e602b5e46aee06fa28de76e01bcc4abc9e145e8b29edaedc5e5452e6b86f59bbfbe1a93f6dbbaf15a94bcfa7dca1c69b731cb2395086d92fe114513061e7994fd131252bce24ff267b0be4650518a1e888aa7e93b93e571c65991d402d919c7620824498cbe4dbd994dfe7963a7dc3fd7e4f8d3a67e495c35d1dad27ad8378182dd20734cc292d9a0329be6bef50556d23bd631c4b3db5aa91e7613886d73358d2a3d33544cf262b6218482fac7bbe28ca529bc66258fa3c0b524c8e873925a11bce92fd208a382c3f5b79f7a27b708c522f1d29541434897b1228bf428f41dfe9915c6145753b4d06546cf1c63191ce26897f4f9112230e02f7aee93391e70a1ac8431dcd664dbe326d5e3c8555781e2badc662e39814bd8465a51ab425ad92b1133c7bf781bcf3ed1f49b34277e3ee9561f4d98d0ac5ed3d47764b8e68532c554edee77658f3ebc69c7adc76b31d5b9417ea2e5f1ea3bf98f333318f98793c44e1ab595af5f9247cdf5bdebf606db6aedfffa2156cc3bfd8416a6c3a39828291b4c0fd35d8516284d7a8b9b95d8f4b863b766254474d67461f4697a56bba7f9f823c77d5536dc2dcc0b6705624b9ebdec8b11d6c1023190beac83b128d4cc1cf71a26f1f4f7f5a3369ec0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810972ce78a30f8e2772d4bc51bb09a3984580423a4768a291227109965932d458b4231ee5441d45517cdd8d5c4023d93e95a01d9e45702b070b8a0950f08844508c3a2f24a90e8576ac90d2d95df557849b99be8aacbeb6e9c56101c2b1663530ae97086b4de2967068011ce55725e1d28ba80ecaa5bf9b664df67a27355fabc0013e06885155657d49538aa9ee4c483ce6595bdd09b1fd10bea889b5952aa44048c2aba203b75b57ce20cd0123589084390cdf078d5d43450ee71125dfa84856f3488ed5b7a0ac28269e47335b18115adb0a2a62b5c16a0422ec427ee2302358e035c48380c113975e645841ae88c25b922f8a09d06c15b630e2dccc642c6e94d7f5978f45a01bf724067fbe507b86a2e732a2e09635d7598fb4105b628a0da51408db55aa11dc56de950b46235a55b581124aea1f2b2a15a1259867ae5023d1b86ca27cd213f389c22755e0b4410eaf9626e4b515f8ebb7288d1eb87a87687294fd424d6e4c97380d805b6044b3ce5e1b4516b32f0cc3e9c0e3d6159e0de81ec7c35f096400f407415076ddebc60e9a231844614bd1cf8aca0473f92f138ebaa3595a8e18378a4dd2a78bb616727654094e2861a9b5f00c0ba2616d65a3f5dc96a8fc5e40f698e27462025a43023d50cd0dab50dbf0425613db2ed7416d3923b780e51216192e85416e9029fc68f85566ee47a8fbf45a1a2e478ce5377c6c0885060a578ac7de3940b37897ac41afb0d657b56bc898316bc4819cc7b43daf2b93c6fca488bcc94d09363cb95a5a338d606b32ee548be8da084cb7f0baab300e384f196693a5ad290176d008560c1ef4d0289958315e45d805c29b6ab255a73fcf699735180445d4767c263fe38dd492363514613e160c71018ca5b84ad57159ec267b4fc179893d815e0cac8381e49636a285535e9e50a284999fe806b1e3e2c61b88bca6789d56b3211946b7d3405c015f321e8e23332e52bbe7d8616a840eb61ea4941af9ac8a11e9a18b1430aa3feab7aa1155e7fcc651b0dada235c5b378cc1a7e8e9d9b12ecaec95e3d49849ac12ba05e2054d01d0a4fc66b2666e748980d7e1089d8a9792d3f92b4e6ec262e5c9129a2e20f21c42a745f616950b1b80fa2b89a6a98e031cd8e0d09b0901718f041b8957b982b9b235dae46b30390434a32a45f2f7e6209dcc7986eb4211102e08168c3898961daf2833b84653fe5cbeccea3dd7b10ec2b3c60ec2485f90d6998ae07f66c6707995eb7585d239a226d467000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000bfd9163116c86e64d90d35cb216fed71bdbe6a0797a48cb915f5a40fc8d31ad340767058b28cff0c240720327e12e653c1f98b5755d8000bc01324db2820781b94c4434fda76223845e0613e2526a95f28fb4a768b1487aa34dadb28cbe8df4fdb510dffe672ff004f37c7ac32072a24c0f12a050bb396ad56346f4e0ba75c0efac162288a7ee8a63255dba5cf451a0932fd56b05e40edd491293e045a6081f6586bdca10b41a6970d8f9a7b3b6b58aa772eefa9ed22c9a24a384d6947770862be4fe45c5e0e56fa4d116b79699ace41e5d9f2e4c245059cd798dd986a3763f527e0c9d5a88a09c4d76d447348509fa7d9bfbf3dea59ea57711a3b1a9352123d4a74df273fa24a89bcab42a6d455b5fe3c503f1ff638280f87c740b9e4c5ff20133cbdfb8d08caeb7de9f26811d437e6ec8c3143c0419c2f5135d25c7f40c7908c03f295fd26f1a03fbc7285196be40adc6fbdddc912b3bc94b0bce08dbc2185ee3cb766325068db55c31ffebe4b1f6848ad4fc201a5fd056916a397abe6a66ff9bb03b037b50ac509e46ca441ed45812e3334fd7036d190a7991e55cb817ec2a63cd800f293277e7d15f086618b55ad395c614d168fcedfb274fdf4fcd50cb976f68a266c5365e02a1ed0221ba4e13e70304824f94251249ca23c089b4d54e02ea03fb7c9841dd30404428aab2519d68cf564d75d18530c7d062496c120a8f5305aab23ae52255ec919eb0cd875422b144bf47f7472349558e746b0eb5493f1fc40abdadd2ed84a8b31221a485052369fd0b552972c9faeb1a78e826ba4dfb9e91e301db589e9d7c256e7051692c48534c6a5e2bf0f45b78aca66d5f53e549827e15d64e2f294f93d43b9f36bedce6cebc05e56ced3f846635ae3c384c3fd55b969ca31e8c625103c2b24e7ee45e92984ca23a331c5b14281b20116069c619d82d6080c6fe35c3a3fb2e73b695cad9c5d3300814fd65738dcc3eafcefcd24361aad13a25b3570d2d509fa449612bdb5b49e0605d7eb78449d1db40660af0f3d8bcd4869b6f175cd28ad72fe2668c3dfc1d4963d0eab309dd50b74b9d2947f86fbe9864ae5d0dc69b55b182ac1d914b11f631193f5f1f897ce52cee97d7ae95631fc2f2a1ae9b672165432eb2e5633b55185afa5e883268d8503aec10774d25d39c800b74405414fb06c55b8c48835577884d6b4f2f128246563066f8f34d76213e0720e899fc1f11a3b0a591885d82c688e40d6b44b54d6c7c6973156e2dd50c40a28d2ebba60f5117d64646caef72974f4b8362e4820ec04f2f373da8d883af27518567688146f16bf4e10969e70be8ace5d2ff6a135db1dd738907ea355fb6d243904f6427d11592672060da14443b55a9089167fc9d5efb2c64b0069795c341f90daff684e566611ea87bc40a4c45f22c23ab6888a754b89e4c95bb54629ce74ec999889c82714b5aec703de7bc080b0d2e622ed53b645688ce164ecdff4ed66c86049b2f9077f2a94cd685294f8ea9cbc1de29a48d39f6b308288dfdb47731e39644b576a298646752f5c53d7943a5d0f7dbbc9604902b61b8edefeb5ab7e5bfdbc1e6723e6047894547e440e918038cc13b47424ccfe1a207e08a40524b553c750683f5f6c960f05836fb9b28c59e1b471fd5331f1811ddf3eaff73798b7ffd6c9714978988c440ca906b4782a410372d70ee65a0a803061708003688f576e2d3a22580b706149a24b93a162be9f1b546680a1db2a8e54a576c28b4772c50a55161b2994514369c2192b2c90017cc8282f41d28099f38b2f1f0d2c0e46b444417a2078755591f00f01df0ce72b1d1bd255a14d2bf67ab3e630f95a5da9bd9e10f08efbf6fe722cf000c32460fa3271f18b39eaa4487c1ddf828b6bedf4523837bb3425ba1c1606e8d5d1e6182aa6a74f068f3e90b42641347ca755779216afbc99603391fcef4e8e5aa202bdca24b83ff42f4f01232d3f2831cda2db76fb93a4cf6e9efb71b5438a4b74c3190a8901d73566c50727559ba9bf6317d116e8f5536bacf064d3f86282e0f88dd40b63e75519c6a8e5664af8e1029fae87930f523e4dc7c2dd6dc3296a42a59f178d438866d929a70951bed05533eb1d818b7c7c595971c26b1d436d26897d6a6eb036a13511ac4a3bd724f2ca57fef07d2c0730800d35683d745125f4237add64b538b7dab0d0f258daf7de1a74f74a2fd010cdee810f514fcf6045f0cc84e2054b5f4ec2772718ffb4cca9c9be77f8f007333860180d60ee4dd8ce976e63ff49aa11dd42fe6946515e59da3e602b1861bd3f63c89362bcfe8438bc71959a617d8d63331a3d903bc5734b777fb14f7a2b063d79ea8637ac52c758ef88df217b95fa8fdf1009ab28d8a4f318f78772568cc7aa9e3b3e001c0111b1751b698ef1b66383d6b3ca942fe4f66fc97613cfbbc03eec9d0b7e08f80939d9a2ea1f72bda7b0d655ac3a94b4c699d3eb1bbd6076e63ef5c1fe9ce258b55d21164ca7ee03bb53d8ba4306f695e648093542d769da95a35ff3a2c071dd8abd5a82e217d82317065d50a87b689ae3a2ec7887957bb243373cf986490961220ea61ebe12ac0287b185070e124fc518c300620b4b6d4f29402b18c2462a7985c00e2a87691053b1fdecb7aa264f33e27c6b201ca6065ef79e5266513aea92e8d3e646453c089b5eba66d14bc45844d0240d2e7737c16668fd53e38a93d6003146019777c03644c300d06927ef6994ac794914efc5be0ca81680ca8c9752908fbd2d56d7fd1fc1c76eed755408f1d7802f0d3d0f347d82b162ee6f0a2a890e083c20b822fa6c4ad627f4ab5d1526d83d897c244d6ed4a427b23b4a0c19f4e8889257c1373764ab7063b5db8ed9c2443cb012381a2b3365eb568649d7ccd52271f25fd22fdc397e4c9c536ebb452cd2cd10dc5010bf433f88cb58d2b9edf2bcbfa83b782ffd4388f1bce3f8f9af5ae6be590bdcecb1bfea846d2f0199eccdb0c7e4d419f69b6a428eaeb462b67aa40340417bdfebb6039aab8242e39f6c11ec136d73fb315cf71414a2a1203af08fdee34ed0072c27462395815f7779012a41ec526be53da954e1f7a7ebbb68feb15cbaea8add6cd0f2fe3d3615991ab54f4c7884e8a80a9535f13be2ed944b3bb315de8af2a70439294cd53f041f41d3562be840c78efcb08661b1731feec46a9091ecede3a9fbc2dae42c72ebdd84308e95644373595db62157dba7dbf124bb45de6c2837b0066673bfd215ff915a8d41637eeb029c345e444251ecbbcdf79e246a80aa4591976a00da06c759c6160ed1986f8e15a562417da55109174628e7b11d49586882851205755b4f99a875ab3599fdcc094e4a2164e1764d24de805fd7b20efef2a8e23fea4e206dfa1fd9c31d90c1fecf745d3eb886190827d952703aa6a99b5000d8ee9d51de94a82dd053b6aa89cd7e94e92d4aa93a9224d3f688b5c834a53f2993638166a3de78aba7cb930cc5845f9915e6523683715a187e940fa2a978b5ca4c3b80db62e96a600f1864bf0b1aac23b1330b13eadd3a2f07ce7181d0a9497c455d228278e5cc3e4c00a2ea3eb8e5b9ce2799256302b0f8f1f829d3a3ae8aa7cc4ea229c5af476c01b8d48a9f6987df57c3469b6ef6dfcb488a3d5b91fe17b5798fe154ab8399a2e75f0d15b2a6aa91302056266b22a38a604edc374e2d2155abca119c11dc6827a47e3cee7032f6e0f59708dface221e47041cffc59ce0334d9b7c5e91c2c320a70ec2f32906624128363c893909f47bd970df652d5e6c2324033f32b1653a039f8c051d9dc8f839c50f5696e9e08f7f1cdac4750b429af03176ff6e643eca1d8fc710c6cdb0d26074d85316f4c9084d5f453f6d36c1cea0e389f3462e1478e2503c1db99fc46f3f0627f173672c21f3cc3b483998192e81efa689819d0007762adbd141a058587e030a3568e412d25662c40acdafc3c6ee30c10cc23e3ddedb6c73085c90c89b1218d67a328f06c3637a786d4715cb9f9d8b0b22d920b68b0557cc80a56fce0b6e2d6627de576e308757a8f37821898e96785ae323e413d3572205b0a5710143a2621c258c76c7c3ff7100a2fcae99c84d1ab1cecf7fc5b1e4698bfa3ba2a0856a65f2d4f291a4a164c0381d70d1213f7e40fc4ba42c43ea8e70043e27c5ab0827559b7cf7f2587d0d2f93c6382cf54e92764d815280d68c554e5b6fbb351bd18635786299dde39fcaf3efa708a3f18701eda1579bfb0bee4fa1f1ed6e09d450d427e4b91f4552f87f31f06f109e74af4bf301481452aafa2146f6375da467ea008bafc3c8408aadd61b07c28c55249ec0c8bfdb00ea000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 92","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000029039d6cdbdc149ef08d3931d78c780142b6d0c153cfa7cdec7b035faea8dbfdd876e45498fd64648dd85387234a179cfb3caa4fadfd641ef4f327849f42ffb271e812a31bf2f74a0d1e031c4bfb7ed572a7286bc55a2b16a3223ad642810956191ae4b795e7c973969e2afbe692be65554fe5d36b778c7415b9d1a69f385a22a92aad7a8fd4a54db30632af075c1c031e68fede0b86a6b10cdfc7a5c5c25069465acbe6cfe297782328c89639fa4b88a0d74d1a06f837e94604df6fd7eb45c22ea93ab96c2b0cc4ba13369d2379ab1e62fa6d77f1553907227da39e3acf630eb9c714edd269cb9bd9b826d10f7ea132237740966f230b44fdcc6ad7e8629cf2bef6659a5158c4faea3ca74b076783aab234877a9e165b29d0256d72833e956cb8fda33b136e941a662905b2ced926f5bf8a13e74e66528809a0ed677bd42cebad3f9d3668eb678030090c212ecfb4bcc7f6d7daa347b7ed3348110894b989f1e32cb83ecca74ea25975c4b900d310c4cb45b36b0de2d125525d1adc4938d0e5771b4eecdc42d3f96fc686495ad6e21ad1c8b87e4c5629013df4d96231c97d895e7869e7ebd6b926c09ac4ba865d2a1113d33463f37feae3d90379108fdb14d63a727bc2afe7547facdb1fdaf891f809909fc5e69e8eba7e7e59e41d6c29d7ab8f9778be71ea0afdb1cfc9afb08ade29ac44ab1042056999e0bd6dcc48d5b566eb5068e357a2c79e78d0c530ea0e926fc8444a0107d3b26d3fd38ef751d0059b9e8d34e6beb5fa49a5b0362984a8c1d5da35622daf4c565543faa3e9a8f1a9bf597826c93fbfcb8735aae90d607e9a7acc5b0eaea372e80c9f0f0efc4474e819109ec422f41c3aab07b4e124d6074192f9b4753ba93a61872d71ab358308e2f32811583d1676ce7daa78aca231294b1d740000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381096df5b9021e118f52be5677b7ce9f06ccd112102faa88f4332a1029b32a892e6856200f9f05e45265ef3d76ba43e5c944d97e4637f3e8628517cabfc65ec94c34b56e443091011bc156d8a4df85572ac137941978b7e2755598e6450be95e5077a1ce8fb21ba087cda3494826c353d3007481be24ee43647e9cb8a9728a87b3a9bf08d3d991ab0cabf3838e2e7a989069012a39198059b8c55fa140edeb9a8e0b64b55e4eebc16d262f7e22243f5727abe22fa2a863706348ceebffdd0d9b426d519796a27ecadff2eaa3f7bb95c8b4255ee73484b54b02deba4886dba0eb45277438a085ed501a723c954169afd656e692b38f2f35bff9056066d16e4f21aa3589151001ec8239b817969e26ef8999c10045a0e886f9201b0ba422b6664c12966d229a298df28fdd27c0211e8a2c419da3d1910a51bed9d4dec5d796e1238526626d1add9c3ad35a0032e4ab490bd4db3976f58a6d568c5a1cb4b038e22b95de0d720dafaa831472249b0a043b8ecab63119aa3b01660973a65842b8b436e118a6927e7380a520543e41c951d203fda81e3109d04248b381d9fb78edc37689b426f5ad788c3eeb69b5107b58a545fbfb91d508640e4a7a974775d09e464b81cf20a17f5a3b82ed55a23590e8459049749580ff6f973028e3f2e84fd56b24e8046a422b738e88698ecb212ba805d83b69e5145070b17700a8953d4319580716484e47e1848814721d68205dedc3891c3307890425b0328543f39f568f1afb05fb6cb7167d553b6ed027b3d66ec6329d54023147315a05b669a44d76a91fd493fa68b53f561631b488e55398311c368d0b5d5e118c11e65427641487524f91e5d6776c929f54769bc773aaa09591934c80f1267a7d0e0c75429083a75befa7c8de83dc0d026e820620696107543efa1363239d89a5b794245a266f889e51c868f7608d1a29594c8030e69d32ce1fec2e0eb60450554eb7582b90c8c982b6ce73806366b7547627c5b9dbae231922f57d9a1044181b59dc29ea2b6c75e66cc59451d8ccd7774d640d927591afc8497afc0c22c307f22f1ecf75445003ad52f198425f9ca7ce007439926e892246c54f9b0275aca9a9fa283d57f8c5513306050df272c76599259359a798a215d622263119d92d7b461ea2185d216335128d50ac98fc6b11b4a219ea007e9d53849568157bb66e66a145fe0c862c2708d27a46260b102fe9cb7be8f826d4868f6ac050951d905495551d9768873061fae796d36586000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c1e02c7c4451da90503c43fded1ccb3dee468a6a8d9e56670cd8f6a58e7941f1bc5efa6e2afdc0141a2f7e8f781d79e70b4813263a9dbc8d8a67f89371cfbd90977ec96461b28bee4c644f2c91e96257b1909b84ecb25cf438a3fd6b835e20d5cda56a1fb7995fcaa0ee1b5327fb1288e3c57cbef0554ca5ad6fcd1f1865c6aec6cbdb24495700ab5aaf078d8516ca4fa3a231a97c77bd150b127cdbfb42c03702c9027b2a5f6594b022ef55b63bf3eec27eb0e9529eccdc82bc6ad1f011f167d602ef1f175da5db4028bf08a053af2c728ade93b37edc2a75b7b6c6cf38cd1c07f359c73b131b13df76139dee6795f1d85b47f29ae97d0e40cf5dbb67360044f78940a1e80d9d99fd5ab0185210d8769911bc471650df0fcb9c3af038f7882f677790e146e612fcdd6fb89f90b7e5e46cd648f4bf8f736d69f8a91e4806346b4366fd48d1481c0b47add82003310b0a99b779d63ede1771f50221651b2d8af40f48b92ee1327c85a1d2ef2d86378076beb58556fcaec6029649a0ea5fde517a85d87704210e071fcb6f63317aeac3eb3e9746018e1028c50c790a45b1beda6eea2d646dce401ad5d7850a5f69cd85301920de77ab0d01b1361efa3e70ac05881bc02190720acc75a691d6064f9d24c79dc72476309e58cddf5fb2a253d857a79c8e898ab6adc300eaaf208820cb02f5f2cd317f4052d40de28e52c55a0349dd855d64e8da8296d4f572281e221a3d27ef76fee67fbe5484e6460c99950763b801fce828e93d2a633a1ca5d7ec582d7c463da5a9aa8056bb2173306f3820bd0a3273742789b61af89ccc42b81cc68745800d2a59231d5d28e832f443a871de5b6b10b58a8aa7cc9816014d7f3545ddf1f481b7f0c9dd41b4d96e5db767b74776c2253fa230df65f3e0b944b95ecd4138e2847418b084d9f9e0798cb5247238ec12b88c10a5c0c645e1d09d09059c72e33c28a472fdd8b88eaa93c63be7d980a12195c2ec3105df2bb81cc9c3009f7771b6b813cd12303e3a9961d6731af55ecfe5127bac68d06f835dd5f2d584fc0e648c3a4256e2a3d4b81966010964657f33d1fe0400724c488d5aacf9f2c0b802cd812c8452e5b8e2b17ff4a1289d33fc405f5db4ecab4a73fca3634756dfbf9012c413b6f64788fd0f68f8ab7620477acd3c14009377f3dd54b9eaf2784433d63341323f54d113fd63d7456afef885f13c13172a37a5dc82336b9515f8f7f4903ef6dbe9cb34930743b6ed11265cf94aaf406dea9802d17bcb369ad0d9964792f74d338dafe47ee88b3b74eba8e70774edc1f16fa876fd62b0bff880ce252ee4435b1debf36f0a06a4fb406f01d618c135e6103e2a39f4c9cf41ec93702ba76ba753ab49b5836c20f67d05943edddf47ab8c5b81f4bc22d773305076f7e5b697a7b25b016190072f756f19f397884e0521595326ca591672684a3be17c9f5cc8e8f4848f7136762178fbdcc7bc6a6c6a31345fee687b0505f72bf1ab7eb87bfe5f896cfd42dd67a239c70648b39bc0c84da33ca17838fb4213c38b68f22914fec3dc50194e883720719e9b5f8d037debb726dbd899abd97853c54b0bc347a322bfaf961c6cd6209c98aa81b8e2595fc151b1375bf4fca2dff49df40a3d1c694edff6e9687e73ef62dd42ad7a05195a7f206f097196aa0e4d68f8132d4a00ceded940c4f6ae02e6d3763073462c7a4bb11778290e744471ec554a05917e52c5263ff02c07bee055234eee10b79175dc164ab2051b03598df1d4311e87acf4aec45c55b1a58b0f05ebdabe248a27c0187643cb8f9529d31fe0ac4a28d780196da00dacff5f2dd64fb04e7c159dbbcdd3343bcb7ae188de15d923d2ac0af232c5389dc9c949fce554f7a0425d4f9b28df2ee4b81740c2b5a5b93f0f7ab75ebd360cbc78b11c28608b5bafc970cf3d4455a20a198392d876edcf89e2639b50cd84ae21bd50fb077050ebffb210be711d8ea807ca66493650e909911fd3cad99ab94b2ab2edff192d9d75257818272e147a9c54e06c53210fc091bf4175f2f44423669716fd9a6c4f96a0c4be17839769a806453e55d7357fbfb3d7a458e70957d524c0e896398e135bfa68a0cc136fb93ee7d30ad463e32e152fc32cb8e7f0b05a30eb13c0df98bc187ec0a54856d2efcda10a82b89dc8cd21c67d9b6df3d7005ef3b2bc9dcd5d55b64db40b74fd322cdf9d9911a00b5a02e1ad5ca9bf65d90db709fc1e5fc84be97574b09c83b49963a51228a667bbd84bfd8e0d90ec161fe5ca73bcb8d95fd7afd982ab7ebab51bd2b24cd6d356eb850d2c65593313d8ebb97e7dfa450ae982918582f86a356f538eb05afd460566d79f040d36c93d3c645b636560007d51b121de3fafb3ed70b475aff9617da4b52937c628678b109c3b76bc15bd02b766a394893d8ec966dfd8033d12a8d98ac5be201134325e32cb6786f4faecd7dcd05aef5f3739122b817824a672e71deb312cb7dd6a77116b30715076384297b1962efdfee6d6d2b2ed2ea4dd802f4784872d825db828557d4d927b7232682ad91cec3e508854f529853a8797b7bf7bff8e3c180980ddf4081e96a12a495acde0c73282ac78617c68a55a94573e5a37b859858d1e19adc82821b316b9d346ecfc6dbffb3779f692a62d20d1bc4e730fde2aee826e76638ade3dfaa11057b0bc8a80e8905b15e41d9a4105109f18e7e1362149ae9c568d1d642d65b94253be2b13e7230f8bcf34dc87241d1de72a65bba111c111cbf5bd618cd02e0a06e37f60b3736631073a6be004c1ad5f0091a82c87b276f7c5aaf6938c886a6039df23482e2064f6af05636b4c6ba6b24a29aaf2174af4bd959177203ae9b160f81ca6764948afcdacf6bec0b987c6dbe178dcf47c137c64809483019c5f2072d0301c19c500c60b5ca913c24a8f28f50e1578d806ff9f9b810ca14bf5f2268fa18dec67d973eb1d975aaf871abc980d06222493d900cebd8811fa20d5db8f8036430f8bd7f9554f7cb47f9ebf389f66c3ccf9f42db57affee074ffee4eb3e11612fd8a8fe02cc4e9d2f8bb36c505cece9dc87512aeb5d8ebe33328c5217ccaf2e1af1e38bfa84c0035decd8d8c250fb4d964e8f0ae448aab740d9ee9d794390686fe9a95183f0d5166d479c51014f1f29d8fec616e1a4e7a9c86e2af790bc7bd7bb6f746a2266332e04affbe6b9512e6620681c3317dc846e4fd7974e8ae87e370ecf9dfed574e339cd7e8a663ecd1a7bf5842391913d98686f7f2145bbc420f2f58b89131d5f3be41c85752e13504bcc549a8f690cd2b0e1e29e4dfa3cc76bd398bbf28f33a00c3915dd719f7cb985e9a0a7cc8190bffc8bf47310c71418d7a6c629c491eb8e455148bd4438ba6b7014608b0ce6a1bc5b035bc174c9bffd966d8305fe9e5619bca3fe4b39e6732dc652531819ac828f86ea11360678e786eaa741382d713ae26a608d582a3e4583d45744acedd32670b5ad4a1310301b28a174dc9858a55f0c1b7486cd66cb0635083b0c63016e40dfc533ab80c9cfaf1378d00769dcbad56b09da3a4e6cdbfd8f3fcb951680020dca58647665462e42f42dc14e7b20f262d3ceb0b1a2ba807b98d66232ad7d3839c298564bc36a134cc2447b1b9fe69271960459c0a6f897c1878140690da7d41fd8aaa05a679fdc3037eb2885ad3c82374f4bb991745351292dfd8e54f565e0093776b7ea65ddcd500beb4d15af6029f2630a0062f2d4fb331b47b6a5e139d385016e1fa490eaa209636b1383b7d7dc1148f07ed2cc2c03fa7fee09305f34c57b3ce899c18462b4f1ef88c1ac5259440aab48c5849652aad9d3cf3d31f36c7f64f918868182d36345ba5bb7a4ee088d8b081eb78fe977f5a5295177aa427215bb26d1de33ad4b2d610a47f8c672eeda703a04d0fae4c5961f13ad6fca81863d8a394135565d8b27904a511fd0621a532f84a47ccf4fcc2114d4c369b7a76822959f8caa25a6495081ca9ec3ac3348a981618592c090b6439cda2fbc932c8697b3709323e3388af8efa1b9cdbd65a65c8f0c302330ddbd10e0235f8030562452ede447ee5a5a9a636af6f615b1210aa7cbe69572b3467b643bc5f5ec3f9ad15b3ad918993355e209acbd0f1393076da3b0950803295b6571e476acaa04d48a4627367cb7faa83796c4178ca9071dccb8d3ea70381b61f0c56d515e0a765e266dacb13056317ad8737a1ad541aaccea1641946e331229f19bb54c20bd51e63d63bffa13110a552fd0a95ab984ef53bd639efa0568c6875b2798e3a0578c940c0c4197d3587bcb1cc45a99f5d37b1612dc1a4178a3e288fbd79ddacd049159d6a5416f9ef3f38c74449bfb2e6a894566c5c17b4555e154f29a932414636900000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 93","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028b39c001faaf11986fec8e02863bd822eb154bd4cafb7d6bf8650e55ea739e3e84c3ceab48ecd409327b8ccdba787c32089410e5990fb646e5d9af651e0f3ccacb064380ebe1be77ce270f5336e7e89fb913d53a604b01df4e3546196ed1c238a535a118b4677d556f767ca446394296b211a8d0a9237a567e330245c50b77946ef752626de96c7c7dc6752283fabb8846f700a57b90394c8ddd9a2adffeaa17e79163ee7f1c8099bd3f35610f9bd57fd498a31bdb66bc0f1b67739af2248c22dd0fb2d67d7148e91c6aab2fac5b3da6cc4d3c650a6c87ca7afd4e5a2da238d24a7b3a707f3455062358606297f5f9e9aac50f8675d75f51c515c23a5aafae39c8e520680257eabd6be244166cdd5d99a77fddcb3579442a12da2531dcc7571712649393e86c6b54c3d5adf4a8dfbea7a536c3f851633915e4922303fb9dd7bb6f061ea72f7dee8e7b4e95952b95418b74c5075dac4354b7a6cb85974226e6e60698c0ef7d883a8fbebb626c5a764b5528c848684891a4857f62294358e6114b9c6ad7dfcebb5f365beff09db0fabcf164d976f0c44f53dbe7f10c6c2a212233106221a8e649a0b4a62300fc988c02a48cbd1e646acd7bc0fdb091c954959accbf490109919a5579ab5091b612f3c125045b9681954ededa32d8e16748c92a4ef9101ef39dd6c1635a2c460d033fad52da60d955608cd0d8a98673e924d9c5295c647aeba32ac570eed6b51bac3a5a4ddeee03b53e4798e412e4842ad39df5da433d8d732fee01a57de9c90da6372a4a7a59ace518553e37694db53ec56b5b5dfb1f9c23f3e6757037b718721d7b79ff14688f0216afe9aaf22093f67039baf211667ab6d97cc69abb81322af4f9a34df047994d579a7943e74320541b87d3b16f6535d683d9e3de6454f4b900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810965fd19040ce0158ecca79117d1bd47441fd23991007f2de0fa108d94524e9471ff1bcb9d8a4740c55101a1ae2eba4f09e39fc6da6521d75e24a40b78180aed214a816b65466b854934abfa4de103e045f49c14b9a234ed569647dbba742a18350d2d8dd6fb387a077116e528b96e0b8061a6647bdb8106bde40519aa51f664fe1a92249c043fcad4aaebd1dcb9f553c9e153fb3b38c4436b118c1858e9c120ae32153048619e01a9b6ba94c28ac67244c527b971ee384da8f9736fcc911bb842a96c92ff754c0e76f10a6b9520d9a89509a9708ca39ac39d9eafd4f53a6de053390c56fbda9ec94458f940b368ae0e5854203a15e12d482a065e97f82beacf3adce7177ea97d85f8ef26a23c8161066eb76d45464b101862471977409422a9718ca8e47c546a48eaba34da9afc2aaa1487b88b0b8269fac90454c1b6319d07b445557699cc98854c6488a8930be75c885e02eac1334ae2a4b1d5b4a7260e506213793f6942885af246c24341811141e063a30566782f394d26fc2258e03019545b6359bc965d26e7aeb1f4c0ff63318291be1953602d4c6e3998dac1121e26fc49cf57870bc562e16b666f6755ca18cad51454a252771a2b929956f288ed16caba1d1a42b59ef18bd224f72f135e0430e39bd3079caadce8c59ec9fc9b29b6c09ec1e98bfca72b334506890ccf101d25d99b0e24f87a534f3116c7e9f3a6f54c293c46fde4376679b35ac8a17001d456a862278095d01ab134581821b64252a64d2d32a165b17a5b8c3c8d84160b1ead6368ab31756d50a0343a7848512601ca2b55d3234eb58ae4889526da8c342ba93cda489292a3f1b7156d30c0ba624126342c2aa7c09e024b9b11eef2ab5b0c67d518b731d6d21a125b060e528e71fe755300911e0be8976a19a72a2494e047ed90b95169bef8540b308330644bfaebc877b8ba4ac9d2ff7e244100e6593425b42653a2cbcea5bcb872c79ba20021a7b9fe5ca49f04086911686d2615010ac80d66148efe629b63d6864ad5159f9e5123f191ead89dd76c559f45ef646f6dc18692da14a76abef3f84b620bb47a8a430d579a73d4c891b15bae5d027f5317411406f90d9000ddcb42f9d52a321bc55826a6ba1b936b6a2ea78876131b0b9ed266b71d9ba7f23359be2aa87629ec7873674dbd6ed80542247b06dc3be69a6cea6922a6539f88eb10c22aaa6e4dc62e00cc2aff2ef5483df4315d57a2393561261567041478ff727e18a651e1c4d3910920000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c3fe13692e3cc06ebe8ff9a292d890f0a34dfe9a4f968f196b475ac4df553a30e2fd5df008df4d7508302aaf6389b6a5a9135e9bc8a5accd2bd2df98ff662b763101d31e24e8f182fa50840be27f76ba5ed645bb4d3f7f2f6ce25179a47fd7b6441a9b3a28783ceedb425b2912734a75d7d03811172188253bd8f0f52eaee84a9fb025f95ea1b566c53297a6a090f7fd8b21639523e073adaa750d63da61631f933fedffb2819e0eb3074e9e11e10b102ac88e2c8d6cf408fd241ad301f9b8e18a88b74cb4b0dac76347635dfbb3eecfdf84229babcc003c6e4efb7394e25667dd7fa47d36e027559f53e98789e6e732e6aa23a71607677fb975c2852367c5ba5e3d10b3017ad26f9a38ce803929d08a43646ffbc3980b359d8bc2e9615636d4e5de8de6fb2465a983eb1696e98dd33faeb7af8c2d30506b22390d7f9fc21c7a016fdf22d21ed2ea4175fe9f5f44598ec26452700dc9a495675431e1236865f2f4aa5bc9c9a10eee9e29b1fc4fefcf8f24bf94342fc7e19aa6534c3b771d910aa419ea2bf70e2c1915891cc630a3397551e4f34bd2192b70eb210ea67cf152a35a3f5d0878e153579b42afafe5068b2be2b48127ffb54553b7a9b6f845e7d72c43938ae42bc03e33b836ab212909510aae7dbe8ee6d0eb8ad84d60832f3151273a1e09c514c3aa4cacd15564643f4255f36059022b91ba4137ecd97b34be3308d40ef06bcf4f45ec625b54c7347f52a21815508199c8b7a6212779cd171894da9fc3de2a6ef5d76bfe03b8199ed1dc92b2a403e4da009cbc0fb597c5952be32579eb8e781eb12d935848c051029c528cbb68cbc1de0102b42561e21f48e72e028c2cd8816a9027914571b49d2f94c9189e1a7f18d7d3d0a09b3a36edb8a084ace5fccc77e3e42eda0fbab8c81eaf170103ca757981839c9448362bcaaaa3f20c8dc653aef36953559f3597e1915f02a8d33d0e46201fc794ee055e6d9955b91fc7aba1f136c280367404725cb355fc2f129413581401f98236d2a6f8bed7fdd7ea99060dabe3f0e8ce20b0e98ea80994d1673e8ccc6a0ba4a9d544f3d31bd95c9d3847527a978c1f155efd84b6a7becfb749628ce82e80285fc7272ea05f953404e437ad557f38fd9bbf77a69b81e4441605b23f2aaedb00c7519d8e9cb4cae5f8c3fa74faabf6c12595ba045f647aba7168c65c8a6006733d1341435495c7088c3361b50c43787ec24c24f57323466b5c088e8097b44666453010da38ad65b426e72140af78a5448b2f93df3820f013fb9dcac49604c86f2b2e4ea565463917285f148e8bfa9e11943ad3b86b14ed59a190cae097db26daf8fd2a642676a37dd90c23b52c82ce028b80a805d9ba05457f7b6cbaecba4094822e16c14d6e2291b731d581b12fb16802653360aaa6a7989d61c80debfcce81a36d9ecc84039c4f086a5579d36ff5d0cbe61292e4fc3d14277af380a9c1dbf36c2d61f59cfc0d62524e042710bff5ba719e56ba367ffe849d660b9f7f3b638e113bf2e1a4db1b8f65a0fd680bb2a168a4fd5b4e0edf3208ad47f1ff4afbaa726e38763cb5c84c03da3d1e32cba873b9a0c750922cd3d0a10a4877eafef602f5c875fbf0ee2f4f0af7f308ef934f7e8e74fda62a860bb594fd061d1b2bb32ba613339042fd90e749acef450d204072acf58b18c365e4f4b815f1e837453c4255d53bb68d50f3677e7173fcc23d2b592149a9f3dd615868af91f705387547862d34553fd45b8df643f596dfdb7aba47bd5d91445826c86fd4d30365a2f9a3cc0913de19707d072f27a09eab906304008875b5be3526210d6b8bc8663975a1f78eab9cd7f7305cdd4c00d6277622e50606e1cadd639730101d088bc2bab295ad86ba8e26f5ebcb3e9c7c543e533a7b3c20f0f89001775f714825dc8547bab06f5b99c5305ef18372a184569323fe269d45b669b9a222c9defbb0b2c84f42a57ef343a5c12f5712eec33985df8f0c566d471a9403fc103a3eeed42829d8e3e5c517bde29447841ce96c8ac587df3e4b6227fab386140db0112ed0d2846355c4a45e94f3a0718ceec13fd3caaeefdf0b7f89f502aacf8c9d96d01b5549157b7df2be65bc30c889e69971700286c561df91c8cb923001e5f0e21d2c7a3dfe8d1af07fece1eda20c031b29a4389f265d2c7be64ec37b2884849ef30fc8a82d2f766ace68c72f0a4b72f3b50884749814387893db2370a3410f794c64cd24bf0d13e44ad500ba9816f9baed72f7593f758592c2e974d1207a664b869130baa1fa71dbc55875134e7cfa276e36568f79483886099a1070c14c6e4eb87523e04c0154a2250624261211723453cfad185298de06d08cc25fa18bc58b34ecdf5d9dbb02541bab4a2af110ae09130e12439f1cecc34f9ab5d7be36c827a6f2f6708b543d4ad2e424805e2a74895742b0a5da30cabe4ab45f40cbfccbeebdab9b8eb8f78781168b5bc79e04effe1757ab0547b9bd0d2625673ce528d2b4874d46df0e09c24fc413ef9ab4c3d2e803c1e316d77ff5de3368bb925b2b1f6ffc340525663931f5595c8aaaf9fb0dccdfa4793519a66d4fde38bd2044c60fd1de15d60ba878fda570e7aef6db69d2527a1f1481a9d05ff2f6f621238939acf5d2c37b2bc3a194a9e65e7441764a5ee37b1fef3b8c9c425be1b5ff0d05bcb6a3b91876ec04ed89a31749fd443c2b85f8f388e7070d77dee37e2b666628cc9a961236dd24af2769c1f613b4e77f8e82d1f410ed59f63f1df19bc53a448106de4f8efb8cc37e40144b0f658a4135e25a3cf36d8692def2677e4bea3a9770f19e44d55080625421d5badebef3b39be71c08650b5718a9b2fcefc4becb26c4b63c43f6557dd66517d103907f82f9c2b965b7c5e36059d2159183f5acb8b5ff5e6b92e94d53ab25ae955424e80edec4650be293e836da6148392c500ff4b7672932e90e068569b81ae335b2e5013ccc95f571948d58127eb1269a08d6e897d2d9b60f3e49847c05d0b3ac230a67eb6d38ffdbd4b8d82d7b9ec803429c701f080be86faa165c0111131712db4957fd84a8936ab55558c69d33d5890cadd08d7f0d4962cf9e2f69c7517e79db14b76e6e188f5ed95169a2a7e4c0ebc2175ec2dd44abcf239ceb3e22f955ed25da41768ca5fd9a9ae15faaafeb431958a679249ab8bf879185e8fbf9986b96a92972153b4cd0d1be001e5afae3ad1f0b1191f1483738e728d4ad240538e5ef7bc9ba4d5903929d74cb64241306fdbaaae17b1c3134aed2cc394d3ef9653cc62a29c4b0b9be04e95e072ec98f7a80a7b575ded4a1993aa884c1edffe056ec475d934b4eb0ebf418975728c6e9cb3919b2b67d2c71228a4df1fe2c8388e3a2bdd75549417fe795f1947f857b1c0c9ca021515fd4d79e691493b988080943c394bf29e4190082a94f224afde5853323ea51c06b41547eec0da5cc202a048d77c7b91e794c51e72b02ea7c14578c11d9df48e099465783e496029ebb6d42d9caa52902a4694355db01dd7f5d7c113ae06e3f712fa577e937cd4fb817659f93964e194fe7d509a81c258c69c3415a8f11d35b414339fd1cc1d4f50665d9111592d1c3a3d69fcf6a971c285a94f5ffbfe8d2fd2746dceb3b218d970d670d10135126e479d92000d41eabdeea4c04d1748a4908dd39c60a52aa5fe29c8aced50dc1295b5c2c4a98e3c62ee4f370f4d3e500fe27b66f65bae604fd558d66b7f09ce36c36c8b5b4fed193ef56d1d8df0fe6fe0031466a1c633203966fe83d6bff843657dc0af176aa8d5cb7312cb4e072bcff24d5f3828e29b2037e8d1fb63537c70c27011e9a97e3f04895f4e84ac69c55d450b46d5792a5d790557be64f765fa243afa98527b976783e7acdf76a7e1dcbda72431fc30d7b05197478d8d74077626ff7409f95b24a1f1bb6b803b9f1b9ad5b06883fae6c4b587c309a63f3b2fc9619032157b98c1da9608107e87f4fee0dae995ab86ac9869446cde92441f0b9f8240e6f7f7aa9189d92b7faa3280fa749ba8c7729f8974049c5cbcb8c6650cf1c16b8194c7ae1a82b40b8b04488fcc69e674362fe4821d4c1846cd9bc49234bcc464013f5f9a082fb83d63098c331d4b1c9129f52259ccaf4a9237f8ec5bccf06f230c08ddaf1d0c21c5930f55d3d5f60cbfc447e7fcbc75cd199733f8d17bd043b67b0c138cb0c9c8f2e477728f27dee573796f71b013689b537aead4991e67f2f5eb94bfad9509d7c235c9e55f68f26b9ce8aa90834d170f8b700a40ae9a817d5d17b1644d25bcf1172a5cf0c755a6ec04fafc39db06aaa05f5988e187b9e110eedea9c84b99ad29a4b31950f2c870a1f91daa6a5817faeae516fa42660fcf56000f7365d8c6cc11d4784c6fc02e4d0c727806e9d43b957bba124c980c31f81facc6d46f6c38d227eef8f000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 94","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39fe541a112f6b646c7b9d87f696377919a4819129ba47c7a9a7001764923e30568927555e13ca43113e8545141f2670ed07ef19a9dcba48436f1628f242edb03d99f94e95cb540d6f024597ffd6601f58c37846d8c4cca1fd8cda753895a6e83c40f6a20dbcfb81f6fab29895a50da2cd1c79e20d5d4faeb5b9aa933619c6feb7e89dccd2276f4c468976f91ac2c7891fd61cbde50556d4c73af6685af19fcc5fb178b4fc9ab5e4eae39f91983a7c4f268cb279622717d63f2f6d3bcb8affdda1783c1bf10c4417590411886e7183d50c238cf62d9f5220f12667fc8d3e1736ab248ae66ba6972c600c657353f52989ff09885d7572a3b1b8f0f39a2ad4610792441e997363878b7abe955473f9175291e883abded3f6f5d91f6509c110d7c15d39588e549f079a609787b22de08e2acc16206126bda6c1e4beb535c446ddafa74dfa2d0b2d05352d63004e67e62fc6666030550230c5f2a184752acc991e8c6245f49424322547a4a6255dc90268bc3e04be93189d42cdc477a123f522dfd85d9f7fbf4b72179aca570c39239d3991309869856b71ffcfbc69cc0655364151d45922536088af1b945fd99468cd1a461167dd24649f0641e632796a13b61e77dbdf96f036104419b88396aa541ce84eafe832589171a0b4099ce18ad1c14e2b38b45122a26706aac4589fa62fde88d8225ae7c9d68850445f4b3711f6c31cec72189b5d2669ac63399caa6a41e194e21c08ecaaa8e047195655f6b3bd770a54b3e30648d09828dd434f959edab0eb2f11cd83650426d9b77a9af32ee9cc7cfe672acfa2ebb5fcd1ac0428d743aab267b23d9c5da5544dfaf977e0eabdcfe66f5adc3c1c4880a7f9e18459e5f169eeb5b4d19b9cb26c94082a3dd9fb45f6d44df15840eb4671cb434d263fbe847d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810983552540e488840bb2d239ba2bed9030c510c2a48ca381e4568d441790f4e625892ef02714020aea5528344de0608c52260c75de3156e33f1fc8cca0c1c774adce995a9beeaa7ca2ac853487c105e4c86b71486a9faad57406a1d2133e9132cc5cfdb17d35041514361971d326144b2f8acc5680d7c6259ce8ba67addae26e626922268f089481dc082491211be91bb701eb47af32682862d5084450a3209d43135e0ee51970cb38010ebbdbc3e4c262615fd76d98ae8a3ec6921b6f0fa39d42142296384ee14cf5ad0de83fccb79ab6430c1f61bd577c8ab50adc1a861c11ca013e8f418566e45e8d20c5f3c0f1887e4169af5171b78849d96ddee73cf9072425a8e25ad4b80305001c316d44eab64a87bbb18e6516db7a6752581b01e9bb8ecddd92a8288461cc0ae1ce17cb2672b7e4ad9914989e6502b56a5b0fc6aa7b444c6fbad5ab6a65d76493522e4130943628665be8c1066f78896958d06e9886c2abd34394756450762700aa946f563a8469294dad2d12082002b04754e1c830a4df3f62f423a883e82fd6f8b5a02ef56a4c7cf546aea5b5f97819b860665afebb47841ae669ba4bfa3b19f068fc70c831476806b81aaaba63f4903188e96b532771da01b2a32bdd3a70db1713c8d3b318dec9f79f0381ec5d383b1e589d8c1fe72480427490bd7827d7298a3e8e282050e2a3786ec26b993e72e09c8b7e0a265110a97154c38a0b98aad50c059f8bfd73637a06f86bc4ffdbf600ce5208094ae41d05229c96e3d560f95e98f464194e319fc96e59e3dd4b70e09f3bb59a007222e7959bc3764bb9017849dc4eb4bce34b46c8aba8eeb3934fc8d224e89df71c4384b7c281d5610985b63d1698b22791bc96ed00216d2b2b40ffcb2c16f0b919ea8082a0130a014b8b1702d1b248806432c4f80149629032c6c8668900e616e76560fa2ca955a60b19a404c1658cac2a652db9bf102430fa2824ed96dd147c3d9a9146652dd1e3b45117b3769189636e990d415d04fba60ffc224c12b9c4916b6faa0a62bde48e91e8609a31c3713fbaefdbdcd91fa9f65b45700bee9f14b2b3d1970c8dd42d40e44d7189d17a3be0c884676d4df7955f576662b68b768cdf2588c489e41cd3ab30c3eba990f8036ace875fccbf39aacb62b6900e6934b157ddeb25106d249b470b0e1386b1d1289caeab4a7125645529887a34fb0a11149fa0f0807d2e2c8148a3b10b07d633b4e5507a800f1fea0b211b0b89622638453dcbca000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c601f7ab96e8c14d1a5094672d7034fa8f81703a2cc18983c972cc66736cd98b031ac8a479ced21a1f634938df85f3e83161646db81b9ac3ea22f80980b8e2eba4e9975714e5a98985817f426c41f3968349686b69af917564a2648401b8fa127fc3200dc16a9e663d1d345ea83131e21229dd39e70d7270de7577a7e9635602fd2c30efaf204a9234f0a73d21375658b0b0b04927e67f3f5534614edf5137badfed914a49aa301000092da93b3fa4a0ff592cc3a53f4a75b54fee775efa421eefcd6e0d32fb5cdc096886076da940b26c6e07f12f6e08fa7b3e2dc42055308e5607a2732717ae592a6909c6e084252a5b08685fe8c6c1da387b0aa9800b67cdb3ee2fb21b9be5e6b79ab545563068441c0c9c1e68cef6028a5cedf27d3ca47d95094c9e1e68b8449758be3ff8fde148abc420295dc76e3eba8e11433217fdc3136551a5a41c1c7e7d6ef43601946897fda54842d8f73faa7eb7ed0de544fef2a95c6fecb13c8c0f14b5b22493f54374184b73d5bd47383bbc5dd7bc1beac0cb8e66d2f413a9dceb7e1d0ee2d63b9eb28db232c33a95b792ae67d2591f5af59ddc45771a0e7195c4d25e7f4079359597678b0c0a87df3d66a686a9215dd566d4722c212ad05a23e1377e37e18a6ab3ab8bf5cd47bf1baf06eb05e4c150ca67d7e52bd297a08cfc97b575752e686b83575f425f3a450bb0f596a60e41f7183f463007fd019ee255bdef1d98b7a0a12ec33b3e2bc9bf0cc8f4860debcfbbd5e40b2adc2cd10ec35a341be7a49f8d204fdae86921b7de5ba700a61e2b041a8ea7040acee844892e5cf025ffec5322ff6d765bff1107c967a12eccb0489f64f8c13bd7057df76485446641aa7a560c7e73008c46572628e1a225a8d3f6d68ddc9759a952fc07cd43de4434bd3391089e900275e9ebc92563ac1403bb7dfdd182092130e3e6aeb7b666f4ba66c38bbe1f726f40a07df6c42079a6054399519e26d765ca065f4ddfd27a29cba292699cd826fa9d3e7ee31b0d76813879db5ec5c7f454095dc3bd27323dabd2dff949ac760d6137334507816330fa67d886021661adc69aebd882a07e01b4b6e5492399ecdea99222ee785c810b30409dfaf2a3ce5a05d699c2368249c9588d86feaa778b4860d6dd442088a21d2d9d0b49b15ec579776812af8ad582f1c44bb6432d7472300b5440a382ed87ab64b20373a0abdbce391d0bffc9c543ec686449fca9d04b7141836a416720bdff250a06d7651a1f98eabe4b340b2303591d0847aed6ffe423b6dd8c0c03459c381db506f531343f82c116323899df1e5d8db8997bec12eb70103f0bf2b3d53c4d4694052606ee32be4f5b35450358d7d85062dcf7f0bdb51364700baf92cd6ace4e2c10e6cd9a332716f5f4bf7598466a99238357798a499c9b8be77690635c57e7d87a904b3f2278c0b1b23e5860b0532f152e1626c86fd855f656b5d070bc81ce4634a87c8ea6d6a433c02dd2e6d6561b25968b149a6f3bba40b749f188b84314b5778a000cae91a53d59860ee6f7df38ca0935cd64c08a34bf19981c17951b9c39a847d0637441452e38ce5e1d9b99bed51b86705cebb8d3244c40bb8d70f846936a2be29c21604a7e6bd3e655022b929954f6c9a5743f5fc2127b49956d80128dd582ceaa06fc174813e5f5e6a0a4d7d26756fb28a6588e9410722591cce2a6c6ed0976b98e1fb0c642d5df8f08e96bae1fe10375fa1d7c70806101570fef1ebc8f58664281e2b61df2081b655013aef54616308504f5f4a1e8f156680163489d3fe7bb0a514f1d2d57ee6302853d7d03c767c7bdfb79e2b8c80403f26f6edbdd6a890a0a0b9b76d334e0f729ff9c47bfe960a1c3faf77e81b9ac156367423dbb4d766a1f3b1e67595effd76287f22bc37da4f0204633e804002eb7c1ad0836fa4d01e2fcdeab8457dfc3d8b7f1151bef3574f8f4653aa3780003787b8891901abc8250a974c15f2dddf9e1be6798647eed710d06cc3fb4c276bffa585680fc632d8efd1614745bc3c72b82c53feae935ea5014e2b321f69badf570fad878c9590fd20fb7bf1b31e373da93d1a8c63ea45e698ce060fe70aba0fa84f37e836f2ad2998f07101d3fc7ca2b08b1398e1687ed5a8ce860ef9b4889ff436b74d13281d1f6a7edf1dbe8989bfaeefe6a475e65217643e757006871e664099f5b3846553603cd9eef8fc195807361fbfdeb8dee6a0b79f009c10df397ffb865f4ebd0473d458d553358029c6b5a95d6ffee9b645311d10a8f479b7e5249aa87e3ded08311b4ddf3a458fe61ae294a22643861826acbbc9b0ea8b73157ce15d1ff35098ae67159b07ca7499398c26776dd9884b5d3786c87d48e864d8bbe2b73e2890f217e135bfdfc4dc5e805d9cefef5268e33db611aba6a5d57ec82b7246a63dcf3eaf3a51cf503d65c206d2362421de774158aeaffee45a6b5ad5cc0b1de0e2ea74e97913729a69e9c00a309ddceb7738baf4757ea9cc96e055bbdf692b12d8b01b92ce5ecf3d52187402cb7fd961a2672dc1875b6ea22ad7f5f42b1b52ba2d780f2e6c5b25fc7e30b1b663e3a09c8ff0b5c302e0e7f984ddcc62dda65fd996e17da72f02a16c354bbdad44c5b5044759bd53789b98bc58cc25fcdf10a9cbbf0fd6abd58a4cedd92c5d85ef22b3c5ee5d9440ce42995517d2f7352ce997f51a36b9fa5703b4c6491ad01f406fd1b5bf85321026d28b51354dadedf057b37743499a986469f908a01f3c1b74def5d8e2f57ed25a80720b540333109a0a65e7984b557f65429f3d3bd7ec3732a10d7af36dd5d2414a09949a0f57f37bd9021d2c482e61437cc15e9dfdd92d4c212c4fc6c22c54591e5afd48210fdc88040135e433f50e45874e0d5ee2bbc857f2c80e2fa4fc7acfec8eec0cab351f677c790787c715945c21bf923edc0a58878ae09acf5fb5a003c9c0b6e30a450ce6dad4b626108b88e89f1e6a7bb3843e1ec8aee35af69e81773cff71190f819ccf24142d60ac51b80b61019ec7ed2efb6c5f18b499fc9727bed2e3324f8b94a522092e0a98241e29f8f14c6561df3fea0824f9cb0fe10bb497e427ee62085e7aabb2900fa47bf27c1638bd116c5555c076deefe9754e8ed333d72ce9423e27ef640fd5199c0cafbcf2da1c5c34121a69e7e0deb3c268fe60c6797056383da43e6f472d225116f63124498271d3d43aadcc5871f2349ce040be068d72eb57b7827a7d9aa01405ba0ab07e684b91ef05418948f6713aef1f4948399e0e6130740cae3e481a6366295422be3ee2e892aa9fee86a6e23e2ebcbe654989fd93d1c4e7d62910e1223bd66b7c54f8dd7d373986e5d4141bf0bde98dd13aab7d598d698660f11fa4bfb0ad09d5c27b65386c8673e6c4ae9e8e30f8dd1a5a3fe557a3c29dcf99a7c376200ab595c49445e740e3daec07bc047fd6ea4fc6cfdc23d7449f9d1170fe635ca36d3de5b57f1cfb182de240cd4c1e480600c449d1a8596d8315906a53954201929e7665dd2e27d590d481dd394cf2e8ae19217f1ff0cb511def7460dc9e49c21607247857ba744b1384344b4c2d8ce987512376f66f1a279509281242a7a2a58ed500395418138abdb9c5572a258d157f4d3e88ed216bbe9cee3bd054fe61f94c59a4ad19aa62e456b86cade61622a6fea877575eeaea20c76ae8a89e7b44396bae0eeeab1c23f221a3df2b2cc683256a4e5c8207eda0b235562ad3b510f9d3fbe0b51cd8f238a0abd2ec182681606c8fd111d8ce1ec1cda6db4572303ddeb925ac1fffd75e321468266790dee6bc0e85070cee749d9e46795936324dd1388e1b11aa617500534b8daf2de12b035f73111b770f5f56f5c6a4152c45ce0e112e650faa9f3c7e59e3410745c29fa59cae5cc37fe4c6594990e50df1576b69b2b292afc58a804743f49dd7c98c1768fd19ab4213ae4fb197492af5bf7fbc6c8b507673539d8515dd527fafdd8ca3eff629caa720aa11e65922678447ad4ddf5ff943873df5203afea4130ca5f633e104ab083ec690cf092d208a98006e91bc7e33731d18e592869e564e6d3ff8bbbbb9837ffc1f1b92de0f5dd4a029c51e3f64592cac3de1b4ca5414f894b7b0b7d73d6bf1da4b908aceab47771da56a8b0536301fc5fd270caa55ce171332f7db2eb4619c4b2c1971ebc0ab8b0b11fd54c24285da8428ab9e0150d8897216b133ed554de8cee532024df8b8d9314d7c9a3ec60464f9c7bca8c3d4fba23a7b543ac111aba8c8f1bd54a243d565dc062f84cccedb0a03375fdfbcef8ad8cafc440d3e6f988dc607ecb947673dec4ad48724c91a6be22a0027e42af6d94d26d188d0b7b3a5af012880fc0105dd2f11171742321dd41a0401415c58ad4dc445642a2cbb466788f54d270bd8df25602b298b62b6d0fa3ada97008a99b73a807092f8957f17eead9d53b1128fbef1defcbc607ea92afbd353e95f52d33ab7c1ebe2","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 95","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d397a652746f9b248cdf13b9b20063d43b63c20b9b70f2f25818941e8bee0f44b9699ce7ed29e3f510d5037156dfe04da53faa45557c92c5cedfa9fb16bd35d5ed668de4f519c8920c6ab83bb8151add739cf5745708e378d2a85b5206b2938928a7fc89ae4561d8ecf69dd45d14e313a4071e8423f834fb72c966e03de23b71e16c9d5d5dde05b04f919fc241728617f451eff8bcabcd33449610bd1a2ca657514b27550e707d152def7d18875428998eae4077a9e95bb8d3328e8d5368e8dcb61cf541a65b33e8fc0e16e74617418932c83a3cb16a4be4608c25d78d84017182ee3e6f09054d925348c0f3529349096277fc289a5a10265f80cc96089d53f1a88b09f40a18753170ab8ec1a54cda1a9d8e2a61cdbc3b66506731ce171604b8121362886cfeb23a74561f228cacb0ce03e7c664a115eab73f6b08a7d863b9f8ce97769364885369534d679b4e1cae00eac9b658f8e9e2aa5217177fa52bbcdff5ca19893130d2b64aa74d364cfe7dfc89b1969c2b1a036319b3a4ba453194bd21cf6b35043e372814c5d5dbf15459c699e0f53e7ad80e7d0c4e39b1da0b9824242b5ac626c2be939e6539456ff1151fdf31e23c8da3aaa4affa18ecad8978156aca54454f7adf6dac24133f479b0f4ab2e667cdbeda0b3e7a50f67ac087b30d1a677ffa573ef943124560c6625cfbebdf7bc593b0df55d854c64328d352d87f8daf48aad5566e8693f706e7e6d8a1a04c9b91f1b771d61ae6d74f795c325e5ca385c3b1c5a1edd623f5f7cdeb985e26a1dff046bb789c9d16650392cd6a95ae0ab2e7efec39748552dba304bca56aba76bf9c42a57ed6467ed4c549b32f48a2f4b8d4b26cbfac9f94292b757ca4e9367111bf300e9f9a41ebe53e029945ee2366a12ae66424b0ee17ae0dae636000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381092bec1fb3f54c2ba48103554fddd784ed3542935c555741740b7b5b3f14817d46c6940003947a599ede19587d5ac461545c9fd26e1045c6b375294b93dad72e6aeeff93c88cee0d358cc4b520643d39a9fbe1866c81222081d8e9a58f30761385c27f04008a8af3ce0a1416273621dbb5b284409587e9184e34798374c7f60361ed8474a192a6a92ee23551bb207e0cf06b85107d15858b6a8d2bb09c8a0ba7cdca4e9a1e61cba8119b526aabe8658b417273e68c9a93b3717d206b61cc82ecdbb82019bd27f96e3168247f82b0e06afc2c3d4e2c37283d86c18cb58ad156232211b4543a6c4fbc48ed20cbb9289cab66593be4088b005266dbd8586a5c846ef7f822811b3cdd5303d3ea41f60bfa2a5cd3b13c478ba0d90c9849bad36c4b42a9c1bdb3260bf8627c06054929263bc0a36a602a5e9aa8af79b06a481a5943c43eccd5b8251e91a4d59d02613a1b29d824bea8093378888760d5a3d523e8da7edd35b551ee83ba285dd6fed9e13e4dc9a046964329590dc323c7b6aee5a7ba2e2891415922d66b0cf328f9f8815b4718bacd7a26368d9d598ab4fab2e902320534d40c50c0beaaa7015b57baa11df2891a5a1093c6fbd4b14d08117c67d5d36a57a0745f40c7ded2632eccf749850c94625c6162c5e1656d32a061920d9c9ddf58b36ac71b29b9ea970b68627948f93808d6b9dae8b3c79fda25a865175d1c8fae2c693be41fcc1e5ca346c26193601132c8986c10650d6ca48dac3b1ce50302ad682998780305d0815688caa3644b849d4a5a32703413698a1db0d29fc3a39b15e3b1090b295524aa26d7564f5b9027e7be8f20ad1110f0a5d12e4e720e1b13969f2b8c9f899aa7f943d1cc14f26d0d22d2ab9a3929800bfcdd365543ffadca9947e98edf53397019672fbe1b62747551cd290b8ceb0864c44b3da27f7b7edfd49e001a1bcb0ee982d0035828ccb538525213c5a07b62b1e3265c283495e5478567dd5e0e6a19377824c33592e136a0c0b93e346511982415b971b1faec6b5622f5fec9f86c403d3666db734e519cece928044087ba75c0c27208a460a858344c26a7801881491b80df264972a46a108abdca9598cbc12a0315ee207cedd2058af4a2d811c34e7c67ba66587e7fed3623c09eb658e9500abf1a7a6dc24116606c3d3d6519e8b26e7e0d06eea1692f9659c09bb8814f0b3f2473c3ddc7a7383e8f689300c803f613a23c893a7ec270f26d648123723215cf5ee1650405ba53cc4b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c81de897f02ae7292abafa6a0cad52929113410f2ba972b4184e894c4d31081420751560956f49ce2b772635625afc3ca6698fbfde4d0a05ef243df190ba1ce780eb572590e01e6e283e1963f2b0722b0ceb365552f65bd405f1a284ddbed07ba61c4453d30cc28c83e41590e09d7bb6932d231285205d61332fa9263b8a2d3d7f7fa20f521ca4b49f249896780e08c2dc41669bf0777278f87bb1f72cddf4b998062b1642791f81ad474d6d8f963dcb4458ce11108544c41cdf19145b77038c7e8adcd6501508c53b25be6e787313018620d1ba647cca4a5a8399e11815eaecec6ae66dbc576699bb0ab44de111ab6f252256389efdc0546e641de87fd6a3a724716257a9174f39542539a593864441eb79d499fcdf2f1d053cebb3a1fcc09419d2c553c2265b3dc3943e0341bb49130e9981ec59945fa0b23e9dbdbf352aba0d925c4333f2ee1f2c83c847efa78bb13263b893d7cae029bf08cea2a5d1b5b997e403a489c6d9a124fb8386fe58c2476894e7754b8e5a162102a119482b5e59f8d89c8b1dea70b6c80641c77bfd12d45c5b3ce0021ee500a1665abcf740794e0d3e7e8cb5804a1e0d0c81a107dee80bf63bff8ce2ee2dd602df279de39c579b417a758356d2b48b41e83495dee9adfe4506e03f19dd096e81405264d408b2fbcdbf41db5ced6fbdc2645dbefe5bd038382993970c7686dba3fedc24e1f91ba4b6cf70b2e832b97be24b6393273a519db0b4446e98d77e86ccacfbeccb18939013c66f7a29b10de2e88fcfaef656b858b7dfacc4f21ef5f328c0ef604fedd993510ba40530b79525fe8d336def0e5c303539e664a9360edad7268f70df4de199ab3f70eb2ba65e2752bf5fdb1e853e6f4efcafbb31d8cc23155413be31082da958b01682894a9057cab66d4d64a6f3b1d81c5b75815a3e0caf6486b17339174276a84e11c117b060302dc2ee06a03c0e15395c0dd32661638f059a385578c1b792349a41c511d12ac7185b060a831ee296e6626459c2750faf3afb579f6f6836d566c00c979b5130e8e50431e914834cbb3d26f6e5ba50bcf05d50f699faf10767aa2831c3557a53af14bfd9f23c00f76c2680c7dbf4a9b2a425e34c943228c3ebe55a0960acc757d7878f7943e2e8a1cbc8c0d2139a6a6459d3492a1a7757f71e90a58a78e0ff9b04d059c5d131f6e3c30742fde5506ae7860045a4c903de96dc43ac6a69273bf8edab7e7fafbaad9efa8fa609961502efaccde63a6d98d8d017075487c608ff701a7e3381d7a2acb134b198950ecc6970a75af5625faa4eaf968cce48ffb673f4f365802a984c609c33ba312140a60a6f0924e945d11baacfcd643c874d352a90367ea4c59b63665364832b1a9a9a01eda92c64f393c357158973fa7c6047b8b5e27eedb28e26359402b63032f8b230f5aa968272819ca486a8bafd3d66799ae951cabf04ea81e1e7e4632b915d4e8387c7d1f4fafe1c1fc8666fe0318403ea0027487e947d844a7fa28c0523a64ebd95d2a8abf6a71fefb5bc059b2cbeecd4375f3a3f109dead98539244ddcfee9e42db3abdaf943c445712ebf19508a1ffa6133c5078c1da69a32cbe729a8876c4c73cb232024a87d87fd5f9456d3d4a936cb4ce2e00ef415406d66d344000a4a95cc9651425a16021336c4beff310210324c754bbe13cd0066c507413671c80cf492b4655d898a18a2f4db5a393400c6ad821580b0712d6c919c62e87fe212260eaef6876c409fca1047a67b223e0766144f3f676f051fbe912c4ce4a9f7b85459da031ec47c621f6ef06cd1621421fa52b047b51c944dfa94807083b4ed40d533b19813477193d1e4e96c8d76a5af3100fa44a985a6513060b08a7f3848159b3cc551d43370b223037753b824a099a7c7df59305be09e2e79618c83818bd542f39380126a927190ea5536dfa63b664aa7601c6d82cddf4ce4006e1af2601ec453971828cd09c29d2f3ea6392b58d38bcf40bf6b6497f6b848cb853b187610cd23880cb09787c76087356c66565c0399be746a81753442e4aaa54e84f1d8c2ccb2d00a551e960203d61e71a72e131ed1967dd06e72c99264ef2ee5bd156fc869b5031ba23a6d354d7cec58f339f6bc2dd1c547f07aa733994860197dce5bce6024a74668ed89a2c9cafe1f78b31638c3225d96009c260fbd28c1f0423e75c9c01a0f9e62b7f265fa3817f441f56ae79ba54a0c107fd7946a2ddda60d0eae428715fe2b4ff93bef83cd10e5e17760fe028f1aac8084a43edcc12bfd3265d13fa94d9704809a50881d48f0080a976c5bf31b353b9043c0f0b69ae6f2b8badd056752f2fc9e90c4b35850c2d45b9f354b41ed7826b976528875547a0c389b83725e26c006cc8240e380e3eb554dbf2133a131743539b1d174cca6b135c59f81d499631bda4cf90ded836e8c24c074a0bcd83271309ffef320791c9030fc2b1f53fd2de870e54eba20ce9930c279b48b39cb481737f012f65933650374ba39e2222191b0e3c7db9632ce9cb077322cef97ed832ddd8aaee53c52c03d2aaf8eb5597d8d6467a406bf428e2f16462e0c0d486a1c1c7348cbbf92633ec4ffa75945025a3c92095317e32290d4cbaa6ca40f3f201975f3fc8b733d1467c094e075e8415352e3ae51a6c5169a4aa430bcd66ff39b184f5b7174042dfcc6840eef60ccdcac12d012ae4f24f7184a038d8d9964ab405366740600b98cfe2e4737c8d846fd4e9b22b5047110d85b37bdb9e7e3baf5298bbdc1050aa20f14e34dec283830f5fa9c570c22ca659c1276be8ffbc0ac3551db8488855ae7ec21e239e88a0f68227d17dd87ffa3b3d0535f9e57807755de56a65c0de9f4a79f8746b20908bf9416a86f62ee2c2545bca2d55cd4d45dcdf06dc879e1b6270a80778d0274aa658395d800eaef367df4f4d838eee0a66093e0f419b9edc5f003e31cf0eb7e1cee9accda7a2dfc920a4b5222389dbf12ad17392850c434a9b3c260159b0f52e78e7a66d28dd5b3c77662cfed2cb3dd5bc3cc26a34293ebf1fb3a9bc59bb0c104c5a9387f3893a65d145d424ce741a375f9c65e733a024e78fe274b29ff4b0eb6f21fafc31453eaf7e48fabec5711d3898b876f59952c73123281a8e85148cef5a166bf45df36053d57ae6f29d3e334bb2395fa236d4daa8a4fdf99d80a9bcdbed36154bf4fa3d463d51974032d7b88b2504317e14165b1c3fe3d8fe366fc8284321d80f9cf512f418c63f73b7c29c07870332387bbd1a870ac39485f64086006cfd68c8299347615a423736c01faef2da56cfb6fc966948649324e22d4551b9f50654ee505547f7d0b8481adf6aac3977f49d7e6ae5c4248df7b43bda7f082aacfcdcf1c1bc04f2d45f5e028498ecbca47ec4d1ddeb03a2ab27be9e4b80585145676f8ae7a5017bc5efa317a576ed6e423d5a0495b8dc619712a2c3e6162b04b9bbc7de4be6532f6c1c019e702c014c60189a2612594bcb18317804c630264d07b7396db562777bc305b885e00706ff6d0208737bd229bc7aeeff5fb770a4c057b347601f1f6c16f60d4a53a0b32631ad2d41fa307f6630228e1807d22475d5e331a50a680896dc606f3941ac08f8ba46de5a49f5ed6a94965334fdfd69c4a6c7973d9615b3fe576b15aacb9b98d9e498d2a3a89b4f8eee715ed5f29f13dde7629bb386f7cc800f16f3b5ba8bd0e14cd8d9bb0f0aa615be9d7557f6efd00f7bbef9989e7f463279408e6ad77e100ae4457d57424f2b1caef43052c5b25c896baa1c2fe67d1d6f669311f17d39460f0b176a7727f53257a36faacbf3dfe623d8f882f8ee41ba1ce387e1d1860f4babe26ed678395b9979d84dea5c7b38905d4c7fd867ed7722d066bff3a833d3282bb40d1cd310dc8dac9270a49b65b5181eb30f166caf0832a8dc56b9d135550b506d98d036be7876836aae669507990de6d03e78a38139cf64f65fb410f192e30b045c93fe259c10e0c5b56a2b5f0605da0851104c4beeb4e3b30135cae5a6c68403c63121b0993832834a3b5ebdd345c41b26dd219560b624024b8b945a10d385b3ce4e0bd54e10a64aca59d283302028a9592120d142cceb1cc30e1f96ad041f1e17bcdc3c68c2ea2e0d65d6ba3696166cb365cc461abc4d67d504e8290eb452ecb77f6d5faa5053d01317646242384c5c510bd43c5780bbd01ebc3af33d29d8a09ef39ac85e70398d2a64dffa72b3efd8d6d57aa2f9dac0cc6eeab27b69fdf2403a5fede0bfaf441619be03fde44c49ff0a34e9c37d2b9aeb726d56eb646a67bf349323f397db056d71de72a2597d780942554c8f8273e307dba6bd02e944e0559509e1f28b511bd709d03ea2451ef234df6f077e06aa01e2806d5bdf89df29f1b3d8c6d8014496ad83857f7465f1072e88709d0194733e1fc8c9f092df5b9802fd2ddda8b142217b9532d8604e2f32d06f6400025930da2be9b25529788e6bf4eb7f84c272df455ce2ada291cfdb5fe815129e4aed59625c879e99b3e3c1b6c5d700000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 96","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e39079c54f29e38d69a12a0c91d3279ae0530cc982c40e032e08e6a56434d8908bf777b792070db13a23418f8bfb34e754cf143199f85067fccd5458ff68b2b7c8a20525879a341b4984d0f031d6ab47be0057aa395c9945993698f4a08f635a75bb5f727b4d9d3d1726f935164fcc42216e851967e1e1533593ceaf7adc08131d8c4ff03a1d4707813fd5f498baffb3d4516daf219c10a47f3505efe09e964dedb2988bf27b3b9ccd241fbb7c3cdcb43e6af57f4c4c56689298c392edd425a3a3a24883b08b0de372aacff839d9995bf3a18c2e4dd36188f6e89ae652e7971e8266b165ff797981d70d866b2fc84a5b083d3e6f19dbc0a3c4a692d5b09497fa3d12ed21c439f1405971ecb4d8a1ac2210993c1f64fabcddd2626cb4c7228bc1f1443b52d498a5d6c0eb7d9acddf45f7afd0be4e7a86d2eb8b1fddd14a3173d88f258c47a495d81206c6b13919b4a16ede7737cde39fabcfb31bce8aec81bc2e45cfe1dd4874484421c8c8c5e848ea7b5092678d3b5fc4d6aa0e2c411967a6931a16671f68c7cdac6c6b9c23c628924c3369dc88e0f860f3b4927fadccfcf88a5e918b846522feeac8844e88e4e6c8e85f72d9520990625604613ed1a42a358d48660ead358ebb5338b75c5195bf229d437abe5dd13457e1addb97fdd6cf608161f399098956d245bbc8208d6b2b70a31525c62c0dde06b78edddaf1795f1b36cf7d5ea4618dbf5b9692a84f7aac58902a8f11d2e8d0a41e780977db214619d2fc753708fc4d1b3009ad55e8d64b518d75be86a0287baa767253ea62c8aa588069b91a93bb43d41fa98dafb984db882cbb61ee9d9486099c96bf3c0b76736d16c58ab15f9fdf780ffa43d7adc8d457526f85d3dc9ed483d32f89b39cdde0c1a6be2d8618e2b2034cbf327cac65f2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003810970c17dd329e1ed13269d3b0b1288afe581639e4c4d6481928a7c156222d05cc63f2dbc0b96024766adc665be9feb0cad85832918aaf76d0a4d2ae0ebbb037c2e156b26f72349aefd386a15a0806950adb162db9b1b32e7d85000d67cbaf8a97ae0413d5af748cd0de34562e1f86963e049820521754bce74b89f41d25b57169849095490c81a041fb49ca05e4265db87f7885744320a37c7a0377e552245a1c9bf9501dcf85559f89c7cce5b0ac7b69aae25b040d7cb3ae400c7bf254c665c9b40bb0ec81106b822c495c39b680136dc1fe10f8127329e2e23260834c8e5e7a516f49c92820bb0714cc5b482dc4c9ecd00b192a23e8f04f101326291861c9b049a68ed661cb932570d9091c85273eeeb3a6ec1750abcccaf96e69de0aa2a722a3590a197c3618ef8a7fbba0e8d7aeae2250dc3ed8aee0199d416b8653534c7600b4d7c6c7cd93e48d9289eefa63fdcd009eae2702898c010f2c193e4064e848265a667572f43d83d1181c9550c9d9a823892ef7bb0bba3e94852a6e107593211a585ac4aabcb870189c954ca058716963a8e22d6cd463928fc8b682d378dc90ac2a3c31267d8528b886dba668ac7aaea07ea202965723e5573be16497831255e6d7c3183d4944689f2b74583ede04bc48b32bea47050565a070f0e7a2545b331b95c7e35804894f62c7737b241316fe7e57e963c640a05cb2bc9f2f8f88008bcd9a3a9df46db1a95a460f04b1a4b0508b327de679739ee72f30c218dfedb8a0da2bc8419889750a8f977e44a89026cf37c405237c0975d0f612bf5846d892979b0320da9e8158a181b9f264705bd26101c5b97409210c53e4a49ad70fbdae2d1a32429607b290c7843f91e57eb8da522404b17a9cbee19eea111520464b2ece37a1ce364622584a371ca1f8b0c94b1fc66cb8d49007ad1c03e26e5adc4d0d436342c8d830203ec94e58a23e7c5eab37014371fcd9875eddf530de56ebf90f6717fdd6f05368c3894c175945a16f5e616b6a92911e8bf061a0fd983e3b26cd36c717a524e436b64d0188a462c0824be39c14d606d45440ab310d93422468d09a5565e3b5a3106d562c674b4dc08cace283a1ed107f599365e79a37632a589ae5e16179f40036008b3824daad3504effc9f6e7eb50ca9c79a99fc65da804f11b57004e8025b8e06e163c2c42f599c5f664b46f9764633f8b345e285d5da3424df6aad5c3be6398feb1444eb88024d071a9c9be9cb80baa5aabf42ede6c75f51fce000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ca2525e8b98c55864849ffc71ebc953f7a0eca6298f6aa15a83bf6923bd5921b1c86dbbfc544a39c364ef6d9281481e946c994f96829d6639727a5345560d8641e9a510f913f7fe5592c2a40cb278f5afd8d4504b5387c20945654f08168247a98f56a43a5020955f882d2d93781f4a83676b08f50341e953a5d1b67de7f6d1be3d78d5d060aa85b5ee4271763c437ccd595890dbc8fcfaf2754ae9349ba2fdf89847a15188716c0ec672887a4b9a15176ae0c5138819ca232d012be1dcffd29f677442083087c127cbd80b0d9cc0962bc8318e734910d1e2653bbf700c84bb0919e12df331ccdc7128b41f0666f6419afbadaf673be16c9177d3cf113c6488504de088149bfb83eacbbc400309b7ad753f7b2f5aa89f070c9d14c084c32df91c5f7cb6a7d869d64f4a05af80a98be7517ed784c17b0d7df96b9987b7ea7a398ce018ae6e13e1c0f7aa040ac3ffd273bb9687ad6fefdb211061a6228967e9dfef69bcc1c5d02ee56d49a93c8aad46d08322a2ca246ae8c3edc071d063ad605a97b8ae94d58e897a4a6310bcbf55b0cae1aa81769d30b46f883eaf29d4b5fea32f2dbde49360cb6235754bdc305abb5e5395360097378656e2bace675448889b0149d6086c51e9c3af07a76563164864f131cf9c0cd475cd4a58726ad237cfb76aca68032351fb24711da635871386b4bfc94b0db6d35f07d0196f75cedb92efbe7d653e0ff9326a596f9166ff6cab73125dad27f361d6122ca531d86910187e75f849edb52db26c96fdf05925dcca232480d3f979eab07cca68fc9069965d12bb666a180989ad1fbee3fe65e746c5a8f64dab2e370f0487d001121edd0d0d760531af46da65c75de11688ebf31dd2ac95c188bcfa07ea798609f3ea8e6364a43742a2825144fafc05abd17476480812eb2483734b13d075b3ee3ad510b67cf7057014351b2ce5357e3f12f43ba74ced614be3a9ac0e26763e9ac596f87ae98f72abe0de213a81a9a03e2b82f2312c1a186dfcfc3db346feb132931c793ecf837f57d8e326101f59705b77a3083e712ce347c2c29c23468b0c5857efa410197833987c61ecbc2a855ef78b3d7b1b697ab9844aad07c4b8ef666bd80daba5fcac900c5d358a11676ffc89dff4f36f29f14d9f9b854dced41ffc4b36381449d22801c19bf8e8ba1f07a1b38ffb527a34d009c4064a1e606ff2ab90ab2e05c156150ec14d7dc792578a16f46650d0abb61175d1817e2c38f109ebc01a3abb358673561691185da32eeef566c1ba1c72c1f08cd1b427b552425501b8783116f2eb0cff73c5d2def18d291c106980135821a77428fab20a935ac8b6dd8edd1a936225344eb103de0d5879cca09359b5b882291c0fb1fccf167c30dbecfc324ac315713cd10f35b72f0d4871a7cbaa2b4cc2bc2598f23da607c94a063c9e2013b0eda5f3bd5aadb2c429177a4bfd7b6181ed5f9a55c1f043da8155c9e7bebda7ea07dea49938fe07743df2295c220eb53348310842b1000b7a02ac025c3a94fa82d46ed7e2712de71b149742731ebe62e225d21a7f29d5f3a8a62b71fe16258570da412c07cecf82b2064ab5d98761c69fc5e899a8e174875b3179deaa0bf4a0261da9bf39148440dcbeb0c887e41fdf751505de79aa1f8593f45482b659f5b5f4cc3e7bfee59def49458db195a1a692b8af4aa44ccfb00b753ac761181b8aab39db82385ae776cfc585f7873613b62de55bb10a6b2f27e631ce41436c3fe390163e6f4ebd6b501519c96c06fadcac8f75920fe1435542fdf535ead6c0e3f41345996063b95a208defb6f110cc861580979bf4422ed395ca218cfc3b22c0ba8b31cb9eeeb51c3df35fece92795cafb8440f522b44e21b3a18d5cdbc296b887a4b927f36715e4ac2cab043d8b69a8704d6be24c725b0c2e814bca7b040c27fe8f4c14911051039af13f44e0485eb767f5404cfb6fd19da24d82fe24b53033c83dd8634e2e28aa330a81f14bac1c57dead7ffe39994d9d094383e14322e146a3df27a776e2f09a11ec9014c809f8e543594d6b4814918a129b36fd25015a044e04d3f081d4d201df86a0fcafbbfc695088170b8246776b6a28e59449c646d1e706cea96b12683cd3a7c60459d42989ca46694b0089cf88e9aec5e110f69fe0e3fe20d18309d1ba72a83a34813b771484505b08548fe5d376aaa0c414260ea4bce5eb81f6545cd5203026264938905be1e252574f4b4e71c6e12f99f6efd35effd64183cd0665fe89d6a357b1908e083511dce2cdf792a608044c31418c433f86719e156af3ff98d0f54ebeb9f9fbf24588a5557d310ef9d7cf5dd8a68512d8cb15114773c69d7b40c927858afc049f7c6a89841020e1c313c5c38b988ef505ebe6c15fc1d6ccd8b472f90ed64da895d06ac01bb99f455a195a670d22dbd5e3f03ac84a08831e9842a566e9785a0fd4c460c5cac154d705dce1e7fd1c45baeb23976af881cf5628f3cd92ab19bae8d45a03a859518e4a1e558fac2b48a432e46cf274e6496b63874ca4e4571132568aa43eec3d2a3948f40d327976a6d28cd816cfbeaf8fe126913384061d219f51179f679081503371ea0b6bd7e9524b0ece2573304ecb4a16eb471ca0817c0c6ede751f283aceec5a60c2796c6261ffc6226e4813241619f465dce67b38e1d5a647b079503144907307c7d6eb6e6ec1936b5c94fcc08a882b4555b19b33a9bf22384db38473a313966d157daf8aad41ef67d3a5fe723559096ab1768ff69773eb9d5c88d6f35f00dfa4473df71c7e9e35393638ded05d05c105cbf37711d38e3eee35e8cc0029b3761241fd1e56969e09e949690d4fe25735d774e777a2ca17fe058e14ae6806f611fb1e9fcd516e20499a704b67990716703a4287b50ab45d155d40edc0aaf97f5b87551c236cebe9cadd562b27957ead251f79caac6433f228b50167fb1a753306fff08b53a8a3cecc226857a321700ebe23ab4d6c35415ca79b682d6cfef6b1341e7ce00cb9870f432b63a2d9a9a43c87d28a95c514582812da37738bda6cc76142e08f69ebaa5acd0403100c2343e2fa088441e9a55c720bb509bc3600c27c1d39157e049650d1749751efe55a72349e2a5b714556ce2188ce972287be2152c7e58d3fcad43a214a4095de55cae9f627d8b9018daa01547842fa1ad14d67327cd47eb9b90cd94afdf5244de57e527f17894a410fb4210e06632e88a398400b0aa48cb3feb9a90acc668615d193d5a98158092fbb59ad2d6d4ffee433a2a6a971a228685ae5bbafb3ab28242c630af4656c5071c545618a0a765fce41b19970c2152d44c349d0cdfb29673d1a42ffec139d1c9958b0962f7b57f80cb8fe6331553b0df93da9bfc722b1c001f48ff9c0fef032610a1118ac9ebaf9202dffea605272a50a90768f031c72d570c0aa5b0d4fee4ad568895274388104c0bf88d03fadc3159d6cf28ac6a7e3e5cf6fe5c6658128cbf81456db8c29a76f9c75230f3837f1a94cb83c3aaabdf4b29c9045b45ab9552bbb6c0844bf2926267c0d74d3337249d5c9610e0f6ffd0278f12f39c48650c048d61a3fdb8e1a2e08ccca68803a55b39bd39160b0420cbeac7d8a55f571f490f694a7aa8b725ba84238ee1e711864aa1f74aff252c088e36b79b09c80278dd442eaea8c7d5833cd1baa18bdd866689e663eadd0eaa6e0c78a3e09dffe5f6f1f4003de24336586b25dc5ee45d56f31d8bb2de31b24e87172f3f1b26d400b08d50ff624e456183f269cbf06b3707260383174fda152e4d0c528a90c54114c4f278d0fb35b74dd3ecda14ee89d38e3227a7e18b068f134b22154348867a61719c926ea3320d1be0b9ed78466b2ded728ca04c15ac144185fb2f5084511a38cfd765659351ac1ac3e5f327d9f3de9b2b003758da78dfd08faef3625cedd87c8a55a3cd0257aa71b3788fd2449efd1f48948cb304468e3ca07ea7044fa185a2b91f9761c6532b9273db74c66b2de95ab19e5102cb90c719ec85671e2829b182bb6d09323248d6584f0ca67d422bcda65a0146d8df27ab4ae651706d5fa33b5bb88adc2a1a95105d55cca8439a5060d110760dee8b855d0839053be595278eae66542736d25c93d8544c6e55ed51ad6e7029c2e6d32cfa8844bc14972809e31754af84bb479c504ee77cb65ceddb6bda613feaa2ae6598d1f4975d0fcf9d9dc787eeb5c03f8b0bf438e83c38e2195ef1d35d40f5a14e194bc1bcc64d02ca722e7da28334e91fb6654d708c5b07946cdf58747086eb3ca59d095eb27f1b7e6806d3a35335b2265031a1120f28eed8b4c5d9af268502727c5d23152149c98e6970d4dcc4b9d0fecfa6a79fef82cb233e71fc8aa999df66ebf5a1db2ed1583c65803fa8958f49890d13bc05c6a991f26c31766bdef9bac601a47c8c3c5e395fd8f47e56f04439e9bc8e9b1901a529395f2d57495d70d0712881d298a60e3e013326cd56bf9f1319ea8d6a6511eeff373f081478a51e14f0aa4a33c6c5ea7816380c8984f7a5da45b0c4b6b550644e65a5b2df059ed050936fe6f073b4e8056accd3eb65a0b000000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 97","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028d394e72095eb17bb89b37805a1a3f472fc37e69a0ba427a32f2386f52c9dcaad351be308a739c1c7a9dbd87d8f94936a385c7b24130b8369b7f6bd9400e8fd37b31965d883d53e2af36885b80b1d76feb8a0136a7129c7f85062d0407e6c0eef27b85ff65a1d16632354bee9345e7dafa13e91887c4bc29bcf099207fe20097969b67fdb4eb74b5199814e8d34292bc4a7197868d1fc1ca586891211d540bbc9fbabbd1ed52e396a268d15cfe35101016e126af6a92e5c1c05b111a249a23609b6e239b744d8ef96ffbb0755e21ffd4d210733ce6643b11328abc24b0edec14b215b79d1025f64bb6aacaf5efba920612b139b6d05857e67effe9f458b5aebe63942a7765947fe56455507a9bf9676954afe2523897713f4b611c06b24b0924ccaeca743adfb592ff2b7e7b27b2717d801cbd33990b9abecee5d0c1e6efc9ef9f6c3b99f3a711b5cb4e94ad1484a14cfebcb5e5561c41f2a2326485e8899de892d2d4ba27fb2d60abda75957299b240e5126c7c9630b8d34f122b70ae9b09550653536fb14641b652264c84e25642d0e7a34eb1374ddd8af675a847de1588dada7079b3074e4348a68a5b8c1ffa9ec2c35fc6627cec6e326c2348335ab421cd9cf7d1efc4f57c8967ce5915f5b36adef74de89e34446a904f64f9856a366ddef882034548e4d1e74240b2eee58c95d59540dc3af1948920c90c7d0f70ef579ac9ee662572aa2ab8e464d27d1d6d035a7dac3a3b22788fe46f59e06fdc9398d632d97f5378d0957466d316ac613230f29d31a96233c8c6730bd89deba496fc2a40cb62658a155cbcc89f14075f66318adb79acd2f5f508dd73f497745fdc437783480ce64cca97fce946437e744b562d8cd9cd9d22932295989249cd951207dda684a49b1b270703415b5bcf9656000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381093fb566559429d7b2ee3ca293583b0332090685a0f270752237922a326f8d1995d162b779fd150bb454762f76c80aee6dfe728de44782846f3a0a33e0155a1504066316794de8bee576a69c1d3d6d508a2bb88bdf0c5eb4f5da1c5d1aad04e34ceedd8bad0f306b483a004889a56c4aa1536c57e4e28148986133ba65a7658c82a2b09fe1851c3e7c0a960838120ee9666fa2f810b00f124705680cd8e2413b8edf1ddc9285d31274b616c8344fab11a1ddf18298d2b0b7b20814d25aa66c207a9b0dc6934b696e980e2b8d47f90818b59b9397fc41697365ff6856f555f898434982015474dc435cd44961928b0c2e011d9a5fec1d1774adc5146ce0121852b8536ad64d591876b58b824e1945d27d02c035d4d2cb302ed453e6954810a95e95b86da3ea4338a68018d6c3887ca0243429dd1eb04a153c626dadd26c4eff16f88f8f67dac0a32a476a22aa5494a215d8996db8a7325f087c9ebd614a5c4a602c6684921f0267446d26fd0f6a2919b075ab8ef184add4d63e69a6196d505753ad4794d8fe829112a1061565536a8e812594d095fc677d71d0b478c807ce77fe37c3621b1fa5c64ba45b829bb7b2545b75d8576a8981638693a6a9729be6c05a57669d22e871d54e53b6f694da6e0219cd8ca8e30a2a84600702e41a6289a414a327a4874d71dd068809f94b8181b72eaeb681a9c235cd9a9a1aa58d875fcf0273b97dd18ba54e6045ecb2c70df88b3a0cba1942dc0be2993a040fe968ea7c17db058c558dbbb4a2eff03c496746dd608cb446fed6dae00b811da881c261695fe95f80d352f7190114a0aa439b2dacc36792a8d8a0acf82bce5d784d507b13c148e646e8d5762ba02b1342bb0abda08a50b1a787ab281997414e4a79213019cd428857217b56665b8408e4fca791bbc6b308cbbd18c6fae797af2f814b01f7c040696e4fdbeb033137bafdfbad90e61b3e8cb84164e1a2de34b9d1a5403712f1d49dc9ff78dc73968180ce1859bc103be76a6421fbbaa6814550e113da61a7da4de44b60b2006020401b95d3e5d39554bd92de075391ecc0e00cae8574f519974f8818936de1e000c0d68cf0bea5f9da43b50d07147889809bc9125bf2e4678d715f46e45d68bcbc44338d490a9c6430465d8e58bd68aac8ffae968aa01dd69faee579d0e4b65e8ebd84fcaf0b0b6d3143cacac5650ea67279bc4aaf19c2abfe11598ca32764e66333e0111e037ae8eabb0174b5fdb1b630a1a3743a9d8bb02dc4000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000cc300769683fe7bfd74b3acd21af3898b74ca73dd126c8315538937cac4ef0ad4588765a26dcce1c90c559ce691e7eb3e0a497d357e1ab583c761439c0a66d1164518f01b6894067925753cc2866a91552fcd0ef029c2284c620caf364de6c56eb41ee0e4431d9be22b76451d132a3f9ad91a53449be820a7acf56f6adbc7107c7c729ec8a64fff6a24b4cf83ff4e945def336dbfea6067fccbd1cd6b5698adb1ad6df03fd0a553457b8e9feb4a1243feefc2df7f66ae3eca5bf169f7891adaea8d5c59012c7aa00a5a86b0a33d0006f8ad5a01c60abbda6d249d3fac7ebfb85103a3a747a45d0adb7def52ed3a5f1a620ee383a9c0cce1900e413fc74a7a97646111d54783928b15bca783d01efc67f49ce6f781e82d25d3f30561f507e3831cb4ea5b4a08d5489830017270b63d8298beebf48eb56bda5685d5e1e06404eb9a6c3790e9b29c99168b10badf8fdb03f3c568672773eec96428149ca272ea5a8083f8208bdce361e7d40bc4da75029d4a18b0b6ad615dbf849935d4755cffd270a52fa290811cd55bdca38ed89f0066adb9ba7f58366379ffe1caf3a9127e147c3af3dc27279391e0c09537e81e20e7b9fe4fe3da970fe50bfc96555233cc9e61d3c356aaa8eed5a8aea2327d7036ee03e7ee40aa35e9da4544b121514c261ec1cb0b2d75b1d5ce129e47f89825f69ba8254163179fc1331a917ae9c5a18556a10c5f983871b1258cb6fc8ad207f97a220c5598860b6c56f1eff09de6000241e901a89e107feec15833d34d6eb12db6b188faa0b858a5b9e32f84f783b43b6f8a3b2e4b044cff8902e1eb0c527bb4e29c92acc9dc7e0d9ac6b3a021415768b21dd9695983ee89c871c0eade0bce4fb72e682dfb5a2bb7498bf4d2c01240f67d1b62baa4e587069c16e3032114b14a1c4288febaebb4c75c3c05924a358c4bb7df95ecf81d67147fae3f605ede61b7ba164eba1ab36ece97db0ecb32a673e899b24557d8987af3adc57a9da609914c9b2d6d8ac58e5954e0db5aa9e75b444700b8f704e15a6a7bba81809fa8801c6ceb5747a44ceb8f99cfe6d8a2a03c03451e5f3d392725207f3dd28b2c00004425b7ae05fa3769183ab60857b27ab08bcc4321d293c93d1d850d4e7a81b14564d7b15ac0e3bc1bfe0561622c6aa06923eefe163629ede8ba1732dbfcad52d3baa6e11e569ea790b36a8472b2ca37bd5c0edd37d8f164b874952d00d592fb705c6b3110a12b03829c157191d33c579593e7828cda5c24a284ba2f5a42f0bfa601a8f6d3db1ca6d703ecbd261629c9f96ebc0458737b9951219e5b1f86192e2a85b47d80610a0acc8b1a70db2916f89cdb2c7f8943471ddbabd2a3536c5dc8a73cdeddeaaedc86fa148d2ee479f8465558852fcbea0dd8017f1b976281a5014319c2c3caccbf571d9550215b24134f6daef32716802e7945cb3f97afc1ab1da17d0c41b545a750ef345a6f88ad5ff52d512afa6558335b5eb8979d8e6dc1da562bb997e7d152d9fa3eaa09119c3474e11218230d8a56c19ad87fde483fbd6ddde9acba813bebc8505a323c601e5b5251650dae9334562e3dcc38a28bd7ded6942d0cc2014235c1b66cf4a57ba3010b83cc7050309f57a27207512d195d070db3d10ffcbacdb47e4231142bae588f92c5b0a71abd67ca9390c2e05fd2cf7a1fabb14c5a7ae3773c66db1f055214479e388b5e6abf0df8fd1b0e4f90828acc397643cbc274143fb4331262a20634877be4c7489c1ae9eaf90bb2a177a6b5ac15cbda27da0616e5f87461554f5686a7bd6d047ad0b98c8cdea3db78dd2970c78fb861f2a92ddc277876791c4a30f525659557831f4377065d19acb384cc68340152a6de6d84cdb58f433923d1fb8cc6b10bacd95b9ab1b45563998620d192032269fa8301c09a29c4b5b20ca0a3d63a4f5984b7db0f5b17417dc7b939b9b177bf423e2f3d57dff296e6e4ff0fb1744b13731206ead54ef0aa1da09bea8b0ac0ef71b73d009d30531de9fde90d86bf5f20d8e5a9e324e657a98f8c0031adac4385157ba4e28b48aed957a5b36c3b49057f8eca7f56808f794014dad170601070607010e004f42d01cc63b2a1761126ba045f1165e25fdd05901fac6b76e777faaaee6f5ed94302e2da28046b4bc60228e1b9e194f364e377f84681b3011583554b76fbf8d7456dbdea665adad6aa0556c8cc714f217a518a98615c4c1cfc8adbbd4d12c5bc23ad7a0f849e32fe2005334b55d7bcb43d1c95d4793e7c3882740cde8dd24b367294496a3e2f3251a66cdaece9e0a73d853f8d4e3a4637836ded68cb28ba4fcab02d61fb5cfa581792e636217f3238d78912ea0863816ffb2f388823174b19433c2b14bab69e12c3b791fe683744d4519455a52555af0d7e12749f6094afdba00fc6a609c7578c531fc4c3c3065ebf78414f112014726ec2230f9bcd9c15e36283144ccbe0d1785b65cf49ba8fefe92eb6907c0330bc98ac172ea9e8dd4df8974dd6b6772bbc6ca8e8562c5ec0b6592de7440ac915c35e0ac8087f22eba110ca3037b469b1d5bc92636d81881e38d8bbed01a29b3ebcf0c19eb95bf999eb848022592aeaab649ce19824ed9d3a32d75fba556ee07606a306d1fcec2e24b38274c361b7bc96ce37b7f4fe434eba17ac2a097051a92e4ec32e4c678f7762e8b96ebfd2600c0f224b04b2cd7e9f4ad327d53603828015e9cf45969800f02fa5e0ba26b8c844ba1fdffde44303ad0389c1b31d582877ca6bfad4973ba35fbb90ecdd95f430078bc39aa89434130a5fb8321e51f9624090d0277a9f112ee8ff65d3dba999c7c08727d0f08dcf00ce22f62c955d6a822f247c8065ab94ac442e1cb5f31254816794cc2556891a523b8aef09d3b9e07aa8b67b3b87567adebdbdfb93ba9a082f72052572c97e73af16cfc42d2a51a3683f84748a338aab56264753ba4083d356a27c71f47221ed8340c50afd46cd207c4f9634ab5a44888a4234770c46232c35eff83fa950b0a6879137dce209d5a1f26809b411f046f51ff084f15bfe03292ee845d3044235adbc299925235462e67f803daa1426f0e116b93f4532dd2784f7f87ae360281ce21f70d230c242e1a98de8fe1d6147ad71edec89e24a5980c45fd91e23516758af71df8e0dd96929d4da61a3baeabb96c9378986deb4c9101175e3af1e102b52a8da27d916ee4a28263ca485cfe87ee5436249c1a2f933669f6e3274e9bd93092f4a798ae85d6592ebb54dc65c28ba08582e275972b0a12c22a7792ccfd4a398e504c6fb2cf5ef1f9c268540b4fd7d07d59c49a559d86a56a009c4c18a3fceca109fc7a45c6e842abc22053e84878c4805d96ac96ba00fa40fc3b50407141105845055447ca94bd27f234183c2b8bf37f5cd249ed0705afaeae59c8be8f6b38069d67fb23f74284e8185c176b58b482900a3e09774383c7ecacf4fe5e580df99db102ad4018db73c73a635d3fcdc833b000c948d846aacc92ed54ffb3acae1bfe205d6b2312658f15decfa085d13bc3757c754c5704d8089563e0ccf52b04a49df293cafbbc2fed5d9551b5a3897ec7beaa56a4034bedceb4840a9bdfbb8bf47d66dd3a4e3eb1666372c6b2c39a48d52761bd36403cb130a087685e2eabb8711c11005ea09f90ac49665415c56cab6fd2719c45b6800df914f8ff327eed29d9b9a5bbd6b80b8bb31ad1522803b2c8d89166d5c6b2ed47bc5bbbc4abe6709d46b856ab81ddf15f098a9ab76a8257e7e5c2e7dae53fbd691736f0d6bafe0bb939172614e99c7d7e37754af6c3c637d076a43dbd70e5eae910c8170cecff1621e382d2977635b67f4fac555419f8a0bb76ccaeaef4c7385d293c9595ae10e5201c4a31b4c3ecb9f3b304efb1886f9c58a4ef04e73341b95d9bdb85d706b2a8d3fdd153743a8bb7b3289d0fe79f6a3b9e0fe160dd6700fd64fc87d9ac96858a6d395fef6f3d2193ebae7c3a92e18746a7f12b244fbc5b1df0086cc7045036519d9d7bf8e92b850ea0d3d1e775dea362362462dea2d3501d39203e2879070d1f7ac92fa1576f6d12886d5b979e3c788c09a769ef4ee45e14cd8e7553ebeefcd31ff3d43d4988db08f6630ba8ae8c7250ac42a3d78edb967d59310a4a224567d8797c42370cbd2302a3f49abeaf85fad9455f98b61ef2b5e34a5c552583872145e191bbffcaa526f5e38e497a1a1e1220a0f283a935ecd366a9069d5a2a80baba3a22fa85a2557db72d7e29eb4e33e8ed8bb4ec2ec7c2e9cedef46ea955834acf8c9ab23b78052446fd73c9d61683d7fa0088db97d07cc350af0b6b2ad7e66a493af814c11f8c0f2fdf0df40aafd0d218c00319c367e98d7f10c74ea06d31276f3f216e1cb2f12033915008cc83b00ac60fc9c2fb7f97d6e8cd79650d0f9d82bfd9cafef668021d3d165f3fe84221998bc8c29aea0b5b7e0f1f25a0d7447e806cc3fc39e6038be3df9ac01f46222d3a609f8a026744ab4f58a734e3782bec301ea91f2d8e2242d04a11e82474002143223f29656b1a7675aa5ad181004c4f1381df6a0f95a0186e82c04b4de881209e9ccca3ee5b1def0b02353738d92a07314403a1a2721c256121fba8b8ce9b4600000000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 98","NoBenchmark":false},{"Input":"de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000028e392b32f0bc77e652f9f228bab513cf843b6e23c8580cb88d267d0cec21aab444099ed53080f08e7dcf5956e43b29ba14c19952b10659d924abe10674e8298f3d04799537af8f8afab10d1a5832b3180ed31ec02c9b181a3918b5271017e58431f406aeae5fa5919ab68641b2a1f16de913da932a9335a369d74a6db865555af860ff3eaa1519a3fde69e3b0cfd8c59061929c627e98dd67b4bb3b0d6e4c3d71c8c347ea2b48fd031fec89b33a4397b2c5bb95c31d43eb5a1d3e04a747e373b10bbd988daa8bb4219365c68366cfeace24dac4500f9467b15bcbe6ef171d6fe073b2f2be0cde0ea7f85ab83ca2912acae619355178adbdffc9a20e88b76c8c828ed57a06ea18bf94135af6cb999b2fbda45312c8ae42e3b2adc18cab15306b36888f56cd1e57f871aba60548e2bdd8249dc9fede613eec2471831cc645bb7d45fe2433d50706c2e4c40cb3d4f3c24b3d2f8872568987b8e7d5246f6f41c38d3d9ee76d96846c129e858625d8ff7be03196620844745a3e555bc7364bad29adfd836f354d72dd315365edc34298ce248b8ef31140c3eebe38c9b42608d1c7e6bba68f64e669ecac9c4e34e8ebfb3ed97145da35e84bb10d4532d9ac6b31a941d24dd2249de34ac4da8c50d70ea5b394372cb3652f4a4c9a82b290523a7d621cc3024b2289baecfa3ff2fa624ad7c2914cad596b675acf0e76b74d4b829b8a71bf3e563d3f64890eae6de0430b9f4a9bdf3dca0a43bb912f6876863bdf793f9e3fa4190d607f717da21e67a3ff6a737d85cba12f8a12635238223f7ccc3cfcc2957dc7b6eb1244443370c4f932623231a30882ec7d5cf648cef61ceb737abcd8a7f4e7169e4c2b7389faa68faa486d624ad1b3be28b36c3fbb84eec3165d206b1db1338fe86b104eeba7b96477bdc400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000381094f35170312acd574ca38a21c294a729efb2810e32446a55272fc097078c0a7c343480f90c16609e7acb350a86d5142c4234c0d0d76bd09d94fa10d37f1daf3107c1d003816c91f167328d29bf474eae365c783f8b53a2017b6646ab19903eb6d685917e462d325c82a872e4861ac0ba07d743c68622be0410058bb62562464b5649baac4e999c28e2058d616bfb243a685a9ae4ec9a30093817a2a9d64f814a17b16522ef00507c212c53ea18b9cb59a5a6c30ce521b99bc73d7e81376928465e9d0c9170d14d024204deb5b9ae2616c67857669d936eb259ab819ccbab95b688a088564d84012050a7379d5276473600cd43918e34f5287cadecf3c0a6830682c09e45c5a9327ae031f17e1d5a59c2e455699c8a31a9c9607eef9c69c2adabe1aa5eb2feb23825e3318824eb7327107aa7c155044ec30932222b1af387f4729d85005c8a07963eb31920cd50af78f4bbc65c5871a5fd513aa74a604033a71420236de100080b64006c55b7387cd0a61e758bcb255780424010522602f599de13a78116006bfd3a5ac319f907b422c74f8d491780084658403b3d8554f9104e36ab845565b74b569b59ef91f6dcf914384222051117681214e092119404e2f46b9bc96b4058a511bcdf8e33d07db2dbec2c5eae321b21d49968e0b3e55080967ddcb3e784ef687659b9751ce0294fb41e99584e35112c7727671e1556592eebeee39c9c81eec4f38d499a34b4a033e575b7e4e7052192d74a6e9742c01d627b12d36b450b8e620175031b9d23280913624deb7e8d40362b4e54a2b0723ee03b55c02dbc08942a269b88e42193b59c6232845651705b561c155347c31dd75ac6c4db2c6a6224301d3a3f5d514a54224547e6adb0495268c0cf9a84697422a40dd9b3f03aa67e4f2e2d5659e8a0a72f86727695ae53470589615a00a3a523d6f3d1059d32b2f15c11bd0b849c4157f56c536f32ec4665aaa7d23a00662b6368e47bc651a2a565050ed1fdf373c834409952bb8de2d4987a8b3633e89540cecd02ef5cf00ffe5dd442e3e1821039ca4751558c893528ca4a4e0a202f66bb4ee7b5f683f0272b7e9a0dd683769f6a616c6ce4da4b5c1ee8ec86e644b94a6e31b6b56df02dd2aba44ad8d48bb9a2ea64177246e20611558f408916131b7fa233b7d424c4715b4f4da27b9657af046a5995a9d054b04bb4bee96363fe4cbd26b3b8250a2d92fa95e159204a32b3eb1ee7d9054da54648e5a4436e6e1bf6018a35dd86a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ce4d21a6bb3a2356805e678673c45fb055fc5266e3f692af9935aea307f14a5c41b979966a5dfe42ebfed1487e4822b74ab5af28995e085ec8007eca4977c63ee5299fec63dccbc42eeacab488e574249e9d856146750ad97c8a443485ec1c5820beb0964640010f6407140791e74684dbb91052e2d8bef7bdcd78b2ec03c97a53295d683bdbe32a70dc19a2f75b8613aea9616ae0e280179492820f73fb7fa4121e673fb5c328f41b67ff8ffa7aee6564adaba046d6e1d6aa13fb24965390f829246dfa8763851405075f76cf94c66ffc3308214df0960c649aaedc22926ce9357d3875f8b71d68d75999aa3663c30a9edf07228bf7dff49ec1e6c7a33d2053597003b82392e826ebd701b4c981aaac9951c79e08f592c2c0637c8e5a7f9dcda599e859c317d4888b4098992e0e2d979e41c703686d577e5ba6001ec4f587140711293d664963632f87ea0461e0e0c5e9d8d292fb409f9f9ab172ee17fc8afabad06e42b437ce22924eb5dbd3a80a06962f3b37946259f9c75a233cb2b4abdc5cd1b648faeb1be8630db40d151b8fba693df2c5bdcaa14dc4783f450b6bc407515ceebc5c9a47bd1a141384f0b596cab1135c075651cba989c190f3171dc1d72330edaa01656813c4b7811715060b023fc426745c301b2a91e0d08ed3bded438c4ce6799c35f3981c882a0bde4a2feeb1a52cafa47b0c48558fc43f98fe08f03a71128362bb6fb9da6a22249f4d4352ae7d3dae85de497e2411eadcfe5bf1a3c075c45811e0097ecea255fe15bd8321fe8b546a8cacfb899eecf5419db363c7567c2fe7360b36de14674f500a31d3eec71451a7c0d5576a8939c0f6d4d9f2f03f3c516ce25ce73abb35c73aa94f6aefae6ad87052d6b195fa43586817f5bb974aae7f1b8608922411aa5b0d7d574016cbd3ded13395623470a108fa0e1d3f9faa7e1e5031843f2a23dbce8b196315290dea5795e4115d53dc570a444064cfa3c9457dbf3ee323b1966ecd2270c32910f8f430522471258a1f1955a6e1dd8c84ed9a566499bf85628615351abe84b401421da2cfaf575e2644c9304c075ecfc374066cec713fa4c0d89043689fbc59ff54b8f97ee0a3b0989bc5e4ef83cc9833e75bc8b67bb5ee3c06ea156611cda95a6702416807530ea206ed89835d20805ea988b1958569cdf7f809996214dadab4e20bd44917e3410ec6beac98fea07f764e85b66aed5e17cf675d2ed8e63db728fe75158cb31779e31379648b43d68ccff3780854cf03535c57122019456e73cf06769bf1fbf558542241ce665bd10f921828553585e0cf664cdc6160f9c47fa5330591b74194f4716056ca83993efec4a52db9a1fbd3b2f504ac19667325167407375b6d7de739f07947b511c8d475744e5c29d6e286a37f1ff8317bd0178f0e306a38fa6e75f4a80427feb2c91235d3e7f20d8101cfc03bb73f44ef59af3526e9afc580027a1dade37654238b8ec7af0105248fe30784a88b72e11fc1bd807e47a349bd29075befbb29730ef8e85e3abd5105559bacee74aa27d90d360a8d629dbec95eb34c7f7ca20096ff7b521e40d3944a975436896f372eeab6b8615eb91697965bbf955779dd3047f7e3bf029e3509a5780247445d6223d085afb4291d976efadc41e42dc2c0728d18f6155654a332fec72eb6aef8b92c1d177e3dc28c31971bcaff76ddebfd9588bc244b116d409e58dc5ada1648663d603c47faeb814aaa7eb9b6264356f926c18b9357bf426b89ddc8eb9177eceb5c6cdc64dd8feb7b326bc1ba89bd9035235da0e644ef959c58dd97b88d5c749b36931ac2694c67151db0894652e99254222d37cefe9e27b3dd663a152dbe29a3639afe42f4578937076180563aad6ad739255ea012a17d2a56627d84c44fbab261d392a966cfe19278799cf1634d42384323c496190d4b9fb662694e3887ea66ab9e8b195488c8dca47c8bc0424247759137cfbf86dedc3641904cb6facbb30a9fa84acf69a67b4afdf4c2aa420fc0d90cefa0dfbbcd3072d9f772fd6058e2bf0e251be93b00dc43765b53db51b22f12d3ed0cc5655e4aebd9d923f99a43e4461dcf5992030e66a1cdc3a65558d9bb3a39788d92328387d144850dd3706fd7a079e3d2398f542f91a8aaabf0c5068dbaf1fcc5160398abecf74884beb04f3a3ea38bbb80d798f5981b3f2db6c7b33f867b7dc06a4417e30f94cdb4f523aeea0be12bd75aaed57520db0d4b4f013be3a1dc7ae5c58fd1de9637f7d82f697b7e92da427a78feec6a5c0255eb57a43dea6cebc8805bc04e04fe789e222b1e2642d26edc14fb36ecc6092b3060e45eed6c5b35de8741f72933930ecbd7338cf39474122357365700cb50c5eb176fb92814fa7f4032570ccee6b859236ad5da5f1730129edc7be218ba9874620f6f0ebc45e0bd622f8fd1ae6974994af95c6519ec1c46650c073d194fa6ebc62f405f63a3416782a47872c7d77d648d0a1c802ffdfde5fdc112c94cfc68f401889efc522fe488fdb5384c0d93147ab6587659d936f98ecfbcdcfbf8b352d605f18c855e2559743ed97991c5d50df44a7b929303835654a3955abc5bee6327400a7ccce460b318d8b5ece5b12f606adb3d7b5ed59563b8e675e78029aabc234442c2463256fe02b04f556da35c4615d14a9f4eff17db0db81de4bdd894f6628a120be2d4cf3e1f46d53817899657035a76137e23c0b0e8ddd29465d7f15628fd435e6caaca4194fdbf85fdcc31d5dafcb52568b7c0cfbe713bc85fa424ba3abe149e4035fc86807a8b876d2163b447cad5ec0e6ef38a1d591afb46267f9dbf142cab1cac1f73beba212992fc6d4647ec17848d1adbb1901277a5078dd72d9c9184e893c0806e9b4aff0a824670d438620f2a7e8d2965b619d291e5824c014fc888a36fbbe17356431f0039038f9b497902aed969f9c488390b7087763638e976801127baf1f53803c4dc9649f0ee85d67b239e2bdafb2bd75f1d1da22a56fb3af10a9dde7ad306c4af8681029316c0e1949228e6bf5adf942f1c0ef92b2bcbc0c70d49e5808851444240a78b14d21b54f66271482f49b85f5180b268050327368496cfa8b54ecb97ee6d28eb74a3742f68583da046809002c22f7b31fbc0566969f9a15cdca892c4beb101a2ac3526c76e9d30982c9b4893450fdec4001d2431828d24d8b1a67df80e2e10ed2ea8d723227055c48006665f7da8e032efdc70bc7eeb2b369b551fac542ad6df1a23107e2b3c0e3ccacc25f26404c085cbf56e52d35d7948db9fda6dfc24709994719d8ced41a2cc9b3c4b2bef0967cb71861cf0e6aea9bec9395726aa0e2f1a7247ed0f6038e3df4bf566786073590dcf97f8f0a99658d8f630a2d130c46cf4d26c669360d0f70b75f904c9f923ab285d5db129f6c25ad21f9e26ac844d07a8eed86c4e224ebfc5b3f720d6f94b0a01b1433c46b40cf84e80f7a6afa7bb8f9acf818ad3cab2ddd6904c067bea4f1fe79b83cb0aa8fc75b6b096bad6fe94abfd48f8efc0f2b9a02ebda8fdbdbe1c77f1854edba18aae7f31ced9cd34c1b355108df18a8953932f7554af05b203a96a9bb93e0eff51d7f93b56e351562cf85a2d35eae2c2427b89a8662a1c723d4f14e6eafdbd636c2bb7ade29c1a6bc8a463734c808bec68b1e9a31af6e29b412f1cb8c90a9911ac5c3ea71e46113d2d7b1ae2d8802b06a770fd0e9e4652895e42181ad09bb541e9493f258711bb7bedd3e7ca8b8ce875669cf80a6880eca3f13800de7011ea67f443e505c4fb455608ae586f922b3c83fd33b306bdedb86223c33e3aa65edc93cbcf3a03adaf9f328997951d59a9200c0ba2618e3596af176b43122cedc52b1e006ea6d12dc236a6fcd7cc46825f2ef7ed71683a731d746fff2fe54e0b392a8cbfa38873196bb2b835dca7cb7c3ed9a004c7a329b9734a111744bdacdb669e69e9df1e52f07c513e3752a0ccd81d7ddc4a64868b7bb2bbbd2095373480522be10615248a179dcb61dac90f7fa5fa9b84f190a9c62b5ff9cd473a940f03e7107157d7eb60af1e3e384ffe8a67dcb2389b3b0fab7c789cf100ca95cd6a85442cb9a2c243fb9d454b20bae5762d72b8fe79b4df81163d61de4578cf976992d8b9989fc68089f811f53db1e1092b60220552876b818bea981571898cd6ab7b5f13c46b0a076526e3241d65014f855efd7bde08ad91f259dcb64e94ec3dad97811eb024ee1d341521dc92ae5e93c73422088976f2d27d64e1d193b955e6736ad2bccf3c1a53d590576434acbc0b687f27f255fef354e68aca47160efa7126f908e08e4548c11546d9c412d685fa84d2eb4dcb2bdfc48e2fa8023548198ebb072a48044f4391143e3bef4ff9066a4b0d03adc826819d67588ba84f99da27424103652acc039ddd3b567851cd78e4117a8b93afe01fc8eebdaa1acb8ba9d095789e76b9d5ab9ee177a15d666ef171fe1d4bdccfe2e58ce669b561f63028c6ce26db5c8182fe048680b175c7ab407215ff3a7801c950d509867ab1b0bef89b3e38a387915225ede76f91aad15a85d8c46efd588bb3baacbc52c036211512473420f3f061f5f53e9353de0780425745a76439b3811511c86ca503251f24113384e1a24a9367536e796ce08b896f572489a2339e82a856c00000000000000000000000000000000000000000000000000000000","Expected":"0000000000000000000000000000000000000000000000000000000000000000","Gas":1,"Name":"Vector 99","NoBenchmark":false}] ``` https://eips.ethereum.org/assets/eip-7619/bench_vectors https://eips.ethereum.org/assets/eip-7619/bench_vectors 5 seconds benchmark results / ## 5 seconds benchmark results ``` goos: linux goarch: amd64 pkg: github.com/ethereum/go-ethereum/core/vm cpu: Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz BenchmarkPrecompiledEcrecover/-Gas=3000-12 61453 91486 ns/op 3000 gas/op 32.79 mgas/s 800 B/op 7 allocs/op BenchmarkPrecompiledFalcon512/Vector_0-Gas=2101-12 100734 56717 ns/op 2101 gas/op 37.04 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_1-Gas=2106-12 101684 56510 ns/op 2106 gas/op 37.26 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_2-Gas=2111-12 101174 56683 ns/op 2111 gas/op 37.24 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_3-Gas=2116-12 99828 57143 ns/op 2116 gas/op 37.02 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_4-Gas=2121-12 101956 56744 ns/op 2121 gas/op 37.37 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_5-Gas=2126-12 102994 58001 ns/op 2126 gas/op 36.65 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_6-Gas=2131-12 102300 56824 ns/op 2131 gas/op 37.50 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_7-Gas=2136-12 99993 57946 ns/op 2136 gas/op 36.86 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_8-Gas=2141-12 98952 57536 ns/op 2141 gas/op 37.21 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_9-Gas=2146-12 97986 58009 ns/op 2146 gas/op 36.99 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_10-Gas=2151-12 99571 57636 ns/op 2151 gas/op 37.32 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_11-Gas=2156-12 98488 58712 ns/op 2156 gas/op 36.72 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_12-Gas=2161-12 99486 57854 ns/op 2161 gas/op 37.35 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_13-Gas=2166-12 99860 58472 ns/op 2166 gas/op 37.04 mgas/s 2776 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_14-Gas=2171-12 100924 58179 ns/op 2171 gas/op 37.31 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_15-Gas=2176-12 96562 59211 ns/op 2176 gas/op 36.74 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_16-Gas=2181-12 96573 58758 ns/op 2181 gas/op 37.11 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_17-Gas=2186-12 95428 58460 ns/op 2186 gas/op 37.39 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_18-Gas=2191-12 98922 58564 ns/op 2191 gas/op 37.41 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_19-Gas=2196-12 98349 58908 ns/op 2196 gas/op 37.27 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_20-Gas=2201-12 98071 58697 ns/op 2201 gas/op 37.49 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_21-Gas=2206-12 99408 59406 ns/op 2206 gas/op 37.13 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_22-Gas=2211-12 99640 59059 ns/op 2211 gas/op 37.43 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_23-Gas=2216-12 99399 59409 ns/op 2216 gas/op 37.29 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_24-Gas=2221-12 95290 59013 ns/op 2221 gas/op 37.63 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_25-Gas=2226-12 99997 59205 ns/op 2226 gas/op 37.59 mgas/s 3160 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_26-Gas=2231-12 92920 58687 ns/op 2231 gas/op 38.01 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_27-Gas=2236-12 97474 59255 ns/op 2236 gas/op 37.73 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_28-Gas=2241-12 98890 59309 ns/op 2241 gas/op 37.78 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_29-Gas=2246-12 97158 59470 ns/op 2246 gas/op 37.76 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_30-Gas=2251-12 96217 59625 ns/op 2251 gas/op 37.75 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_31-Gas=2256-12 91668 62747 ns/op 2256 gas/op 35.95 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_32-Gas=2266-12 93902 59204 ns/op 2266 gas/op 38.27 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_33-Gas=2271-12 97846 59762 ns/op 2271 gas/op 38.00 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_34-Gas=2276-12 95500 60260 ns/op 2276 gas/op 37.76 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_35-Gas=2281-12 92139 61466 ns/op 2281 gas/op 37.10 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_36-Gas=2286-12 95546 60238 ns/op 2286 gas/op 37.94 mgas/s 3544 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_37-Gas=2291-12 94633 60190 ns/op 2291 gas/op 38.06 mgas/s 3672 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_38-Gas=2296-12 95407 61661 ns/op 2296 gas/op 37.23 mgas/s 3672 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_39-Gas=2301-12 93936 61283 ns/op 2301 gas/op 37.54 mgas/s 3672 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_40-Gas=2306-12 94119 59677 ns/op 2306 gas/op 38.64 mgas/s 3672 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_41-Gas=2311-12 92101 61007 ns/op 2311 gas/op 37.88 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_42-Gas=2316-12 93086 60859 ns/op 2316 gas/op 38.05 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_43-Gas=2321-12 93742 61208 ns/op 2321 gas/op 37.91 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_44-Gas=2326-12 94639 62377 ns/op 2326 gas/op 37.28 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_45-Gas=2331-12 92235 61630 ns/op 2331 gas/op 37.82 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_46-Gas=2336-12 93420 61803 ns/op 2336 gas/op 37.79 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_47-Gas=2341-12 92262 61451 ns/op 2341 gas/op 38.09 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_48-Gas=2346-12 92217 62103 ns/op 2346 gas/op 37.77 mgas/s 3928 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_49-Gas=2351-12 92612 61988 ns/op 2351 gas/op 37.92 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_50-Gas=2356-12 93085 62125 ns/op 2356 gas/op 37.92 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_51-Gas=2361-12 91515 62135 ns/op 2361 gas/op 37.99 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_52-Gas=2366-12 94096 62662 ns/op 2366 gas/op 37.75 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_53-Gas=2371-12 93184 66734 ns/op 2371 gas/op 35.52 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_54-Gas=2376-12 87160 73950 ns/op 2376 gas/op 32.12 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_55-Gas=2381-12 71065 70963 ns/op 2381 gas/op 33.55 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_56-Gas=2386-12 76144 70699 ns/op 2386 gas/op 33.74 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_57-Gas=2391-12 76360 75385 ns/op 2391 gas/op 31.71 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_58-Gas=2396-12 82645 71328 ns/op 2396 gas/op 33.59 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_59-Gas=2401-12 72736 71673 ns/op 2401 gas/op 33.49 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_60-Gas=2406-12 84778 68452 ns/op 2406 gas/op 35.14 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_61-Gas=2411-12 91416 63326 ns/op 2411 gas/op 38.07 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_62-Gas=2416-12 91442 63048 ns/op 2416 gas/op 38.31 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_63-Gas=2421-12 90864 63330 ns/op 2421 gas/op 38.22 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_64-Gas=2431-12 89984 63484 ns/op 2431 gas/op 38.29 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_65-Gas=2436-12 91274 66384 ns/op 2436 gas/op 36.69 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_66-Gas=2441-12 86680 68861 ns/op 2441 gas/op 35.44 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_67-Gas=2446-12 82628 74306 ns/op 2446 gas/op 32.91 mgas/s 4568 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_68-Gas=2451-12 79260 70996 ns/op 2451 gas/op 34.52 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_69-Gas=2456-12 76460 75526 ns/op 2456 gas/op 32.51 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_70-Gas=2461-12 86166 74883 ns/op 2461 gas/op 32.86 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_71-Gas=2466-12 83335 70610 ns/op 2466 gas/op 34.92 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_72-Gas=2471-12 81807 78670 ns/op 2471 gas/op 31.40 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_73-Gas=2476-12 80444 82829 ns/op 2476 gas/op 29.89 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_74-Gas=2481-12 76786 79519 ns/op 2481 gas/op 31.19 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_75-Gas=2486-12 81050 70981 ns/op 2486 gas/op 35.02 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_76-Gas=2491-12 86422 68954 ns/op 2491 gas/op 36.12 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_77-Gas=2496-12 83240 66162 ns/op 2496 gas/op 37.72 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_78-Gas=2501-12 88854 65845 ns/op 2501 gas/op 37.98 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_79-Gas=2506-12 89886 72613 ns/op 2506 gas/op 34.51 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_80-Gas=2511-12 79981 67357 ns/op 2511 gas/op 37.27 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_81-Gas=2516-12 87176 66094 ns/op 2516 gas/op 38.06 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_82-Gas=2521-12 88449 65996 ns/op 2521 gas/op 38.19 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_83-Gas=2526-12 88611 66354 ns/op 2526 gas/op 38.06 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_84-Gas=2531-12 87794 66999 ns/op 2531 gas/op 37.77 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_85-Gas=2536-12 86299 67295 ns/op 2536 gas/op 37.68 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_86-Gas=2541-12 89646 66234 ns/op 2541 gas/op 38.36 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_87-Gas=2546-12 89415 72866 ns/op 2546 gas/op 34.94 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_88-Gas=2551-12 73672 77453 ns/op 2551 gas/op 32.93 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_89-Gas=2556-12 74731 71803 ns/op 2556 gas/op 35.59 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_90-Gas=2561-12 77031 76380 ns/op 2561 gas/op 33.52 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_91-Gas=2566-12 75326 71679 ns/op 2566 gas/op 35.79 mgas/s 5336 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_92-Gas=2571-12 71496 76141 ns/op 2571 gas/op 33.76 mgas/s 5848 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_93-Gas=2576-12 76779 69734 ns/op 2576 gas/op 36.93 mgas/s 5848 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_94-Gas=2581-12 78199 69682 ns/op 2581 gas/op 37.03 mgas/s 5848 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_95-Gas=2586-12 77578 69543 ns/op 2586 gas/op 37.18 mgas/s 5848 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_96-Gas=2596-12 77648 74972 ns/op 2596 gas/op 34.62 mgas/s 5848 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_97-Gas=2601-12 75147 76185 ns/op 2601 gas/op 34.14 mgas/s 5848 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_98-Gas=2606-12 68714 73209 ns/op 2606 gas/op 35.59 mgas/s 5848 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_99-Gas=2611-12 77630 72218 ns/op 2611 gas/op 36.15 mgas/s 5848 B/op 11 allocs/op ``` https://eips.ethereum.org/assets/eip-7619/benchmark_results https://eips.ethereum.org/assets/eip-7619/benchmark_results Set of test vectors to perform benchmarking of EIP-7619 / # Set of test vectors to perform benchmarking of EIP-7619 ## Inlined vectors Here is the list of vectors to perform benchmarking. ``` [ { Input: "de8f50a1", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 0: No data after method signature", }, { Input: "de8f50a1abc", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 1: No enough data after method signature", }, { Input: "de8f50a100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000e0", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 2: Signature offset is zero", }, { Input: "de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 3: Public key offset is zero", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 4: data offset is zero", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e0", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 5: signature length not present in input", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000000", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 6: signature length is present but its value is zero", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000600000000", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 7: Signature indicated length is too long", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000000201111111111111111111111111111111111111111111111111111111111111111", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 8: public key length not present in input", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000020111111111111111111111111111111111111111111111111111111111111111100000000000000000000000000000000000000000000000000000000000000000", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 9: public key length is present but its value is zero", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000020111111111111111111111111111111111111111111111111111111111111111100000000000000000000000000000000000000000000000000800000000000000", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 10: Public Key indicated length is too long", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000020111111111111111111111111111111111111111111111111111111111111111100000000000000000000000000000000000000000000000000000000000000202222222222222222222222222222222222222222222222222222222222222222", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 11: data length not present in input", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000000201111111111111111111111111111111111111111111111111111111111111111000000000000000000000000000000000000000000000000000000000000002022222222222222222222222222222222222222222222222222222222222222220000000000000000000000000000000000000000000000000000000000000000", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 12: data length is present but its value is zero", }, { Input: "de8f50a1000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000002011111111111111111111111111111111111111111111111111111111111111110000000000000000000000000000000000000000000000000000000000000020222222222222222222222222222222222222222222222222222222222222222200000000000000000000000000000000000000000000000050000000000000000", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 13: Data indicated length is too long", }, { Input: "de8f50a10000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000031200000000000000000000000000000000000000000000000000000000000006b30000000000000000000000000000000000000000000000000000000000000292390191ef48486eb9d9a6823d8e6ff0d7f4df8bed13af7fa55a7e8dfa0d19725842a5451bcf4c061982d021c63a7d666c2024fe57033b1a1bda8c2179c518c94d434947eacc109efe792857ff6450cc853e8bb9d5d951b3ddb1397fadc2210762b479e386e660a68eb2ad034a58a3d0cce2370edf257ff4f81fe97c9bb10c1a96ee87d2414fdf4ea39f9f7c0604d1a3aebe5d73a6a1f7221a99eb2389b905da94766cd27a9a89f13d56b97cdd346689cfc5b3bdbbdc5102d3b5f93a2a95be40afcaac416d831391474c2298da0a359bc958a5f227de991a338944d6ebe4963f1a4ba5bb3d5c672526992329c84c5770c03a5e43504a28fa86f3b9bd72354c0b1921d1b568e5212856d8436f79a8c409e631082a4e28b7cb99d89c2a9ab3c196c56a77e6d05718196b316d8e9bedcfc214e2a33c02f0afd821dbfcb966c8bb8dde01c812a2045b6bc8de767f97b739dc8ed262f43dfc092e49f34c7728839895e4620620e4a193e94dbf2a9d439e249e6ec3377ed6734030acd43d138b982c36df814a4257f971a53aa5d92a7670915469013e68124edae3fc11b4ca470938ee2f218bc0e11468a6092f233de914790c972f77d95f968ac5f6e0968e0efa8d628825f3fbad2254e04e9ba34defc698b2e19e9629290f4e5682270595035b07404b091f5325293ed4021c619d7f0914ac47219b9e5df6fda5acbb398adb5c8540dc3390a548d82be42fac8f6ef9963546bcf278e63fdd49d0abbe62208e3956468771df4a50dd7a3aa197d81f58c14425ee166d29aef3eb2c171ff9b24f575e0ae9a65227d1e57ab6c5df11a369645dac717ab671a4c10aef72824134d0e68676bb138ca20eb5e08a0d1f90ee48af1cce1f21c72394ac427f382ced545183689cdb72cec8ea30c77389a16204356259e4b1142d000000000000000000000000000000000000000000000000000000000000038109b7107f987f937ea7566bca38e1578b8d0b59294e68bd208bfa90133101f5efd8755e9f1fd20564762585baa5a4f165ebec6df80ab5248a22bba940a7754abe5329b5c60345f395ad2a33ac106e65f14b91d0dca308ae4cc6db5fe69eee9fe4a392ff64f52865070eb5587e7f83ab6c187cc0584b3552920a3d4b50ab0a4a1e8d9dea3d4b5eb015a2f4ab59ae3d0ad2c081d8d2428a83806de7973ec65975ff8fd7287c642b6a83250255b61838cb4d68c52600b8c5330fce48aaeb806d4fb99a9add5e56577454a5a5ad5699711dd04854bf11484713dea5d9abd17f9214c33c4f4d47a6600bc241011f52e29d9820ac85ab70dfccb1d08c003b489c0826bf28ccee71945637b7161e6a99584451bf8351a43a0b0755ce3044f0840b7ad0489e6572c896666463e2cfc8ebe1258e3a963ab1433b173865705c15f044bcfde1b780d29e422604a9081d2349f6d6b40671b7c6ae77f44c16a22412e9e32cb116363d99ca4d2c3ace6730fd45fc6612d389edcd1c9b2201ba32a4705fac61005e184b89a4c90983acd7afee694ac9d904473eb512ec2d4875c1c954b791506f02c9e65f5d04976ea4e81d22d4884eb1c47eeb1a7ee109e12e61ce0ee4dfa88fdacb78ed61b0a327c2069d8cd33d184e68a60c22f6804faceca968cf5c1c276c7d16386f38bb82d5ea1e11d801f5ef33d3a3b0171dc870741ce8373c779ae8935211348c436285703681f1e6b0adc05c35c56196c246731ee2a4a998ef918a165023a76d324c58419cd9e76ebca0e13823d90b2ebc641717b404e2ee2937d48b38441e88f1086c15c95de8a48632bee5fb56f99f07ac31037323000317c291e2eace7865ece23548e804679241f1366748b1656cd58c28b86d5e08e269d0e3a668a834f4178a188dd63384042773fac10b3d96f533ecabe3a8a27e091d5846d6ead8ac9241437240ad4f7d274b78403402210ad042ddf73d59e02abf657aa41e101455df638d44c181e4ca219f2c6679088ff11af439115d8ef38f3614b957e1ebb9cc2e6bee0c0664da7ba3f1268404a5bac8ed45854881972382908861cc7f14f5d03b112273917854617590aad70eeedf398cb206ff5c7f7a9c5390dfa27e14b1148518833b3375cdfaf5a73680cdd7d0ea5f664672fe91ae6700032a3ee21aeb3ab7b6a0f66b0f65597a7fb6f5c1a9b1459d48885db3734abec9918c0f3a8135bbb2279984a054115e9c12a8f10ca25b93be8a3acfb94dc6a90d4da0e0a7ada80000000000000000000000000000000000000000000000000000000000000064486c8e99de7f81a3b0f4610bb555be687d67e079f5b03ee9d18c21d766fe3d2d36ea378a89294f839dc9bcd9a8251f92cfd39aacc1e228f44442e95b3c59ef904613ece9d312028b07a3cb26b3c9844dcdb2699299d7d47fd63f7889d6c5ce34626b583b", Expected: "0000000000000000000000000000000000000000000000000000000000000001", Name: "vector 14: Correct format but invalid Signature", }, ] ``` https://eips.ethereum.org/assets/eip-7619/invalid_signature_test_vectors https://eips.ethereum.org/assets/eip-7619/invalid_signature_test_vectors / ```plantuml title EIP-7701 Complete Transaction Flow actor "User" skinparam participantFontColor automatic participant "Ethereum" #darkgreen participant "AA_ENTRY_POINT" #darkgreen participant "Deployer Contract" as DC #darkslateblue participant "Sender Contract" as SC #darkorchid participant "Paymaster Contract" as PC #olivedrab participant "Target Contract" as TC #darkred "User" -> "Ethereum": Submit AA transaction note right of "Ethereum": execute\nAA transaction\nstate transition "Ethereum" -> "AA_ENTRY_POINT": ||| group Validation Phase ||| opt Sender Deployment "AA_ENTRY_POINT"->DC: Deploy AA Transaction Sender\n""deployerData"" note over DC: ""ACCEPTROLE 0xA0"" DC -> SC: Deploy Sender Contract\n""CREATE2"" DC-->"AA_ENTRY_POINT":deployed: true ||| end ||| "AA_ENTRY_POINT"->SC: Validate AA Transaction\n""senderValidationData"" note over SC: ""ACCEPTROLE 0xA1"" return valid: true ||| opt Gas Abstraction "AA_ENTRY_POINT"->PC: Validate AA Transaction\n""paymasterData"" note over PC: ""ACCEPTROLE 0xA2"" return valid: true ||| end ||| end group Execution Phase ||| "AA_ENTRY_POINT"->SC: Execute AA Transaction\n""senderExecutionData"" note over SC: ""ACCEPTROLE 0xA3"" ||| SC->TC: AA Transaction\nExecution Body ||| opt PostOp "AA_ENTRY_POINT"->PC: Paymaster PostOp Call note over PC: ""ACCEPTROLE 0xA4"" ||| end ||| end ``` https://eips.ethereum.org/assets/eip-7701/complete_flow https://eips.ethereum.org/assets/eip-7701/complete_flow / ```plantuml title EIP-7701 Simple Transaction Flow actor "User" skinparam participantFontColor automatic participant "Ethereum" #darkgreen participant "AA_ENTRY_POINT" #darkgreen participant "Sender Contract" #darkorchid participant "Target Contract" #darkred "User" -> "Ethereum": Submit AA transaction note right of "Ethereum": execute\nAA transaction\nstate transition "Ethereum" -> "AA_ENTRY_POINT": ||| group Validation Phase ||| "AA_ENTRY_POINT"->"Sender Contract": Validate AA Transaction\n""senderValidationData"" note over "Sender Contract": ""ACCEPTROLE 0xA1"" return valid: true ||| end ||| group Execution Phase "AA_ENTRY_POINT"->"Sender Contract": Execute AA Transaction\n""senderExecutionData"" note over "Sender Contract": ""ACCEPTROLE 0xA3"" ||| "Sender Contract"->"Target Contract": AA Transaction\nExecution Body ||| end ||| ``` https://eips.ethereum.org/assets/eip-7701/simple_flow https://eips.ethereum.org/assets/eip-7701/simple_flow / ```mermaid flowchart LR redeemer(["redeemer"]) --"redeemDelegations"--> Delegation_Manager(["Delegation Manager"]) Delegation_Manager -.->|validate delegation w/ Action| Delegation_Manager Delegation_Manager --"execute delegated action"--> Delegator(["Delegator"]) Delegator --"executes CALL using Action"--> Target(["Target"]) classDef action stroke:#333,stroke-width:2px,stroke-dasharray: 5, 5; classDef entity fill:#af,stroke:#333,stroke-width:2px; class redeemer,Delegator,Delegation_Manager,Target entity; ``` https://eips.ethereum.org/assets/eip-7710/mermaid https://eips.ethereum.org/assets/eip-7710/mermaid ERC-7738 Script Registry Contracts, deployment and test harness scripts / # ERC-7738 Script Registry Contracts, deployment and test harness scripts This folder contains sample (and actual deployed) ERC-7738 registry contracts and tapp scripts ## Test suite - Init hardhat in this directory ```bash npm install --save-dev hardhat ``` - Run the test harness ```bash npx hardhat test ``` # Test a script on the registry ## Deploy Example Token Deploy a test token, let's use a simple ERC-721 with a custom mint function: ```Solidity // SPDX-License-Identifier: MIT // Compatible with OpenZeppelin Contracts ^5.0.0 pragma solidity ^0.8.20; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; contract MyToken is ERC721, Ownable { uint256 private _tokenId; constructor() ERC721("MyToken", "MTK") Ownable(msg.sender) { _tokenId = 1; } function mint() public { _safeMint(msg.sender, _tokenId); _tokenId++; } } ``` Deploy this NFT using eg Remix and make a note of the contract address. ## Create Simple TokenScript, emulate and Deploy First install the TokenScript CLI tool 1. Install the TokenScript build tool (see [TokenScript Quickstart](https://launchpad-doc.vercel.app/quick-start/tokenscript-cli/quick-start-tokenscript-cli)) ```bash npm install -g @tokenscript/cli ``` Here is a minimal example minting tokenscript object file: [Basic NFT TokenScript](/assets/eip-7738/tokenscript/examples/tokenscript.xml). 2. Copy or clone this code to a directory, ensure it is called tokenscript.xml. 3. Locate the following line in the TokenScript: ```xml <ts:address network="ChainId">CONTRACT_ADDRESS</ts:address> ``` Replace the ChainId and CONTRACT_ADDRESS with the contract you deployed in the previous step. 4. Use Emulation to test (in the same directory as you put the examples/tokenscript.xml file): ```bash tokenscript emulate ``` This will let you test the TokenScript functionality before deploying on the registry. The generated page will allow you to mint new tokens. 5. Upload the TokenScript to an FTP or IPFS and make a note of the URL or IPFS hash. ## Add script to the registry 1. Open the registry page: [Holesky Registry Page](https://viewer-staging.tokenscript.org/?chain=17000&contract=0x0077380bCDb2717C9640e892B9d5Ee02Bb5e0682&scriptId=7738_2) [Sepolia Registry Page](https://viewer-staging.tokenscript.org/?chain=11155111&contract=0x0077380bCDb2717C9640e892B9d5Ee02Bb5e0682&scriptId=7738_1) [Base Sepolia Registry Page](https://viewer-staging.tokenscript.org/?chain=84532&contract=0x0077380bCDb2717C9640e892B9d5Ee02Bb5e0682&scriptId=7738_2) Click on the onboarding button "Set ScriptURI". Set the contract address and scriptURI in the card. 2. Test onboarding. Switch wallets, go to the token page of your token (eg for Holesky): `https://viewer-staging.tokenscript.org/?chain=17000&contract=<YOUR CONTRACT ADDRESS>` This will open the TokenScript for your deployed contract. Click on the Mint onboarding button to generate new Tokens. ## Deploy your own registry on a testnet For this test we will use Holesky, but you can also use Sepolia, or any testnet on which the ENS contracts has been deployed. Add some test eth on 2 wallets (0.1 -> 0.5 depending on gas price on the testnet) Create a .env file which contains the following three keys: ``` PRIVATE_KEY_DEPLOY = "0x<PRIVATE KEY 1>" PRIVATE_KEY_2DEPLOY = "0x<PRIVATE KEY 2>" PRIVATE_KEY_ENS = "0x<PRIVATE KEY ENS>" ``` Create an ENS domain on Holesky using the PRIVATE_KEY_ENS wallet. Obtain a `.eth` domain, not `.box` or any other. Go to the ENS app https://app.ens.domains/ and obtain a new ENS using your Holesky. Using the app, unwrap the domain. Click on "More" then "Unwrap". Now, use the script to transfer ownership of the ENS to where the ENSAssigner contract will be written: 1. Add the ENS name to your .env file (don't add the .eth suffix). ``` ENS_NAME="<YOUR ENS>" ``` eg, if the domain you picked was "kilkennycat.eth": ``` ENS_NAME="kilkennycat" ``` 2. Run the script (note this script changes ownership of the domain to the ENSAssigner contract that will soon be deployed) ```bash npx hardhat run ./scripts/changeENSOwner.ts --network holesky ``` Now, ensure the change ownership transaction is written (check the console log of first deployment), and run the deploy script: ```bash npx hardhat run ./scripts/deploy.ts --network holesky ``` Congrats your registry is deployed. Now to issue a bootstrap script for the registry. ## Generate TokenScript and upload to IPFS 1. Open the `./tokenscript` folder in your favourite editor, and find the `tokenscript.xml` file. 2. Locate the Origin contract definition line: ```xml <ts:contract interface="erc721" name="RegistryContract"> ``` 3. Edit the contract network and address on the line below this. 4. Build the TokenScript object file (use commandline from the ./) ```bash tokenscript build ``` 5. Upload the `tokenscript.tsml` file in the `./tokenscript/out` directory to IPFS, or your publicly accessible FTP. ## Set the TokenScript entry on the Script Registry Set the tokenscript for your registry via a script entry on the registry contract itself, using the script itself. This is akin to 'bootstrapping' your registry. You could just as easily accomplish this by using an `ethers.js` script or verifying the contract on `https://etherscan.io` and then using etherscan's write menu. use the tokenscript CLI `emulate` feature: ```bash tokenscript emulate ``` This will automatically open an emulator browser page. Connect your Ethereum wallet which is holding the key you used to deploy the registry contract. Now use the 'Onboarding card' which is defined in the TokenScript xml - click the `Set ScriptURI` button. This will open the card defined in `./onboard.html`. This card invites you to set the contract address - which in this case is your registry contract - and the URI of the Tokenscript TSML you uploaded in step 5. (eg `ipfs://QmRaVBN4NBevk1j4HHfCLrMjjLrYNnsnJS2caJs9smYAtq`). Once you click on the `Set Script URI` button your wallet will ask permission to call the `setScriptURI(address contractAddress, string[] uri)` function. ## Test your registry 1. switch to a new directory and clone the tokenscript viewer repo: ```bash git clone https://github.com/SmartTokenLabs/tokenscript-engine.git ``` ```bash cd ./tokenscript-engine/javascript/tokenscript-viewer ``` 2. update the registry contract address: open `javascript/engine-js/src/repo/sources/RegistryScriptURI.ts` and change `const REGISTRY_7738` to your deployed registry address. 3. Add your Infura API key to the .env (you will have to create the .env file): ``` INFURA_API_KEY=1234567890ABCDEF1234567890ABCDEF ``` 4. Install dependencies and run ```bash npm i ``` ```bash npm run start ``` 4. On the opened webpage, open your deployed registry script: `http://localhost:3333/?chain=17000&contract=<YOUR DEPLOYED REGISTRY CONTRACT ADDRESS>` 5. Set the ScriptURI for the NFT contract you deployed in the first step, by clicking the "Set ScriptURI" button from your deployed tokenscript. Set the NFT contract address and URI path you uploaded to. 6. (Optional) Set a name and icon for the registry script, by clicking on the 'Set Name' and 'Set Icon' buttons on the token that is now displayed. 7. Use the script served from your new registry: `http://localhost:3333/?chain=17000&contract=<YOUR NFT Contract address>` https://eips.ethereum.org/assets/eip-7738/tests https://eips.ethereum.org/assets/eip-7738/tests EIP-7745 log index proof format / ## EIP-7745 log index proof format A log index proof is a Merkle multiproof that fully or partially proves the contents of certain filter map rows and index entries. The proof format specified here can be used to prove the results of log queries, transaction and block hash lookups, and also to initialize the log index state. The root hash of any proof can be calculated and validated against the expected log index root regardless of its contents but the required contents (the proven subset of filter rows and index entries) depend on the use case. These use cases and their conditions for proof validity are detailed in separate documents. The general format of a log index proof is defined as follows: ``` class LogIndexProof(Container): filter_rows: FilterRows index_entries: IndexEntries next_index: uint64 proof_nodes: List[Bytes32] ``` The filter map and index entry data included in the proof uses a more compact encoding than the binary Merkle tree leaves but their contents can be translated into a known set of tree leaves. The `proof_nodes` list provides additional tree node contents required to calculate the log index root and validate it against the one found in the relevant block header. Note that the position and order of the proof nodes is not specified in the proof but can be determined based on the set of known leaves. Also note that the `next_index` pointer of the log index is always supplied with the proof and its leaf node is always considered known. ### Filter map row encoding The `FilterRows` container contains all filter map row data included in the proof. For storage efficiency two different encodings are used: a general purpose one that supports long rows and partial storage of row data, and a compact one capable of fully storing limited size filter rows belonging to the same row index in a continuous range of adjacent filter maps. Note that the efficiency gain achieved by using the compact encoding wherever possible is very significant; with the current filter map parameters the global average of filter row lengths is 1 entry (3 bytes) and for these less populated rows it is a typical scenario that the proof encodes all rows of the same row index in an entire epoch (1024 maps). In a typical use case these rows might account for the major part of the log index proof data. EIP-7745 generally tries to achieve a reasonable balance between efficiency and complexity, and in this case optimizing the encoding of the most frequently occurring scenario with a relatively simple extra encoding format is justified. ``` class FilterRows(Container): short_rows: List[ShortRows] long_rows: List[FilterRow] ``` #### General row encoding ``` class FilterRow(Container): map_index: uint32 row_index, row_length: uint16 stored_row_data: List[StoredRowSection] class StoredRowSection(Container): start_index: uint16 row_data: ByteList ``` In the general case, each filter map row is encoded in its own container. The row length is always stored while the stored column indices are represented as a list of continuous sections, with `row_data` encoded in a compact form (3 bytes per list entry, little endian byte order). Note that in the consensus tree format list entries are hashed as 4 byte _uint32_ values in 32 byte data chunks stored in _ProgressiveList_ tree leaves. Therefore each stored section has to start and end on a chunk boundary (units of 8 list entries), except for the last chunk which can be shorter. Since the row length does determine the number of _ProgressiveList_ tree levels, all leaves of all used tree levels (including the unused zero leaves at the end of the last tree level) are considered as known leaves. Also the `PROG_LIST_NEXT_TREE` branch of the last tree level is known to be a zero leaf. If all list entries are stored then all leaves of the _ProgressiveList_ container tree are considered as known and no extra proof nodes are added in that subtree. #### Short row encoding ``` class ShortRows(Container): first_map_index: uint32 row_index: uint16 row_lengths, row_data: ByteList ``` The `ShortRows` container fully encodes a continuous range of rows if none of them is longer than 255 entries. The length of each row is encoded in the `row_lengths` byte list, while the length of this list determines the number of adjacent map rows encoded. The `row_data` is encoded in compact form (3 bytes per list entry, little endian), with the entries of all encoded rows stored in a single byte list. ### Index entry encoding ``` class IndexEntries(Container): empty_entries: List[uint64] matching_logs: List[MatchingLogEntry] false_logs: List[FalsePositiveLogEntry] tx_entries: List[TxEntry] block_entries: List[BlockEntry] ``` #### Log entry (true match) ``` class MatchingLogEntry(Container): entry_index: uint64 log: Log meta: LogMeta class Log(Container): address: ExecutionAddress topics: List[Bytes32, 4] data: ProgressiveByteList class LogMeta(Container): block_number: uint64 transaction_hash: Root transaction_index: uint64 log_in_tx_index: uint64 ``` In this case the index entry is fully specified, all leaves of the index entry subtree are known, not proof nodes will be added in the index entry container subtree, only at the siblings of the Merkle path leading to the entry in the `index_entries` tree. #### Log entry (false positive) ``` class FalsePositiveLogEntry(Container): entry_index: uint64 address: ExecutionAddress topics: List[Bytes32, 4] ``` In this case only the `address` and `topics` are specified because they are supposed to prove that the potential match indicated by the filter maps is not really a match as the actual address and topics do not match the specified filter criteria. The root of the `data` byte list and the `meta` container are considered unknown and are added as proof nodes. #### Transaction entry ``` class TransactionEntry(Container): entry_index: uint64 meta: TransactionMeta class TransactionMeta(Container): block_number: uint64 transaction_hash: Root transaction_index: uint64 receipt_hash: Root ``` In this case the `Log` container is not initialized and its root is considered to be known as a zero leaf, which distinguishes `TransactionEntry` from log entries. #### Block entry ``` class BlockEntry(Container): entry_index: uint64 meta: BlockMeta class BlockMeta(Container): block_number: uint64 block_hash: Root timestamp: uint64 ``` Similarly to `TransactionEntry`, the `Log` container root is known zero. Note that the last unused (zero) leaf of `BlockMeta` is also considered known and ensures that a `BlockMeta` is always distinguishable from a `TransactionMeta` which has `receipt_hash` in the same position that cannot be zero. ### Proof nodes Proof nodes are tree nodes that are not known and also have no known descendants. They are added to the `proof_nodes` list in the order of a depth-first (left to right) traversal of the log index tree and can also be processed in the same order during the recursive reconstruction of the log index root, as shown on the figure below: ``` 14 *15 \ / *4 5 6 7 \ / \ / 2 3 \ / \ / 1 *: known nodes proof nodes: [5, 6, 14] ``` https://eips.ethereum.org/assets/eip-7745/log_index_proof_format https://eips.ethereum.org/assets/eip-7745/log_index_proof_format EIP-7745 wire protocol extension / ## EIP-7745 wire protocol extension This document specifies the extensions to the [Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) required to initialize the log index. ### Proposed new messages #### GetLogIndexProof (0x12) `[request-id: P, referenceBlockHash: B_32, proofType: P, proofSubset: P]` Require peer to return a __LogIndexProof__ message containing a log index proof that proves the specified subset of the specified type of initialization data from the log index tree belonging to the specified _reference block_. Note that all clients are expected to be able to serve log index proofs using either the current finalized block or the previous one as _reference block_. Also note that the initialization data served by this protocol are split into a limited number of pre-defined subsets so that proofs can be pre-generated for each potential _reference block_. This, together with the limited size of each individual response, makes it easy to ensure that serving this data will not be an excessive burden on the clients. #### LogIndexProof (0x13) `[request-id: P, log_index_proof]` This is the response to __GetLogIndexProof__, providing the RLP encoded log index proof of the requested partial initialization data. See the [log index proof format](/assets/eip-7745/log_index_proof_format) specification. ### Allowed proof types #### EpochBoundaryProof (proofType = 0x01) This proof allows the client to initialize log index rendering at epoch boundaries. It does not prove any filter row data, only index entries, typically of __BlockEntry__ type. Epoch boundary `i` is defined as the boundary between epochs `i` and `i+1` and allows the client to start rendering the index from epoch `i+1`. Epoch boundaries `0 <= i < epoch_count` can be proven, where `epoch_count = next_index // (MAPS_PER_EPOCH * VALUES_PER_MAP)` is the number of completed epochs. Note that every proof proves `next_index` and thereby also `epoch_count`. The range of proven boundaries is determined by the `proofSubset` parameter; boundaries `proofSubset * 128` to `min((proofSubset+1) * 128, epoch_count) - 1` are proven by the returned log index proof. Except for some corner cases listed below, each boundary `i` is proven by two adjacent __BlockEntry__ entries: the last one whose `map_entry_index < i * MAPS_PER_EPOCH * VALUES_PER_MAP` and the first one whose `map_entry_index >= i * MAPS_PER_EPOCH * VALUES_PER_MAP`. This proves the `map_entry_index` position of the last block boundary in the previous epoch, which allows the client to start processing the next block, skip the appropriate number of _map values_ and _index entries_ until the epoch boundary, then start rendering the next epoch. Note that rendering from an epoch boundary is one option to initialize the log index and also makes it possible to generate the index for older epochs later. ##### Corner cases The typical scenario described above assumes that there is at least one __BlockEntry__ both before and after the boundary. This assumption can be false in three valid corner cases: - there is no __BlockEntry__ before the boundary and the block number of the one after the boundary is `firstIndexedBlock`. In this case rendering should start from the first epoch. - there is no __BlockEntry__ after the boundary and the block number of the one before the boundary is `referenceBlock - 1`. In this case rendering from the boundary is possible. - there are no __BlockEntry__ entries anywhere in the index and `firstIndexedBlock == referenceBlock`. In this case rendering should start from the first epoch. In any other case the proof should be considered invalid. Note that rendering an epoch as a part of a log index Merkle tree requires the sibling of the rendered epoch's root node to be known. This is automatically true if a `BlockEntry` in the rendered epoch (the one after the boundary) is proven. Otherwise it is not always guaranteed, therefore if there is no __BlockEntry__ in the next epoch after a proven boundary then the first index entry of that epoch should be proven, either as an __empty entry__, a __FalsePositiveLogEntry__ or a __TxEntry__. #### CurrentMapProof (proofType = 0x02) This proof allows the client to initialize log index rendering at the _reference block_. It proves all rows of the current filter map and the index entry at `next_index`. This dataset is split into a fixed number of subsets (`0 <= proofSubset <= 63`). The proven map index is calculated as `mapIndex = next_index // VALUES_PER_MAP`. Each proof proves 1024 rows between row index `proofSubset * 1024` and `proofSubset * 1024 + 1023`. Additionally, if `proofSubset == 0` then the index entry at `next_index` is also proven as an __empty entry__. This type of proof always uses the general row encoding format and the __FilterRow__ container type (`long_rows` is 1024 items long and `short_rows` is empty). Note that short row encoding has significant benefits when encoding a long section of rows of adjacent maps which is not the case here; in this case the majority of proof data is the sibling proof nodes of the Merkle path leading to each individual row of the same map index. https://eips.ethereum.org/assets/eip-7745/wire_protocol_extension https://eips.ethereum.org/assets/eip-7745/wire_protocol_extension EIP-7825 Empirical Report / # EIP-7825 Empirical Report *The following represents a summary with empirical findings from analyzing a `2**24` transaction gas limit cap.* *Date: July, 2025* ## Dataset - **Period**: 6 months of Ethereum mainnet data (Q1 25) - **Blocks analyzed**: 1,296,000 - **Total transactions**: 251,922,669 ## Impact Metrics ### Transaction Impact | Metric | Value | |--------|-------| | Affected transactions | 96,564 | | Impact rate | 0.0383% | | Unique affected addresses | 4,601 | | Avg transactions per affected address | 21.0 | ### Gas Analysis (of Affected) | Metric | Value | |--------|-------| | Average gas limit (affected txs) | 24,734,127 | | Average gas used | 17,668,721 | | Gas efficiency | 71.4% | | Min gas used | 21,000 | | Max gas used | 35,888,566 | | Transactions with unnecessary high limits | 18,490 (19.15%) | ### Economic Impact | Metric | Value | |--------|-------| | Total additional gas cost | 2,095,905,000 gas units | | Avg additional gas per address | 455,532 gas units | | Avg additional gas per transaction | 21,705 gas units | | Avg cost per address | 0.0004873 ETH | ## Distribution Analysis ### Concentration | Metric | Value | |--------|-------| | Gini coefficient | 0.870 | | Top 10% addresses impact | 79.7% of affected transactions | | Top 50 addresses impact | 37.6% of affected transactions | | Addresses with 1 transaction | 1,848 (40.2%) | | Addresses with >100 transactions | 197 (4.3%) | ## Cumulative Distribution Function ### Sample - **Total transactions analyzed**: 244,628,466 - **Blocks**: 1,317,600 (183 days) ### Distribution | Gas Limit | Cumulative % | Transaction Count | |-----------|--------------|-------------------| | ≤21,000 | 26.02% | 63,660,952 | | ≤50,000 | 36.85% | 90,137,805 | | ≤100,000 | 60.31% | 147,541,155 | | ≤200,000 | 69.50% | 170,005,321 | | ≤500,000 | 92.81% | 227,033,454 | | ≤1,000,000 | 96.65% | 236,444,479 | | ≤2,000,000 | 98.39% | 240,708,106 | | ≤5,000,000 | 99.29% | 242,903,913 | | ≤10,000,000 | 99.76% | 243,975,982 | | ≤16,777,216 | 99.96% | 244,535,902 | | >16,777,216 | 0.04% | 92,564 | ## Address Analysis ### Top 10 From Addresses | Rank | Address | Transactions | Avg Gas Limit | Max Gas Limit | |------|---------|--------------|---------------|---------------| | 1 | 0x22dcb...e1 | 2,555 | 19,940,819 | 20,025,269 | | 2 | 0xc87a8...85 | 2,205 | 22,766,999 | 30,000,000 | | 3 | 0x78ec5...fe | 1,712 | 25,950,213 | 36,000,000 | | 4 | 0x2a8b4...1c | 1,559 | 34,411,392 | 35,947,097 | | 5 | 0xcde69...ff | 1,543 | 23,456,520 | 32,400,000 | | 6 | 0x61fbb...6f | 1,345 | 19,439,482 | 32,400,000 | | 7 | 0x4abf0...32 | 1,287 | 20,403,859 | 25,267,151 | | 8 | 0xd6aaa...77 | 1,189 | 24,467,657 | 25,416,303 | | 9 | 0x7340d...78 | 1,100 | 20,093,929 | 20,094,357 | | 10 | 0xb5b3f...d9 | 1,089 | 19,461,632 | 34,508,005 | ### Top 10 To Addresses | Rank | Address | Transactions | % of Total | |------|---------|--------------|------------| | 1 | 0x06450...f6 | 9,443 | 9.8% | | 2 | 0x00000...0b | 6,645 | 6.9% | | 3 | 0x3c7cb...97 | 3,017 | 3.1% | | 4 | 0xca2b1...44 | 2,907 | 3.0% | | 5 | 0x0a252...59 | 2,817 | 2.9% | | 6 | 0x5b12a...d9 | 2,728 | 2.8% | | 7 | 0xd6da1...29 | 2,651 | 2.7% | | 8 | 0x00000...00 | 2,607 | 2.7% | | 9 | 0xb0cd7...a3 | 2,413 | 2.5% | | 10 | 0x22e4a...ad | 2,369 | 2.5% | ### Concentration Ratios | Metric | Value | |--------|-------| | Unique from addresses | 4,601 | | Unique to addresses | 3,834 | | Concentration ratio | 0.83 | | Top 10 to addresses share | 38.8% | | Top 50 to addresses share | 71.5% | | Top 100 to addresses share | 82.0% | ## Migration Analysis ### Transaction Splitting Requirements | Splits Required | Address Count | Percentage | |-----------------|---------------|------------| | 2 | 4,502 | 97.8% | | 3 | 99 | 2.2% | ### Gas Cost Distribution | Percentile | Additional Gas per Transaction | ETH Cost (Historical) | |------------|-------------------------------|----------------------| | Min | 21,000 | 0.00000636 | | 25th | 21,000 | 0.00000843 | | 50th | 21,000 | 0.00000966 | | 75th | 21,000 | 0.00001175 | | 95th | 42,000 | 0.00002306 | | Max | 84,000 | 0.00003670 | ## Summary Statistics ### 6-Month Period - **Affected transactions**: 96,564 (0.0383%) - **Affected addresses**: 4,601 - **Total ETH impact**: 2.2419 ETH - **Average splits required**: 2.02 ### CDF Analysis (183 days) - **Transactions ≤16,777,216 gas**: 99.96% - **Transactions >16,777,216 gas**: 0.04% https://eips.ethereum.org/assets/eip-7825/analysis https://eips.ethereum.org/assets/eip-7825/analysis EIP-7883 ModExp Analysis Report / # EIP-7883 ModExp Analysis Report *Generated on 2025-07-21 13:34:56* ## Executive Summary This report provides an analysis of EIP-7883's impact on ModExp operations based on 304,301 historical Ethereum mainnet calls using the pricing formula from the latest EIP-7883 specification. ### Key Metrics **Overall Impact:** - **Total ModExp calls analyzed**: 304,301 - **Unique transactions**: 75,134 - **Calls with cost increases**: 304301 (100.0%) - **Total additional gas required**: 542947771 gas - **Average cost increase**: 1,784.25 gas per call - **Maximum single call increase**: 64027 gas **Economic Impact:** - **Network congestion**: Average 0.006% of block gas limit - **Cost predictability**: 100% of calls affected with 2.81x average increase ## Updated Pricing Formula The EIP-7883 specification introduces three key changes: 1. **Minimum gas cost**: Increased from 200 to 500 2. **General multiplier**: Removed division by 3 (effectively 3x increase) 3. **Large exponent multiplier**: Doubled from 8 to 16 for exponents > 32 bytes 4. **Base multiplication complexity**: Minimum of 16, doubles for sizes > 32 bytes ## Parameter Analysis ### Input Size Distributions **Statistical Summary:** | Parameter | Min | Max | Mean | Median | Std Dev | |-----------|-----|-----|------|--------|---------| | Bsize | 32 | 385 | 32.0 | 32.0 | 2.7 | | Esize | 1 | 32 | 32.0 | 32.0 | 0.4 | | Msize | 32 | 384 | 32.0 | 32.0 | 2.7 | **Common Size Combinations:** | Base Size | Exponent Size | Modulus Size | Count | Percentage | |-----------|---------------|--------------|-------|------------| | 32 | 32 | 32 | 304,225 | 100.0% | | 256 | 3 | 256 | 31 | 0.0% | | 128 | 1 | 128 | 27 | 0.0% | | 128 | 32 | 128 | 10 | 0.0% | | 128 | 3 | 128 | 6 | 0.0% | | 385 | 3 | 384 | 2 | 0.0% | ### Exponent Analysis **Fermat Prime Usage**: 1,351 calls (0.4%) **Most Common Exponent Values:** | Rank | Exponent | Count | Percentage | |------|----------|-------|------------| | 1 | 0x30644e72... | 66,115 | 21.73% | | 2 | 0xffffffff... | 54,656 | 17.96% | | 3 | 0x1000000 | 50,599 | 16.63% | | 4 | 0xffffff | 43,887 | 14.42% | | 5 | 0xffffffff... | 28,955 | 9.52% | | 6 | 0xc19139cb... | 20,644 | 6.78% | | 7 | 0x3fffffff... | 15,463 | 5.08% | | 8 | 0x1000002 | 6,703 | 2.20% | | 9 | 0xa59c34 | 6,352 | 2.09% | | 10 | 0x2000000 | 1,699 | 0.56% | ## Gas Cost Analysis ### Cost Distribution | Cost Increase Range | Call Count | Percentage | |-------------------|------------|------------| | <500 gas | 116,974 | 38.4% | | 500-1K gas | 0 | 0.0% | | 1K-5K gas | 187,278 | 61.5% | | 5K-10K gas | 16 | 0.0% | | 10K-50K gas | 31 | 0.0% | | >50K gas | 2 | 0.0% | ### Cost Increase Percentiles | Percentile | Gas Increase | |------------|--------------| | 10th | 300 | | 25th | 300 | | 50th | 2,699 | | 75th | 2,720 | | 90th | 2,720 | | 95th | 2,720 | | 99th | 2,720 | ## Entity Analysis ### Most Impacted Senders | Rank | Address | Total Increase (gas) | Avg Increase | Call Count | Current Cost | New Cost | |------|---------|---------------------|--------------|------------|--------------|----------| | 1 | [0x00000062...](https://etherscan.io/address/0x000000629fbcf27a347d1aeba658435230d74a5f) | 14,062,311 | 1,499.50 | 9,378 | 7,263,261 | 21,325,572 | | 2 | [0x7202932b...](https://etherscan.io/address/0x7202932b3be70edf0657d5bada261d610e0d7db9) | 8,315,040 | 2,720 | 3,057 | 4,157,520 | 12,472,560 | | 3 | [0xaaf7b278...](https://etherscan.io/address/0xaaf7b278bac078aa4f9bdc8e0a93cde604aa67d9) | 7,219,891 | 902.37 | 8,001 | 3,908,541 | 11,128,432 | | 4 | [0x454ef2f6...](https://etherscan.io/address/0x454ef2f69f91527856e06659f92a66f464c1ca4e) | 7,190,430 | 2,678 | 2,685 | 3,592,530 | 10,782,960 | | 5 | [0x54ab716d...](https://etherscan.io/address/0x54ab716d465be3d5eeca64e63ac0048d7a81659a) | 6,794,898 | 913.29 | 7,440 | 3,673,398 | 10,468,296 | | 6 | [0xfcb73f64...](https://etherscan.io/address/0xfcb73f6405f6b9be91013d9477d81833a69c9c0d) | 6,216,927 | 1,499.50 | 4,146 | 3,211,077 | 9,428,004 | | 7 | [0xf3b07f67...](https://etherscan.io/address/0xf3b07f6744e06cd5074b7d15ed2c33760837ce1f) | 3,045,348 | 912.33 | 3,338 | 1,646,548 | 4,691,896 | | 8 | [0x4337001f...](https://etherscan.io/address/0x4337001fff419768e088ce247456c1b892888084) | 2,777,120 | 2,720 | 1,021 | 1,388,560 | 4,165,680 | | 9 | [0x4337003f...](https://etherscan.io/address/0x4337003fcd2f56de3977ccb806383e9161628d0e) | 2,717,280 | 2,720 | 999 | 1,358,640 | 4,075,920 | | 10 | [0x4337002c...](https://etherscan.io/address/0x4337002c5702ce424cb62a56ca038e31e1d4a93d) | 2,652,000 | 2,720 | 975 | 1,326,000 | 3,978,000 | | 11 | [0x4337005d...](https://etherscan.io/address/0x4337005db25dbad41da5692ba1188751ee5d98b6) | 2,589,440 | 2,720 | 952 | 1,294,720 | 3,884,160 | | 12 | [0x4337004e...](https://etherscan.io/address/0x4337004ec9c1417f1c7a26ebd4b4fbed6acf9e5d) | 2,586,720 | 2,720 | 951 | 1,293,360 | 3,880,080 | | 13 | [0x58d14960...](https://etherscan.io/address/0x58d14960e0a2be353edde61ad719196a2b816522) | 1,476,481 | 939.84 | 1,571 | 795,631 | 2,272,112 | | 14 | [0x6f9d816c...](https://etherscan.io/address/0x6f9d816c4ec365fe8fc6898c785be0e2d51bec2c) | 1,416,975 | 2,699 | 525 | 708,225 | 2,125,200 | | 15 | [0xc2adcfcc...](https://etherscan.io/address/0xc2adcfccee33a417064d1a45d3b202de6d9fa474) | 1,232,589 | 1,499.50 | 822 | 636,639 | 1,869,228 | ### Most Impacted Contracts | Rank | Contract | Total Increase (gas) | Avg per Call | Calls | Unique Users | Current Cost | New Cost | |------|----------|---------------------|--------------|-------|--------------|--------------|----------| | 1 | [0x5ff137d4...](https://etherscan.io/address/0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789) | 30,654,400 | 2,720 | 11,270 | 73 | 15,327,200 | 45,981,600 | | 2 | [0x68d30f47...](https://etherscan.io/address/0x68d30f47f19c07bccef4ac7fae2dc12fca3e0dc9) | 14,062,311 | 1,499.50 | 9,378 | 1 | 7,263,261 | 21,325,572 | | 3 | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | 13,028,282 | 951.25 | 13,696 | 17 | 7,011,182 | 20,039,464 | | 4 | [0x5d8ba173...](https://etherscan.io/address/0x5d8ba173dc6c3c90c8f7c04c9288bef5fdbad06e) | 9,141,460 | 899.75 | 10,160 | 9 | 4,950,460 | 14,091,920 | | 5 | [0x870679e1...](https://etherscan.io/address/0x870679e138bcdf293b7ff14dd44b70fc97e12fc0) | 7,190,430 | 2,678 | 2,685 | 1 | 3,592,530 | 10,782,960 | | 6 | [0x3b4d794a...](https://etherscan.io/address/0x3b4d794a66304f130a4db8f2551b0070dfcf5ca7) | 6,216,927 | 1,499.50 | 4,146 | 1 | 3,211,077 | 9,428,004 | | 7 | [0xa13baf47...](https://etherscan.io/address/0xa13baf47339d63b743e7da8741db5456dac1e556) | 1,416,975 | 2,699 | 525 | 1 | 708,225 | 2,125,200 | | 8 | [0xd7f86b4b...](https://etherscan.io/address/0xd7f86b4b8cae7d942340ff628f82735b7a20893a) | 1,260,433 | 2,699 | 467 | 3 | 629,983 | 1,890,416 | | 9 | [0x02993cdc...](https://etherscan.io/address/0x02993cdc11213985b9b13224f3af289f03bf298d) | 1,232,589 | 1,499.50 | 822 | 1 | 636,639 | 1,869,228 | | 10 | [0xece9cf6a...](https://etherscan.io/address/0xece9cf6a8f2768a3b8b65060925b646afeaa5167) | 1,130,574 | 1,752.83 | 645 | 1 | 577,746 | 1,708,320 | | 11 | [0x7cf3876f...](https://etherscan.io/address/0x7cf3876f681dbb6eda8f6ffc45d66b996df08fae) | 1,124,625 | 1,499.50 | 750 | 1 | 580,875 | 1,705,500 | | 12 | [0x150fe8db...](https://etherscan.io/address/0x150fe8dbb943c372f3e8c31d9c89f1e6a13cbbfd) | 792,688 | 2,678 | 296 | 1 | 396,048 | 1,188,736 | | 13 | [0x00000000...](https://etherscan.io/address/0x0000000071727de22e5e9d8baf0edac6f37da032) | 685,440 | 2,720 | 252 | 7 | 342,720 | 1,028,160 | | 14 | [0xd19d4b5d...](https://etherscan.io/address/0xd19d4b5d358258f05d7b411e21a1460d11b0876f) | 575,808 | 1,499.50 | 384 | 1 | 297,408 | 873,216 | | 15 | [0x92ef6af4...](https://etherscan.io/address/0x92ef6af472b39f1b363da45e35530c24619245a4) | 477,723 | 2,699 | 177 | 1 | 238,773 | 716,496 | ## Key Findings and Recommendations ### Impact Summary 1. **Universal Impact**: 100% of ModExp calls will see cost increases under the updated EIP-7883 2. **Significant Increases**: Average 2.8x cost increase across all operations 3. **Predictable Changes**: Cost increases follow clear patterns based on input sizes ### Recommendations by Stakeholder **For Affected Users:** - Review and update gas limits for all ModExp operations - Budget for an average 1,784.25 gas increase per call - Consider optimizing input sizes where possible **For Infrastructure Providers:** - Update gas estimation algorithms immediately - Prepare for universal cost increases across all ModExp calls --- *Report generated from historical Ethereum mainnet data. All gas calculations verified against the latest EIP-7883 specification.* https://eips.ethereum.org/assets/eip-7883/call_analysis https://eips.ethereum.org/assets/eip-7883/call_analysis EIP-7883 Entity Impact Analysis / # EIP-7883 Entity Impact Analysis *Generated on 2025-07-21 13:36:39* ## Executive Summary This report provides entity-level analysis of EIP-7883's impact using the updated pricing formula, focusing on the most affected addresses and their usage patterns. ### Key Statistics - **Total unique senders analyzed**: 143 - **Senders with cost increases**: 143 (100%) - **Total unique contracts**: 42 - **Contracts with increased costs**: 42 (100%) ### Entity Categories | Category | Entity Count | Total Gas Increase | Total Calls | Avg Increase per Entity | |----------|--------------|-------------------|-------------|-------------------------| | Frequent User - High Impact | 8 | 31070669 | 18035 | 3.88M | | Heavy User - High Impact | 3 | 28077100 | 24819 | 9.36M | | Occasional User - High Impact | 42 | 7468316 | 2779 | 177.8K | | Occasional User - Medium Impact | 24 | 1040342 | 490 | 43.3K | | Rare User - Low Impact | 30 | 139499 | 71 | 4.6K | | Rare User - Medium Impact | 9 | 346226 | 58 | 38.5K | | Regular User - High Impact | 27 | 22169730 | 10067 | 821.1K | ## Top 50 Most Affected Entities ### By Total Gas Increase | Rank | Address | Category | Total Increase | Avg per Call | Total Calls | Unique Contracts | % Increase | Current Cost | New Cost | |------|---------|----------|----------------|--------------|-------------|------------------|------------|--------------|----------| | 1 | [0x00000062...](https://etherscan.io/address/0x000000629fbcf27a347d1aeba658435230d74a5f) | Heavy User - High Impact | 14.06M | 1.5K | 9.4K | 1 | 193.6% | 7.26M | 21.33M | | 2 | [0x7202932b...](https://etherscan.io/address/0x7202932b3be70edf0657d5bada261d610e0d7db9) | Frequent User - High Impact | 8.32M | 2.7K | 3.1K | 1 | 200.0% | 4.16M | 12.47M | | 3 | [0xaaf7b278...](https://etherscan.io/address/0xaaf7b278bac078aa4f9bdc8e0a93cde604aa67d9) | Heavy User - High Impact | 7.22M | 902.37 | 8.0K | 2 | 184.7% | 3.91M | 11.13M | | 4 | [0x454ef2f6...](https://etherscan.io/address/0x454ef2f69f91527856e06659f92a66f464c1ca4e) | Frequent User - High Impact | 7.19M | 2.7K | 2.7K | 1 | 200.1% | 3.59M | 10.78M | | 5 | [0x54ab716d...](https://etherscan.io/address/0x54ab716d465be3d5eeca64e63ac0048d7a81659a) | Heavy User - High Impact | 6.79M | 913.29 | 7.4K | 2 | 185.0% | 3.67M | 10.47M | | 6 | [0xfcb73f64...](https://etherscan.io/address/0xfcb73f6405f6b9be91013d9477d81833a69c9c0d) | Frequent User - High Impact | 6.22M | 1.5K | 4.1K | 1 | 193.6% | 3.21M | 9.43M | | 7 | [0xf3b07f67...](https://etherscan.io/address/0xf3b07f6744e06cd5074b7d15ed2c33760837ce1f) | Frequent User - High Impact | 3.05M | 912.33 | 3.3K | 2 | 185.0% | 1.65M | 4.69M | | 8 | [0x4337001f...](https://etherscan.io/address/0x4337001fff419768e088ce247456c1b892888084) | Frequent User - High Impact | 2.78M | 2.7K | 1.0K | 2 | 200.0% | 1.39M | 4.17M | | 9 | [0x4337003f...](https://etherscan.io/address/0x4337003fcd2f56de3977ccb806383e9161628d0e) | Regular User - High Impact | 2.72M | 2.7K | 999 | 2 | 200.0% | 1.36M | 4.08M | | 10 | [0x4337002c...](https://etherscan.io/address/0x4337002c5702ce424cb62a56ca038e31e1d4a93d) | Regular User - High Impact | 2.65M | 2.7K | 975 | 2 | 200.0% | 1.33M | 3.98M | | 11 | [0x4337005d...](https://etherscan.io/address/0x4337005db25dbad41da5692ba1188751ee5d98b6) | Regular User - High Impact | 2.59M | 2.7K | 952 | 2 | 200.0% | 1.29M | 3.88M | | 12 | [0x4337004e...](https://etherscan.io/address/0x4337004ec9c1417f1c7a26ebd4b4fbed6acf9e5d) | Regular User - High Impact | 2.59M | 2.7K | 951 | 2 | 200.0% | 1.29M | 3.88M | | 13 | [0x58d14960...](https://etherscan.io/address/0x58d14960e0a2be353edde61ad719196a2b816522) | Frequent User - High Impact | 1.48M | 939.84 | 1.6K | 2 | 185.6% | 795.6K | 2.27M | | 14 | [0x6f9d816c...](https://etherscan.io/address/0x6f9d816c4ec365fe8fc6898c785be0e2d51bec2c) | Regular User - High Impact | 1.42M | 2.7K | 525 | 1 | 200.1% | 708.2K | 2.13M | | 15 | [0xc2adcfcc...](https://etherscan.io/address/0xc2adcfccee33a417064d1a45d3b202de6d9fa474) | Regular User - High Impact | 1.23M | 1.5K | 822 | 1 | 193.6% | 636.6K | 1.87M | | 16 | [0x94a365ca...](https://etherscan.io/address/0x94a365ca808029af8db18257ecd296c16c61ac05) | Regular User - High Impact | 1.13M | 1.8K | 645 | 1 | 195.7% | 577.7K | 1.71M | | 17 | [0x9c0b0dbb...](https://etherscan.io/address/0x9c0b0dbbae8a976ceea8c2a96f6d00c53839afdc) | Regular User - High Impact | 1.12M | 1.5K | 750 | 1 | 193.6% | 580.9K | 1.71M | | 18 | [0x35274399...](https://etherscan.io/address/0x3527439923a63f8c13cf72b8fe80a77f6e572092) | Frequent User - High Impact | 1.06M | 948.79 | 1.1K | 1 | 185.8% | 568.4K | 1.62M | | 19 | [0x2b711ee0...](https://etherscan.io/address/0x2b711ee00b50d67667c4439c28aeaf7b75cb6e0d) | Frequent User - High Impact | 993.3K | 899.75 | 1.1K | 2 | 184.7% | 537.9K | 1.53M | | 20 | [0xa58428fd...](https://etherscan.io/address/0xa58428fd982447bdef7c8b6db6e9beb964b56147) | Regular User - High Impact | 839.4K | 2.7K | 311 | 1 | 200.1% | 419.5K | 1.26M | | 21 | [0x3f261ad6...](https://etherscan.io/address/0x3f261ad6666d6fea319939a3373776632e252778) | Regular User - High Impact | 792.7K | 2.7K | 296 | 1 | 200.1% | 396.0K | 1.19M | | 22 | [0x52ff08f3...](https://etherscan.io/address/0x52ff08f313a00a54e3beffb5c4a7f7446efb6754) | Regular User - High Impact | 575.8K | 1.5K | 384 | 1 | 193.6% | 297.4K | 873.2K | | 23 | [0xe8c20ea8...](https://etherscan.io/address/0xe8c20ea8ef100d7aa3846616e5d07a5abb067c65) | Regular User - High Impact | 477.7K | 2.7K | 177 | 1 | 200.1% | 238.8K | 716.5K | | 24 | [0x1a8312fa...](https://etherscan.io/address/0x1a8312fad1d803660d5d5dee8cddfc35b3bec33d) | Regular User - High Impact | 440.6K | 2.7K | 162 | 1 | 200.0% | 220.3K | 661.0K | | 25 | [0xc1c0104f...](https://etherscan.io/address/0xc1c0104f8ec7cf4b2fc4f86781aa6cbd0e8a2400) | Regular User - High Impact | 415.6K | 2.7K | 154 | 1 | 200.1% | 207.7K | 623.4K | | 26 | [0xf70da978...](https://etherscan.io/address/0xf70da97812cb96acdf810712aa562db8dfa3dbef) | Regular User - High Impact | 359.0K | 2.7K | 132 | 1 | 200.0% | 179.5K | 538.6K | | 27 | [0xc8564726...](https://etherscan.io/address/0xc8564726aaa50cf006ea28c5ef2dadd85a26b723) | Regular User - High Impact | 326.4K | 2.7K | 120 | 1 | 200.0% | 163.2K | 489.6K | | 28 | [0xad0a80a0...](https://etherscan.io/address/0xad0a80a085095eca46de3053c345516f1c722d2a) | Regular User - High Impact | 315.8K | 1.0K | 309 | 1 | 187.2% | 168.7K | 484.5K | | 29 | [0x415ed64d...](https://etherscan.io/address/0x415ed64d42bc0c37aeaaef79aa767d963ef38807) | Regular User - High Impact | 304.4K | 1.7K | 175 | 1 | 195.6% | 155.6K | 460.0K | | 30 | [0x7c088b4c...](https://etherscan.io/address/0x7c088b4c6dceae8889e1fcc8c52de8cb930f89a0) | Regular User - High Impact | 285.6K | 2.7K | 105 | 1 | 200.0% | 142.8K | 428.4K | | 31 | [0x01b27db5...](https://etherscan.io/address/0x01b27db5a9a57c7bd411676413980f0c5ac2fd4f) | Regular User - High Impact | 285.6K | 2.7K | 105 | 1 | 200.0% | 142.8K | 428.4K | | 32 | [0xf79a32b8...](https://etherscan.io/address/0xf79a32b893b793ff4964134273b9c0ab8e9b4005) | Regular User - High Impact | 285.6K | 2.7K | 105 | 1 | 200.0% | 142.8K | 428.4K | | 33 | [0x0e902b2d...](https://etherscan.io/address/0x0e902b2d0408754271c9e97d81fd2ede279cade6) | Occasional User - High Impact | 269.3K | 2.7K | 99 | 1 | 200.0% | 134.6K | 403.9K | | 34 | [0xf279dfcd...](https://etherscan.io/address/0xf279dfcdd57e1571c95e2c5b7e2ee453cbcdf77f) | Occasional User - High Impact | 261.1K | 2.7K | 96 | 1 | 200.0% | 130.6K | 391.7K | | 35 | [0x8e86251c...](https://etherscan.io/address/0x8e86251c88e5b3ef134a37bcab2cd63beb627c4c) | Occasional User - High Impact | 261.1K | 2.7K | 96 | 1 | 200.0% | 130.6K | 391.7K | | 36 | [0xe1963570...](https://etherscan.io/address/0xe19635704ae3b77bc993358ff515d10cceae0ce1) | Occasional User - High Impact | 261.1K | 2.7K | 96 | 1 | 200.0% | 130.6K | 391.7K | | 37 | [0x8f47a238...](https://etherscan.io/address/0x8f47a238c7701247ee8469ddc37ac1df121cfcce) | Occasional User - High Impact | 253.0K | 2.7K | 93 | 1 | 200.0% | 126.5K | 379.4K | | 38 | [0xcd0b5a01...](https://etherscan.io/address/0xcd0b5a01abe9c14f6efbc610c02ecf0fb69855da) | Regular User - High Impact | 252.2K | 1.7K | 145 | 1 | 195.6% | 129.0K | 381.2K | | 39 | [0x3749dd5d...](https://etherscan.io/address/0x3749dd5d2820dc16f8128c81b14a3eba5826e04f) | Occasional User - High Impact | 236.6K | 2.7K | 87 | 1 | 200.0% | 118.3K | 355.0K | | 40 | [0x554b30ef...](https://etherscan.io/address/0x554b30efcc7bf683b6e97170c1201ebfc69de4c8) | Occasional User - High Impact | 228.5K | 2.7K | 84 | 1 | 200.0% | 114.2K | 342.7K | | 41 | [0x7b5cb95e...](https://etherscan.io/address/0x7b5cb95e372246b074e5e17d58e98bef46897b9a) | Occasional User - High Impact | 212.2K | 2.7K | 78 | 1 | 200.0% | 106.1K | 318.2K | | 42 | [0x1d539601...](https://etherscan.io/address/0x1d53960165188ee0c74a5705ee6307fea517c613) | Occasional User - High Impact | 212.2K | 2.7K | 78 | 1 | 200.0% | 106.1K | 318.2K | | 43 | [0x6a6fb757...](https://etherscan.io/address/0x6a6fb757b09178de160a39e1d82c9626ebd2be41) | Occasional User - High Impact | 212.2K | 2.7K | 78 | 1 | 200.0% | 106.1K | 318.2K | | 44 | [0xcfdee1e8...](https://etherscan.io/address/0xcfdee1e80f67d45761f321f3c9ecb28aae769810) | Occasional User - High Impact | 204.0K | 2.7K | 75 | 1 | 200.0% | 102.0K | 306.0K | | 45 | [0x30066439...](https://etherscan.io/address/0x30066439887c0a509cb38e45c9262e6924a29bbd) | Regular User - High Impact | 200.0K | 1.7K | 115 | 1 | 195.6% | 102.3K | 302.3K | | 46 | [0x9b1a331b...](https://etherscan.io/address/0x9b1a331b4ac667fd97674ceedd861008488a3e40) | Occasional User - High Impact | 195.8K | 2.7K | 72 | 1 | 200.0% | 97.9K | 293.8K | | 47 | [0xb5b25e9b...](https://etherscan.io/address/0xb5b25e9b8c5c2d4e03ca0a79e42aa226cdec3ff2) | Occasional User - High Impact | 195.8K | 2.7K | 72 | 1 | 200.0% | 97.9K | 293.8K | | 48 | [0xce54f65a...](https://etherscan.io/address/0xce54f65abb8b61b83c14cbe97de97fce75bbf556) | Occasional User - High Impact | 195.8K | 2.7K | 72 | 1 | 200.0% | 97.9K | 293.8K | | 49 | [0x2891d2f9...](https://etherscan.io/address/0x2891d2f99bc447a591f06d896f5f72647aa1bc4c) | Occasional User - High Impact | 195.8K | 2.7K | 72 | 1 | 200.0% | 97.9K | 293.8K | | 50 | [0x0392b4cc...](https://etherscan.io/address/0x0392b4cc79fbb0f38d8942866c0302ae01c2b194) | Occasional User - High Impact | 187.7K | 2.7K | 69 | 1 | 200.0% | 93.8K | 281.5K | ## Top 50 Most Affected Contracts | Rank | Contract Address | Total Increase | Avg per Call | Total Calls | Unique Users | User Concentration | % Increase | Current Cost | New Cost | |------|------------------|----------------|--------------|-------------|--------------|-------------------|------------|--------------|----------| | 1 | [0x5ff137d4...](https://etherscan.io/address/0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789) | 30.65M | 2.7K | 11.3K | 73.0 | 0.99 | 200.0% | 15.33M | 45.98M | | 2 | [0x68d30f47...](https://etherscan.io/address/0x68d30f47f19c07bccef4ac7fae2dc12fca3e0dc9) | 14.06M | 1.5K | 9.4K | 1.0 | 1.00 | 193.6% | 7.26M | 21.33M | | 3 | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | 13.03M | 951.25 | 13.7K | 17.0 | 1.00 | 185.8% | 7.01M | 20.04M | | 4 | [0x5d8ba173...](https://etherscan.io/address/0x5d8ba173dc6c3c90c8f7c04c9288bef5fdbad06e) | 9.14M | 899.75 | 10.2K | 9.0 | 1.00 | 184.7% | 4.95M | 14.09M | | 5 | [0x870679e1...](https://etherscan.io/address/0x870679e138bcdf293b7ff14dd44b70fc97e12fc0) | 7.19M | 2.7K | 2.7K | 1.0 | 1.00 | 200.1% | 3.59M | 10.78M | | 6 | [0x3b4d794a...](https://etherscan.io/address/0x3b4d794a66304f130a4db8f2551b0070dfcf5ca7) | 6.22M | 1.5K | 4.1K | 1.0 | 1.00 | 193.6% | 3.21M | 9.43M | | 7 | [0xa13baf47...](https://etherscan.io/address/0xa13baf47339d63b743e7da8741db5456dac1e556) | 1.42M | 2.7K | 525 | 1.0 | 1.00 | 200.1% | 708.2K | 2.13M | | 8 | [0xd7f86b4b...](https://etherscan.io/address/0xd7f86b4b8cae7d942340ff628f82735b7a20893a) | 1.26M | 2.7K | 467 | 3.0 | 1.00 | 200.1% | 630.0K | 1.89M | | 9 | [0x02993cdc...](https://etherscan.io/address/0x02993cdc11213985b9b13224f3af289f03bf298d) | 1.23M | 1.5K | 822 | 1.0 | 1.00 | 193.6% | 636.6K | 1.87M | | 10 | [0xece9cf6a...](https://etherscan.io/address/0xece9cf6a8f2768a3b8b65060925b646afeaa5167) | 1.13M | 1.8K | 645 | 1.0 | 1.00 | 195.7% | 577.7K | 1.71M | | 11 | [0x7cf3876f...](https://etherscan.io/address/0x7cf3876f681dbb6eda8f6ffc45d66b996df08fae) | 1.12M | 1.5K | 750 | 1.0 | 1.00 | 193.6% | 580.9K | 1.71M | | 12 | [0x150fe8db...](https://etherscan.io/address/0x150fe8dbb943c372f3e8c31d9c89f1e6a13cbbfd) | 792.7K | 2.7K | 296 | 1.0 | 1.00 | 200.1% | 396.0K | 1.19M | | 13 | [0x00000000...](https://etherscan.io/address/0x0000000071727de22e5e9d8baf0edac6f37da032) | 685.4K | 2.7K | 252 | 7.0 | 0.98 | 200.0% | 342.7K | 1.03M | | 14 | [0xd19d4b5d...](https://etherscan.io/address/0xd19d4b5d358258f05d7b411e21a1460d11b0876f) | 575.8K | 1.5K | 384 | 1.0 | 1.00 | 193.6% | 297.4K | 873.2K | | 15 | [0x92ef6af4...](https://etherscan.io/address/0x92ef6af472b39f1b363da45e35530c24619245a4) | 477.7K | 2.7K | 177 | 1.0 | 1.00 | 200.1% | 238.8K | 716.5K | | 16 | [0xb90ed4c1...](https://etherscan.io/address/0xb90ed4c123843cbfd66b11411ee7694ef37e6e72) | 359.0K | 2.7K | 132 | 1.0 | 1.00 | 200.0% | 179.5K | 538.6K | | 17 | [0xb32cb567...](https://etherscan.io/address/0xb32cb5677a7c971689228ec835800432b339ba2b) | 177.5K | 22.2K | 8 | 2.0 | 0.88 | 500.0% | 35.5K | 213.0K | | 18 | [0xef2a435e...](https://etherscan.io/address/0xef2a435e5ee44b2041100ef8cbc8ae035166606c) | 171.4K | 2.7K | 64 | 1.0 | 1.00 | 200.1% | 85.6K | 257.0K | | 19 | [0xabea9132...](https://etherscan.io/address/0xabea9132b05a70803a4e85094fd0e1800777fbef) | 159.9K | 779.80 | 205 | 1.0 | 1.00 | 181.4% | 88.1K | 248.0K | | 20 | [0xb4544083...](https://etherscan.io/address/0xb45440830bd8d288bb2b5b01be303ae60fc855d8) | 108.0K | 1.5K | 72 | 1.0 | 1.00 | 193.6% | 55.8K | 163.7K | | 21 | [0x95ca91ce...](https://etherscan.io/address/0x95ca91cea73239b15e5d2e5a74d02d6b5e0ae458) | 59.4K | 2.7K | 22 | 1.0 | 1.00 | 200.1% | 29.7K | 89.1K | | 22 | [0xd1ce9000...](https://etherscan.io/address/0xd1ce90003a10e6dab877890ab1fd96511555e4b3) | 54.6K | 6.8K | 8 | 1.0 | 1.00 | 500.1% | 10.9K | 65.5K | | 23 | [0x3d18ad73...](https://etherscan.io/address/0x3d18ad735f949febd59bbfcb5864ee0157607616) | 40.2K | 2.7K | 15 | 1.0 | 1.00 | 200.1% | 20.1K | 60.2K | | 24 | [0x5968ada2...](https://etherscan.io/address/0x5968ada261a84e19a6c85830e655647752585ed4) | 29.9K | 2.7K | 11 | 1.0 | 1.00 | 200.0% | 15.0K | 44.9K | | 25 | [0x2f3c2056...](https://etherscan.io/address/0x2f3c205613d9451f88e19e011ed23775afe00c41) | 27.0K | 1.5K | 18 | 1.0 | 1.00 | 193.6% | 13.9K | 40.9K | | 26 | [0x271682de...](https://etherscan.io/address/0x271682deb8c4e0901d1a1550ad2e64d568e69909) | 21.6K | 2.7K | 8 | 3.0 | 0.75 | 200.1% | 10.8K | 32.4K | | 27 | [0x38de07d2...](https://etherscan.io/address/0x38de07d2526ae929f1903e5f109b70c50e12a8e0) | 18.0K | 1.5K | 12 | 1.0 | 1.00 | 193.6% | 9.3K | 27.3K | | 28 | [0x30efaaa9...](https://etherscan.io/address/0x30efaaa99f8efe310d9fdc83072e2a04c093d400) | 14.1K | 300 | 47 | 1.0 | 1.00 | 150.0% | 9.4K | 23.5K | | 29 | [0x2d5805a4...](https://etherscan.io/address/0x2d5805a423d6ce771f06972ad4499f120902631a) | 10.9K | 2.7K | 4 | 2.0 | 0.75 | 200.0% | 5.4K | 16.3K | | 30 | [0x5b5a0580...](https://etherscan.io/address/0x5b5a0580bcfd3673820bb249514234afad33e209) | 8.2K | 2.7K | 3 | 1.0 | 1.00 | 200.0% | 4.1K | 12.2K | | 31 | [0xb3445d54...](https://etherscan.io/address/0xb3445d5413abf63df1112a4a517de2602f249785) | 8.2K | 2.7K | 3 | 1.0 | 1.00 | 200.0% | 4.1K | 12.2K | | 32 | [0x9569fe8c...](https://etherscan.io/address/0x9569fe8cd0050069328e3707cffb61c77ddeb9d0) | 8.1K | 2.7K | 3 | 1.0 | 1.00 | 200.1% | 4.0K | 12.1K | | 33 | [0x1fa7cb49...](https://etherscan.io/address/0x1fa7cb4925086128f3bb9e26761c9c75dbac3cd1) | 8.1K | 2.7K | 3 | 2.0 | 0.67 | 200.1% | 4.0K | 12.1K | | 34 | [0x0baac79a...](https://etherscan.io/address/0x0baac79acd45a023e19345c352d8a7a83c4e5656) | 8.0K | 2.7K | 3 | 1.0 | 1.00 | 200.1% | 4.0K | 12.0K | | 35 | [0xbadc0ffe...](https://etherscan.io/address/0xbadc0ffee00baa564f3fea62e9d37843284c1e6a) | 5.4K | 2.7K | 2 | 1.0 | 1.00 | 200.0% | 2.7K | 8.2K | | 36 | [0xad3b67bc...](https://etherscan.io/address/0xad3b67bca8935cb510c8d18bd45f0b94f54a968f) | 5.4K | 2.7K | 2 | 1.0 | 1.00 | 200.0% | 2.7K | 8.2K | | 37 | [0x8ddbbcc0...](https://etherscan.io/address/0x8ddbbcc0999f396237b6534ac600ebb0d8618c99) | 5.4K | 2.7K | 2 | 1.0 | 1.00 | 200.0% | 2.7K | 8.2K | | 38 | [0xf0d54349...](https://etherscan.io/address/0xf0d54349addcf704f77ae15b96510dea15cb7952) | 5.4K | 2.7K | 2 | 1.0 | 1.00 | 200.1% | 2.7K | 8.1K | | 39 | [0xfeda03b9...](https://etherscan.io/address/0xfeda03b91514d31b435d4e1519fd9e699c29bbfc) | 3.3K | 300 | 11 | 4.0 | 0.73 | 150.0% | 2.2K | 5.5K | | 40 | [0x159f3668...](https://etherscan.io/address/0x159f3668c72bbecdf1fb31beed606ec9649654eb) | 2.7K | 2.7K | 1 | 1.0 | 1.00 | 200.1% | 1.3K | 4.0K | | 41 | [0xd18d1779...](https://etherscan.io/address/0xd18d17791f2071bf3c855ba770420a9edea0728d) | 1.2K | 312 | 4 | 4.0 | 0.25 | 156.0% | 800 | 2.0K | | 42 | [0x2eb474cf...](https://etherscan.io/address/0x2eb474cffabca358d9fd3f1d43ad2b2dfb809b0e) | 312 | 312 | 1 | 1.0 | 1.00 | 156.0% | 200 | 512 | ### Most Active Entities | Rank | Address | Total Calls | Active Blocks | Calls/1K Blocks | First Block | Last Block | Activity Span | |------|---------|-------------|---------------|-----------------|-------------|------------|---------------| | 1 | [0x00000062...](https://etherscan.io/address/0x000000629fbcf27a347d1aeba658435230d74a5f) | 9.4K | 1.6K | 19.1 | 22.09M | 22.58M | 491.2K blocks | | 2 | [0xaaf7b278...](https://etherscan.io/address/0xaaf7b278bac078aa4f9bdc8e0a93cde604aa67d9) | 8.0K | 292 | 18.4 | 22.09M | 22.52M | 434.3K blocks | | 3 | [0x54ab716d...](https://etherscan.io/address/0x54ab716d465be3d5eeca64e63ac0048d7a81659a) | 7.4K | 688 | 17.1 | 22.09M | 22.52M | 434.4K blocks | | 4 | [0xfcb73f64...](https://etherscan.io/address/0xfcb73f6405f6b9be91013d9477d81833a69c9c0d) | 4.1K | 691 | 8.4 | 22.09M | 22.58M | 491.2K blocks | | 5 | [0xf3b07f67...](https://etherscan.io/address/0xf3b07f6744e06cd5074b7d15ed2c33760837ce1f) | 3.3K | 335 | 7.7 | 22.09M | 22.52M | 434.4K blocks | | 6 | [0x7202932b...](https://etherscan.io/address/0x7202932b3be70edf0657d5bada261d610e0d7db9) | 3.1K | 967 | 30.6 | 22.09M | 22.19M | 99.9K blocks | | 7 | [0x454ef2f6...](https://etherscan.io/address/0x454ef2f69f91527856e06659f92a66f464c1ca4e) | 2.7K | 1.3K | 5.5 | 22.09M | 22.58M | 491.4K blocks | | 8 | [0x58d14960...](https://etherscan.io/address/0x58d14960e0a2be353edde61ad719196a2b816522) | 1.6K | 192 | 3.2 | 22.09M | 22.58M | 490.9K blocks | | 9 | [0x35274399...](https://etherscan.io/address/0x3527439923a63f8c13cf72b8fe80a77f6e572092) | 1.1K | 144 | 3.1 | 22.09M | 22.45M | 359.7K blocks | | 10 | [0x2b711ee0...](https://etherscan.io/address/0x2b711ee00b50d67667c4439c28aeaf7b75cb6e0d) | 1.1K | 138 | 2.3 | 22.09M | 22.58M | 486.1K blocks | | 11 | [0x4337001f...](https://etherscan.io/address/0x4337001fff419768e088ce247456c1b892888084) | 1.0K | 502 | 2.1 | 22.09M | 22.58M | 491.2K blocks | | 12 | [0x4337003f...](https://etherscan.io/address/0x4337003fcd2f56de3977ccb806383e9161628d0e) | 999 | 490 | 2.0 | 22.09M | 22.58M | 491.3K blocks | | 13 | [0x4337002c...](https://etherscan.io/address/0x4337002c5702ce424cb62a56ca038e31e1d4a93d) | 975 | 482 | 2.0 | 22.09M | 22.58M | 491.4K blocks | | 14 | [0x4337005d...](https://etherscan.io/address/0x4337005db25dbad41da5692ba1188751ee5d98b6) | 952 | 469 | 1.9 | 22.09M | 22.58M | 491.1K blocks | | 15 | [0x4337004e...](https://etherscan.io/address/0x4337004ec9c1417f1c7a26ebd4b4fbed6acf9e5d) | 951 | 468 | 1.9 | 22.09M | 22.58M | 491.2K blocks | | 16 | [0xc2adcfcc...](https://etherscan.io/address/0xc2adcfccee33a417064d1a45d3b202de6d9fa474) | 822 | 137 | 1.7 | 22.09M | 22.58M | 490.8K blocks | | 17 | [0x9c0b0dbb...](https://etherscan.io/address/0x9c0b0dbbae8a976ceea8c2a96f6d00c53839afdc) | 750 | 125 | 1.5 | 22.09M | 22.58M | 491.0K blocks | | 18 | [0x94a365ca...](https://etherscan.io/address/0x94a365ca808029af8db18257ecd296c16c61ac05) | 645 | 101 | 1.6 | 22.09M | 22.50M | 411.5K blocks | | 19 | [0x6f9d816c...](https://etherscan.io/address/0x6f9d816c4ec365fe8fc6898c785be0e2d51bec2c) | 525 | 175 | 1.1 | 22.09M | 22.58M | 491.0K blocks | | 20 | [0x52ff08f3...](https://etherscan.io/address/0x52ff08f313a00a54e3beffb5c4a7f7446efb6754) | 384 | 64 | 0.8 | 22.09M | 22.58M | 489.8K blocks | ### Highest Average Impact per Call | Rank | Address | Avg Increase/Call | Total Calls | Total Increase | Category | |------|---------|-------------------|-------------|----------------|----------| | 1 | [0x01b27db5...](https://etherscan.io/address/0x01b27db5a9a57c7bd411676413980f0c5ac2fd4f) | 2.7K | 105 | 285.6K | Regular User - High Impact | | 2 | [0x0e902b2d...](https://etherscan.io/address/0x0e902b2d0408754271c9e97d81fd2ede279cade6) | 2.7K | 99 | 269.3K | Occasional User - High Impact | | 3 | [0x0a0256a9...](https://etherscan.io/address/0x0a0256a9166041101c90be87bbebb8242a3ba015) | 2.7K | 45 | 122.4K | Occasional User - High Impact | | 4 | [0x0392b4cc...](https://etherscan.io/address/0x0392b4cc79fbb0f38d8942866c0302ae01c2b194) | 2.7K | 69 | 187.7K | Occasional User - High Impact | | 5 | [0x1a8312fa...](https://etherscan.io/address/0x1a8312fad1d803660d5d5dee8cddfc35b3bec33d) | 2.7K | 162 | 440.6K | Regular User - High Impact | | 6 | [0x17a9aa3f...](https://etherscan.io/address/0x17a9aa3f7945fb00c2eb16857baa4adb63da59db) | 2.7K | 15 | 40.8K | Occasional User - Medium Impact | | 7 | [0x106b67c3...](https://etherscan.io/address/0x106b67c3f6d4fff429668b0496d2e4cda55e805b) | 2.7K | 48 | 130.6K | Occasional User - High Impact | | 8 | [0x10314ac2...](https://etherscan.io/address/0x10314ac278aa9d431701f49e70273bd6e40c93f7) | 2.7K | 48 | 130.6K | Occasional User - High Impact | | 9 | [0x4337004e...](https://etherscan.io/address/0x4337004ec9c1417f1c7a26ebd4b4fbed6acf9e5d) | 2.7K | 951 | 2.59M | Regular User - High Impact | | 10 | [0x4337005d...](https://etherscan.io/address/0x4337005db25dbad41da5692ba1188751ee5d98b6) | 2.7K | 952 | 2.59M | Regular User - High Impact | | 11 | [0x435b3539...](https://etherscan.io/address/0x435b3539f68283dd44f03a4bfe8666c0f6187033) | 2.7K | 54 | 146.9K | Occasional User - High Impact | | 12 | [0x43d2cf58...](https://etherscan.io/address/0x43d2cf587f2dd7853a60d6a53032b1217e6ad8a4) | 2.7K | 51 | 138.7K | Occasional User - High Impact | | 13 | [0x1d539601...](https://etherscan.io/address/0x1d53960165188ee0c74a5705ee6307fea517c613) | 2.7K | 78 | 212.2K | Occasional User - High Impact | | 14 | [0x1f55ce12...](https://etherscan.io/address/0x1f55ce1234aa67f28b00c493535a230d8f1d16c7) | 2.7K | 15 | 40.8K | Occasional User - Medium Impact | | 15 | [0x211d9824...](https://etherscan.io/address/0x211d98242e4c58e9eb17e3cc135a165bd59dd172) | 2.7K | 45 | 122.4K | Occasional User - High Impact | | 16 | [0x23b32bae...](https://etherscan.io/address/0x23b32bae4708bc9af3962b81d6d8ca5327e9dffc) | 2.7K | 54 | 146.9K | Occasional User - High Impact | | 17 | [0x2915637a...](https://etherscan.io/address/0x2915637a5f4b83b4097fc0b2eae2fe3c1c761465) | 2.7K | 33 | 89.8K | Occasional User - Medium Impact | | 18 | [0x256b3cc1...](https://etherscan.io/address/0x256b3cc1e516d124b3027ecd083aa5a940d1328e) | 2.7K | 54 | 146.9K | Occasional User - High Impact | | 19 | [0x2791a02d...](https://etherscan.io/address/0x2791a02da92175eb44d267cdcc954debf64ca31f) | 2.7K | 63 | 171.4K | Occasional User - High Impact | | 20 | [0x2891d2f9...](https://etherscan.io/address/0x2891d2f99bc447a591f06d896f5f72647aa1bc4c) | 2.7K | 72 | 195.8K | Occasional User - High Impact | ## Entity Relationships ### Multi-Contract Users Entities using multiple contracts (top 20 by total impact): | Rank | Entity Address | Contracts Used | Total Calls | Total Increase | Primary Contract | |------|----------------|----------------|-------------|----------------|------------------| | 1 | [0xaaf7b278...](https://etherscan.io/address/0xaaf7b278bac078aa4f9bdc8e0a93cde604aa67d9) | 2 | 8.0K | 7.22M | [0x5d8ba173...](https://etherscan.io/address/0x5d8ba173dc6c3c90c8f7c04c9288bef5fdbad06e) | | 2 | [0x54ab716d...](https://etherscan.io/address/0x54ab716d465be3d5eeca64e63ac0048d7a81659a) | 2 | 7.4K | 6.79M | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | | 3 | [0xf3b07f67...](https://etherscan.io/address/0xf3b07f6744e06cd5074b7d15ed2c33760837ce1f) | 2 | 3.3K | 3.05M | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | | 4 | [0x4337001f...](https://etherscan.io/address/0x4337001fff419768e088ce247456c1b892888084) | 2 | 1.0K | 2.78M | [0x5ff137d4...](https://etherscan.io/address/0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789) | | 5 | [0x4337003f...](https://etherscan.io/address/0x4337003fcd2f56de3977ccb806383e9161628d0e) | 2 | 999 | 2.72M | [0x5ff137d4...](https://etherscan.io/address/0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789) | | 6 | [0x4337002c...](https://etherscan.io/address/0x4337002c5702ce424cb62a56ca038e31e1d4a93d) | 2 | 975 | 2.65M | [0x5ff137d4...](https://etherscan.io/address/0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789) | | 7 | [0x4337005d...](https://etherscan.io/address/0x4337005db25dbad41da5692ba1188751ee5d98b6) | 2 | 952 | 2.59M | [0x5ff137d4...](https://etherscan.io/address/0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789) | | 8 | [0x4337004e...](https://etherscan.io/address/0x4337004ec9c1417f1c7a26ebd4b4fbed6acf9e5d) | 2 | 951 | 2.59M | [0x5ff137d4...](https://etherscan.io/address/0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789) | | 9 | [0x58d14960...](https://etherscan.io/address/0x58d14960e0a2be353edde61ad719196a2b816522) | 2 | 1.6K | 1.48M | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | | 10 | [0x2b711ee0...](https://etherscan.io/address/0x2b711ee00b50d67667c4439c28aeaf7b75cb6e0d) | 2 | 1.1K | 993.3K | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | | 11 | [0x2572835e...](https://etherscan.io/address/0x2572835e02b59078711aa0800490e80975e4169d) | 2 | 168 | 151.2K | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | | 12 | [0x59b84b24...](https://etherscan.io/address/0x59b84b24e307682df830b32ddc826fbbe003c210) | 2 | 144 | 129.6K | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | | 13 | [0x0f9b807d...](https://etherscan.io/address/0x0f9b807d5b0ce12450059b425dc35c727d65cb2f) | 2 | 136 | 122.4K | [0x8c0bfc04...](https://etherscan.io/address/0x8c0bfc04ada21fd496c55b8c50331f904306f564) | | 14 | [0x5ccc2130...](https://etherscan.io/address/0x5ccc2130e77ae3a3211740c2e897bfbb5d70aa54) | 2 | 2 | 5.4K | [0x1fa7cb49...](https://etherscan.io/address/0x1fa7cb4925086128f3bb9e26761c9c75dbac3cd1) | ## Power User Analysis Entities in the top 1% by call volume (≥7.8K calls): | Rank | Address | Total Calls | Total Increase | % of All Calls | % of All Increase | Category | |------|---------|-------------|----------------|----------------|-------------------|----------| | 1 | [0x00000062...](https://etherscan.io/address/0x000000629fbcf27a347d1aeba658435230d74a5f) | 9.4K | 14.06M | 3.08% | 2.59% | Heavy User - High Impact | | 2 | [0xaaf7b278...](https://etherscan.io/address/0xaaf7b278bac078aa4f9bdc8e0a93cde604aa67d9) | 8.0K | 7.22M | 2.63% | 1.33% | Heavy User - High Impact | ## Summary Statistics ### Entity Distribution - **Heavy Users (≥5,000 calls)**: 3 entities - **Frequent Users (1,000-4,999 calls)**: 8 entities - **Regular Users (100-999 calls)**: 27 entities - **Occasional Users (10-99 calls)**: 66 entities - **Rare Users (<10 calls)**: 39 entities ### Impact Distribution - **High Impact (≥100K gas increase)**: 80 entities - **Medium Impact (10K-99K gas)**: 33 entities - **Low Impact (<10K gas)**: 30 entities ### Concentration Metrics - **Top 10 entities**: 11.2% of total gas increase - **Top 50 entities**: 15.5% of total gas increase - **Top 100 entities**: 16.6% of total gas increase ## Key Insights 1. **Universal Impact**: All entities using the precompile are affected by the updated EIP-7883 pricing 2. **Significant Increases**: Average cost increase of ~3x across all operations 3. **Usage Patterns**: Heavy users will face the largest absolute cost increases 4. **Contract Concentration**: Some contracts serve many users and will see major cumulative impacts ## Methodology - **Data source**: Ethereum mainnet ModExp precompile calls - **Entity identification**: Based on transaction 'from' addresses - **Impact calculation**: Sum of all gas cost increases under updated EIP-7883 - **Categorization**: Based on usage patterns and impact levels - **Concentration score**: Measures how concentrated contract usage is (0=distributed, 1=single user) --- *This entity-focused analysis provides detailed insights into how the updated EIP-7883 impacts different users of the ModExp precompile.* https://eips.ethereum.org/assets/eip-7883/entity_analysis https://eips.ethereum.org/assets/eip-7883/entity_analysis Compute operations to reprice in EIP-7904 / # Compute operations to reprice in EIP-7904 #### Maria Silva, January 2026 In this report, we present which operations should have a cost increase with EIP-7904 and describe the methodology to pick them. The analysis can be reproduced in the [0.5-gasbench_data_eda](https://github.com/misilva73/evm-gas-repricings/blob/185f37f5e0a5636161d5da4983d87a4e420b227a/notebooks/0.5-gasbench_data_eda.ipynb) notebook. ### Methodology #### Data The raw benchmark data was generated by running the [EEST benchmark suite](https://github.com/ethereum/execution-spec-tests/tree/main/tests/benchmark) with the [Nethermind benchmarking tooling](https://github.com/NethermindEth/gas-benchmarks). The database is hosted on a PostgreSQL server managed by the Nethermind team. Each test was run multiple times to isolate random variations in runtime and outliers. The data was collected between 2026-01-05 and 2026-01-22. The test are still using the Prague fork. A similar analysis is still needed for the Osaka fork. All benchmarks were run on the performance branches of each client using the following hardware specification: | Specification | Value | |--------------|-------| | spec_processor_type | x86_64 | | spec_system_os | Linux | | spec_kernel_release | 6.8.0-53-generic | | spec_kernel_version | #55-Ubuntu SMP PREEMPT_DYNAMIC | | spec_machine_arch | x86_64 | | spec_processor_arch | 64bit | | spec_cpu_model | AMD EPYC 7713 64-Core Processor | | spec_num_cpus | 32 | #### Data processing The raw benchmark data was processed as follows: 1. **Parsing test metadata**: Each test title was parsed to extract the test file, test name, test parameters, fork version, and the target opcode or precompile being tested. 2. **Filtering invalid data**: Tests with execution time of 0ms were excluded. The ethrex client was also excluded from the analysis as it is still in early development. 3. **Removing outliers**: For each (client, test, opcode) combination, outliers were identified using the interquartile range (IQR) method: - Lower threshold: Q1 - 1.5 × IQR - Upper threshold: Q3 + 1.5 × IQR - Data points outside these thresholds were flagged as outliers and excluded from the worst-case analysis. 4. **Computing worst-case performance**: For each (client, test, opcode) combination, the minimum non-outlier MGas/s value was selected to represent the worst-case execution performance. 5. **Aggregating by opcode**: For each opcode, the worst-performing test across all clients was identified, along with the second-worst client's performance on that same test. #### Selecting candidates Operations were selected as candidates for repricing based on the following criteria: 1. **Performance threshold**: The worst-case MGas/s must be below 60 MGas/s. By increase the costs of these operations, we will be able to increase our base throughput 3x from our current 20Mgas/s. 2. **Multi-client validation**: To avoid penalizing all clients for a single client's implementation inefficiency, the second-worst client's performance is also considered. If the second-worst client achieves significantly better performance (>20% above the threshold), the operation is flagged for client optimization rather than repricing. 3. **Excluding very slow tests**: Tests with worst-case MGas/s below 20 MGas/s were analyzed separately to understand if the slowness is due to specific test parameters or possible errors in data. After Osaka, we are running at 20Mgas/s, so we should not observe test with values lower than this. ### Performance results #### Run times distribution by client The benchmark data covers 237,733 test runs across 5 clients (Besu, Erigon, Geth, Nethermind, and Reth) on the Prague fork. The overall distribution of MGas/s shows significant variation across tests and clients. ![mgas_distribution_by_client](/assets/eip-7904/figures/mgas_distribution_by_client.png) The boxplot above shows that different clients have different performance characteristics: - **Nethermind** and **Reth** the highest median performance - **Besu** shows a wider distribution with a majority of tests at lower MGas/s values - **Erigon** and **Geth** have intermediate performance, with still some slower tests, but a higher median performance than Besu. #### Worst vs. second-worst client An important consideration for repricing is whether poor performance is isolated to a single client or affects multiple implementations. This is important for distinguishing between: - Operations that genuinely need repricing (multiple clients struggle) - Operations where a specific client needs optimization (only one client struggles) The chart shows the number of tests in which each client was the worst performer. We can see that **Besu** is the worst performer in the majority of tests, followed by Erigon. ![worst_client_count](/assets/eip-7904/figures/worst_client_count.png) The next plot shows the distribution of the performance ratio between the worst client and second-worst client. Each boxplot shows this distribution by the client (i.e., when each client is the worst performer). ![worst_second_worst_gap](/assets/eip-7904/figures/worst_second_worst_gap.png) For a majority of tests, the gap between worst and second-worst is small (<20%), suggesting that the worst client is not significantly underperforming on relation to the other clients. However, we do see some tests with the gas is much wider. These test are more frequent for when Besu is the worst client. #### Underpriced operations at 60 MGas/s The following table shows operations with worst-case performance below 60 MGas/s: | Operation | Type | Worst MGas/s | Worst Client | Second Worst MGas/s | |-----------|------|-------------|--------------|---------------------| | MULMOD | opcode | 20.60 | besu | 57.02 | | MODEXP | precompile | 21.63 | geth | 25.06 | | EQ | opcode | 22.80 | besu | 122.96 | | SDIV | opcode | 23.14 | besu | 85.18 | | REVERT | opcode | 23.38 | besu | 110.41 | | SMOD | opcode | 24.99 | besu | 67.98 | | MOD | opcode | 25.27 | besu | 70.98 | | SAR | opcode | 27.15 | besu | 134.36 | | MUL | opcode | 27.60 | besu | 147.87 | | SUB | opcode | 28.80 | besu | 122.66 | | DIV | opcode | 29.94 | besu | 88.54 | | SHIFT | opcode | 30.47 | besu | 124.32 | | point evaluation | precompile | 31.75 | erigon | 31.85 | | RETURN | opcode | 32.95 | besu | 103.85 | | ADDMOD | opcode | 32.98 | besu | 91.12 | | CALLCODE | opcode | 34.78 | besu | 112.96 | | CALLDATALOAD | opcode | 35.52 | besu | 77.65 | | CALL | opcode | 35.60 | besu | 98.94 | | DELEGATECALL | opcode | 36.30 | besu | 127.70 | | SELFDESTRUCT | opcode | 36.65 | besu | 628.81 | | STATICCALL | opcode | 37.60 | besu | 105.77 | | CALLDATACOPY | opcode | 38.08 | besu | 193.12 | | KECCAK | opcode | 38.49 | besu | 70.90 | | SHL | opcode | 39.64 | besu | 136.58 | | SHR | opcode | 41.84 | besu | 134.38 | | BLS12_G1ADD | precompile | 41.97 | besu | 73.64 | | XOR | opcode | 47.34 | besu | 122.21 | | blake2f | precompile | 47.48 | reth | 50.07 | | ecAdd | precompile | 47.89 | besu | 63.51 | | BLS12_G2ADD | precompile | 49.01 | besu | 69.11 | | SHA2-256 | precompile | 52.29 | besu | 235.32 | | AND | opcode | 54.66 | besu | 122.87 | | identity | precompile | 54.74 | besu | 178.01 | | OR | opcode | 54.91 | besu | 126.59 | | ecRecover | precompile | 55.04 | besu | 58.41 | | TLOAD | opcode | 55.90 | erigon | 789.42 | | CALLDATASIZE | opcode | 56.91 | besu | 134.27 | | MSTORE | opcode | 57.07 | besu | 145.72 | | ecPairing | precompile | 57.34 | nethermind | 67.85 | | ecMul | precompile | 58.66 | reth | 90.32 | This table is then split into two categories below: **Candidates for repricing** (where multiple clients struggle) and **Operations requiring client optimization** (where only one client struggles). As expected, there are a significant number of operations where Besu is performing bellow 60Mgas/s, but the rest of the clients have a significantly higher performance. These are the likely cases where a single client optimization is needed. MODEXP is still performing at 21.63 Mgas/s, however we expect this value to change in the Osaka branch as this operation was already repriced there. We need to run this again on the newest fork. #### Slow tests We also observed test performing at less than 20Mgas/s. Since there are likely issues in the data, we exclude them from the underpriced operations. However, we need to confirm whether this is actually issues in the test and not a new bottleneck. The test in question are the following: - `test_extcode_ops` in Geth and Erigon - `test_xcall` in Geth - `test_arithmetic` in Besu (only `opcode_ADD`) - `test_selfbalance` in Besu (only `contract_balance_0`) - `test_call_frame_context_ops` in Besu (`opcode_ORIGIN`) ### Final list #### Candidates for repricing The following operations are candidates for repricing under EIP-7904. These are operations where: - The worst-case MGas/s is below 60 MGas/s, AND - The second-worst client also performs below 72 MGas/s (60 × 1.2), indicating the poor performance is not isolated to a single client | Operation | Type | Worst MGas/s | Worst Client | Second Worst MGas/s | Second Worst / Worst | |-----------|------|-------------|--------------|---------------------|----------------------| | MULMOD | opcode | 20.60 | besu | 57.02 | 2.77× | | MODEXP | precompile | 21.63 | geth | 25.06 | 1.16× | | SMOD | opcode | 24.99 | besu | 67.98 | 2.72× | | MOD | opcode | 25.27 | besu | 70.98 | 2.81× | | point evaluation | precompile | 31.75 | erigon | 31.85 | 1.00× | | KECCAK | opcode | 38.49 | besu | 70.90 | 1.84× | | BLS12_G1ADD | precompile | 41.97 | besu | 73.64 | 1.75× | | blake2f | precompile | 47.48 | reth | 50.07 | 1.05× | | ecAdd | precompile | 47.89 | besu | 63.51 | 1.33× | | BLS12_G2ADD | precompile | 49.01 | besu | 69.11 | 1.41× | | ecRecover | precompile | 55.04 | besu | 58.41 | 1.06× | | ecPairing | precompile | 57.34 | nethermind | 67.85 | 1.18× | #### Operations requiring client optimization The following operations have poor performance on a single client but acceptable performance on others. These should be addressed through client optimization rather than protocol-level repricing: | Operation | Type | Worst MGas/s | Worst Client | Second Worst MGas/s | Gap | |-----------|------|-------------|--------------|---------------------|-----| | EQ | opcode | 22.80 | besu | 122.96 | 5.4× | | SDIV | opcode | 23.14 | besu | 85.18 | 3.7× | | REVERT | opcode | 23.38 | besu | 110.41 | 4.7× | | SAR | opcode | 27.15 | besu | 134.36 | 4.9× | | MUL | opcode | 27.60 | besu | 147.87 | 5.4× | | SUB | opcode | 28.80 | besu | 122.66 | 4.3× | | DIV | opcode | 29.94 | besu | 88.54 | 3.0× | | SHIFT | opcode | 30.47 | besu | 124.32 | 4.1× | | RETURN | opcode | 32.95 | besu | 103.85 | 3.2× | | ADDMOD | opcode | 32.98 | besu | 91.12 | 2.8× | | CALLCODE | opcode | 34.78 | besu | 112.96 | 3.2× | | CALLDATALOAD | opcode | 35.52 | besu | 77.65 | 2.2× | | CALL | opcode | 35.60 | besu | 98.94 | 2.8× | | DELEGATECALL | opcode | 36.30 | besu | 127.70 | 3.5× | | SELFDESTRUCT | opcode | 36.65 | besu | 628.81 | 17.2× | | STATICCALL | opcode | 37.60 | besu | 105.77 | 2.8× | | CALLDATACOPY | opcode | 38.08 | besu | 193.12 | 5.1× | | SHL | opcode | 39.64 | besu | 136.58 | 3.4× | | SHR | opcode | 41.84 | besu | 134.38 | 3.2× | | XOR | opcode | 47.34 | besu | 122.21 | 2.6× | | SHA2-256 | precompile | 52.29 | besu | 235.32 | 4.5× | | AND | opcode | 54.66 | besu | 122.87 | 2.2× | | identity | precompile | 54.74 | besu | 178.01 | 3.3× | | OR | opcode | 54.91 | besu | 126.59 | 2.3× | | TLOAD | opcode | 55.90 | erigon | 789.42 | 14.1× | | CALLDATASIZE | opcode | 56.91 | besu | 134.27 | 2.4× | | MSTORE | opcode | 57.07 | besu | 145.72 | 2.6× | | ecMul | precompile | 58.66 | reth | 90.32 | 1.5× | The next step is to reach out to the individual clients and assess the reason for the slow performance and whether it can be improved by Glamsterdam. #### Client feedback The Besu team provided the following feedback: - They are not yet able to reproduce the numbers for `EQ`, so more analysis here is needed. - They are already working on optimizing arithmetic operations (e.g. `MOD`, `SMOD`, `ADDMOD`, `MULMOD`, `DIV`, `SDIV`, `MUL` and `SUB`). They expect the performance to improve with new `Uint256` implementation. - They proposed to add to the repricing table all the `DIV` related opcodes as they are more complex than simple arithmetic like `ADD` and based on the same algorithm. The list of these operations is `MOD`, `SMOD`, `ADDMOD`, `MULMOD`, `DIV`, and `SDIV`. https://eips.ethereum.org/assets/eip-7904/included_operations https://eips.ethereum.org/assets/eip-7904/included_operations New gas cost proposal for EIP-7904 / New gas cost proposal for EIP-7904 ================================== This is an automated report generated from the script `./src/estimate_7904_repricings.py`. The script uses the runtime estimation output generated by this script. The report with the runtime estimation results can be found in `./reports/eip-7904/2026-01-15_2026-01-29/runtime_estimation_autogenerated_report.md`. ## Methodology New gas costs are calculated using an anchor rate of **60 million gas per second**, which represents a target execution rate for EVM operations. The formula used is: ``` new_gas = (anchor_rate * runtime_ms) / 1000 ``` Where `runtime_ms` is the estimated runtime in milliseconds from the regression models. ## Understanding the results The table below shows the **worst-case** gas costs across all tested clients (taking the maximum estimated cost per operation). This conservative approach ensures that the new gas costs account for the slowest implementation among the major Ethereum clients. The **Change** column shows the relative change as a decimal (e.g., 1.0 = 100% increase, 0.5 = 50% increase, -0.25 = 25% decrease). Operations with `inf` indicate costs going from 0 to a positive value. Only operations and parameters with good model fits (R² > 0.5 and p-value < 0.05) are included in the gas cost proposals. Operations with poor model fits are listed separately in the "Errors and caveats" section. ## New gas proposal The following table shows the new gas cost for all operations and parameters with a good model fit. |Opcode|Parameter|Current Gas|New Gas (Rounded)|Change| | :---: | :---: | :---: | :---: | :---: | |ADDMOD|constant|8|8|0.0| |BLAKE2F|constant|0|170|inf| |BLAKE2F|num_rounds|1|2|1.0| |BLS12_G1ADD|constant|375|643|0.71| |BLS12_G2ADD|constant|600|765|0.27| |DIV|constant|5|15|2.0| |ECADD|constant|150|314|1.09| |ECPAIRING|constant|45000|34710|-0.23| |ECPAIRING|num_pairs|34000|34103|0.0| |ECRECOVER|constant|3000|2904|-0.03| |KECCAK256|constant|30|45|0.5| |KECCAK256|msg_size|6|1|-0.83| |MOD|constant|5|12|1.4| |MULMOD|constant|8|11|0.38| |POINT_EVALUATION|constant|50000|89363|0.79| |SDIV|constant|5|20|3.0| |SMOD|constant|5|3|-0.4| ## Gas costs by client The following plot shows the new gas costs (rounded) for each operation parameter across different clients, with error bars representing the confidence intervals. ![Gas costs by client](/assets/eip-7904/runtime_estimation/2026-01-15_2026-01-29/figs/gas_costs_by_client.png) ## Errors and caveats All parameters had a good model fit. The following operations have no estimation for the following clients: - BLAKE2F: erigon - BLS12_G1ADD: erigon - BLS12_G2ADD: erigon - ECADD: erigon - ECPAIRING: erigon - ECRECOVER: erigon - POINT_EVALUATION: erigon https://eips.ethereum.org/assets/eip-7904/runtime_estimation/2026-01-15_2026-01-29/new_gas_proposal https://eips.ethereum.org/assets/eip-7904/runtime_estimation/2026-01-15_2026-01-29/new_gas_proposal Operation run times estimation results - EIP-7904 / Operation run times estimation results - EIP-7904 ================================================= Table of contents ================= * [MULMOD](#mulmod) * [ADDMOD](#addmod) * [SMOD](#smod) * [MOD](#mod) * [SMOD](#smod) * [DIV](#div) * [SDIV](#sdiv) * [POINT_EVALUATION](#point_evaluation) * [BLS12_G1ADD](#bls12_g1add) * [BLS12_G2ADD](#bls12_g2add) * [ECADD](#ecadd) * [ECRECOVER](#ecrecover) * [KECCAK256](#keccak256) * [BLAKE2F](#blake2f) * [ECPAIRING](#ecpairing) # Introduction This is an automated report generated from the opcode run times estimation script `./src/estimate_7904_repricings.py`. The script uses data generated by running the [EEST benchmark suite](https://github.com/ethereum/execution-spec-tests/tree/main/tests/benchmark) with the [Nethermind benchmarking tooling](https://github.com/NethermindEth/gas-benchmarks). The data includes all the tests for operations repriced in EIP-7904 run between 2026-01-15 and 2026-01-29. For each operation and client, an NNLS linear regression model is fitted to estimate the operation run time as a function of the operation count and other operation-specific parameters (e.g., number of rounds for BLAKE2F, message size for KECCAK256, number of pairs for ECPAIRING). The results are presented below. # How to Interpret the Results ## Model Used **Non-Negative Least Squares (NNLS) Linear Regression** is used to estimate operation runtimes. This model ensures all coefficients are non-negative, which is physically meaningful since execution time cannot be negative. The model estimates runtime as a linear combination of: - **Constant term (intercept)**: Base overhead for executing the test, which includes setup and teardown time - **Operation count (slope)**: Number of times the operation is executed in the test. This paramater is the one that allows us to estimate the per-operation runtime. - **Operation-specific parameters**: Variables like number of rounds, message size, or number of pairs For simple operations, the model estimates: `runtime = intercept + slope × operation_count` For variable operations, the model estimates: `runtime = intercept + slope × operation_count + param1_coef × operation_count × param1 + param2_coef × operation_count × param2 + ...` ## Model Quality Metrics Each model reports two key metrics to assess the quality of the fit: **R² (R-squared / Coefficient of Determination)** - Ranges from 0 to 1 (or can be negative for very poor fits) - Measures how well the model explains the variance in the data - **Interpretation**: - R² > 0.9: Excellent fit - the model explains >90% of the variance - R² > 0.7: Good fit - the model captures most of the relationship - R² > 0.5: Acceptable fit - the model has predictive power but notable variance remains - R² < 0.5: Poor fit - the model may not be reliable **p-value** - Tests the statistical significance of each coefficient, based on a bootstrap sample estimation - **Interpretation**: - p < 0.05: Statistically significant - the parameter has a real effect on runtime - p ≥ 0.05: Not significant - the parameter's effect cannot be distinguished from random noise We also plot some diagnostic graphs for each operation and client combination to visually assess the model fit. # MULMOD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.989 Model: NNLS Adj. R-squared: 0.989 No. Observations: 320 RMSE: 36.73 Df Residuals: 318 MAE: 24.25 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 31.4231 2.9149 0.000 25.5657 37.3067 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MULMOD_reth_regression.png" alt="MULMOD_reth_regression" width="600"/> <img src="./figs/MULMOD_reth_diagnostics.png" alt="MULMOD_reth_diagnostics" width="600"/> <img src="./figs/MULMOD_reth_bootstrap.png" alt="MULMOD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 430 RMSE: 66.34 Df Residuals: 428 MAE: 42.28 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 28.6369 4.5129 0.000 20.2732 37.8599 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MULMOD_nethermind_regression.png" alt="MULMOD_nethermind_regression" width="600"/> <img src="./figs/MULMOD_nethermind_diagnostics.png" alt="MULMOD_nethermind_diagnostics" width="600"/> <img src="./figs/MULMOD_nethermind_bootstrap.png" alt="MULMOD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.990 Model: NNLS Adj. R-squared: 0.990 No. Observations: 430 RMSE: 59.81 Df Residuals: 428 MAE: 38.26 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 31.0378 3.9965 0.000 23.1553 38.7857 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MULMOD_geth_regression.png" alt="MULMOD_geth_regression" width="600"/> <img src="./figs/MULMOD_geth_diagnostics.png" alt="MULMOD_geth_diagnostics" width="600"/> <img src="./figs/MULMOD_geth_bootstrap.png" alt="MULMOD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.980 Model: NNLS Adj. R-squared: 0.980 No. Observations: 430 RMSE: 217.33 Df Residuals: 428 MAE: 156.62 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 40.8901 15.5092 0.005 13.5016 72.9058 opcount 0.0002 0.0000 0.000 0.0002 0.0002 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MULMOD_besu_regression.png" alt="MULMOD_besu_regression" width="600"/> <img src="./figs/MULMOD_besu_diagnostics.png" alt="MULMOD_besu_diagnostics" width="600"/> <img src="./figs/MULMOD_besu_bootstrap.png" alt="MULMOD_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 1.000 Model: NNLS Adj. R-squared: 1.000 No. Observations: 30 RMSE: 11.20 Df Residuals: 28 MAE: 7.82 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 27.7081 3.5287 0.000 20.3352 34.1970 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MULMOD_erigon_regression.png" alt="MULMOD_erigon_regression" width="600"/> <img src="./figs/MULMOD_erigon_diagnostics.png" alt="MULMOD_erigon_diagnostics" width="600"/> <img src="./figs/MULMOD_erigon_bootstrap.png" alt="MULMOD_erigon_bootstrap" width="600"/> # ADDMOD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.991 Model: NNLS Adj. R-squared: 0.991 No. Observations: 320 RMSE: 26.74 Df Residuals: 318 MAE: 17.69 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 32.2943 2.0437 0.000 28.3926 36.4658 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ADDMOD_reth_regression.png" alt="ADDMOD_reth_regression" width="600"/> <img src="./figs/ADDMOD_reth_diagnostics.png" alt="ADDMOD_reth_diagnostics" width="600"/> <img src="./figs/ADDMOD_reth_bootstrap.png" alt="ADDMOD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 430 RMSE: 40.36 Df Residuals: 428 MAE: 22.15 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 26.2244 3.2736 0.000 19.5882 32.3655 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ADDMOD_nethermind_regression.png" alt="ADDMOD_nethermind_regression" width="600"/> <img src="./figs/ADDMOD_nethermind_diagnostics.png" alt="ADDMOD_nethermind_diagnostics" width="600"/> <img src="./figs/ADDMOD_nethermind_bootstrap.png" alt="ADDMOD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.989 Model: NNLS Adj. R-squared: 0.989 No. Observations: 430 RMSE: 57.35 Df Residuals: 428 MAE: 36.68 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 32.5766 3.9405 0.000 25.0283 40.1535 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ADDMOD_geth_regression.png" alt="ADDMOD_geth_regression" width="600"/> <img src="./figs/ADDMOD_geth_diagnostics.png" alt="ADDMOD_geth_diagnostics" width="600"/> <img src="./figs/ADDMOD_geth_bootstrap.png" alt="ADDMOD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.980 Model: NNLS Adj. R-squared: 0.979 No. Observations: 430 RMSE: 181.34 Df Residuals: 428 MAE: 130.22 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 35.6849 13.0733 0.006 8.6600 60.3857 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ADDMOD_besu_regression.png" alt="ADDMOD_besu_regression" width="600"/> <img src="./figs/ADDMOD_besu_diagnostics.png" alt="ADDMOD_besu_diagnostics" width="600"/> <img src="./figs/ADDMOD_besu_bootstrap.png" alt="ADDMOD_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 1.000 Model: NNLS Adj. R-squared: 0.999 No. Observations: 30 RMSE: 13.39 Df Residuals: 28 MAE: 11.06 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 29.4920 3.4449 0.000 22.3475 35.8904 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ADDMOD_erigon_regression.png" alt="ADDMOD_erigon_regression" width="600"/> <img src="./figs/ADDMOD_erigon_diagnostics.png" alt="ADDMOD_erigon_diagnostics" width="600"/> <img src="./figs/ADDMOD_erigon_bootstrap.png" alt="ADDMOD_erigon_bootstrap" width="600"/> # SMOD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 320 RMSE: 13.38 Df Residuals: 318 MAE: 9.28 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 31.8194 1.2095 0.000 29.4033 34.1328 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_reth_regression.png" alt="SMOD_reth_regression" width="600"/> <img src="./figs/SMOD_reth_diagnostics.png" alt="SMOD_reth_diagnostics" width="600"/> <img src="./figs/SMOD_reth_bootstrap.png" alt="SMOD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.985 Model: NNLS Adj. R-squared: 0.985 No. Observations: 430 RMSE: 16.88 Df Residuals: 428 MAE: 11.30 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.3208 1.1754 0.000 28.1543 32.6954 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_nethermind_regression.png" alt="SMOD_nethermind_regression" width="600"/> <img src="./figs/SMOD_nethermind_diagnostics.png" alt="SMOD_nethermind_diagnostics" width="600"/> <img src="./figs/SMOD_nethermind_bootstrap.png" alt="SMOD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.958 Model: NNLS Adj. R-squared: 0.958 No. Observations: 430 RMSE: 54.31 Df Residuals: 428 MAE: 26.24 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.3730 3.1894 0.000 27.0449 39.4705 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_geth_regression.png" alt="SMOD_geth_regression" width="600"/> <img src="./figs/SMOD_geth_diagnostics.png" alt="SMOD_geth_diagnostics" width="600"/> <img src="./figs/SMOD_geth_bootstrap.png" alt="SMOD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.984 Model: NNLS Adj. R-squared: 0.984 No. Observations: 430 RMSE: 44.74 Df Residuals: 428 MAE: 31.00 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.3917 3.3060 0.000 23.9998 36.2517 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_besu_regression.png" alt="SMOD_besu_regression" width="600"/> <img src="./figs/SMOD_besu_diagnostics.png" alt="SMOD_besu_diagnostics" width="600"/> <img src="./figs/SMOD_besu_bootstrap.png" alt="SMOD_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.993 Model: NNLS Adj. R-squared: 0.992 No. Observations: 30 RMSE: 24.50 Df Residuals: 28 MAE: 11.61 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 22.2938 6.5115 0.011 5.7869 31.2411 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_erigon_regression.png" alt="SMOD_erigon_regression" width="600"/> <img src="./figs/SMOD_erigon_diagnostics.png" alt="SMOD_erigon_diagnostics" width="600"/> <img src="./figs/SMOD_erigon_bootstrap.png" alt="SMOD_erigon_bootstrap" width="600"/> # MOD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.991 Model: NNLS Adj. R-squared: 0.991 No. Observations: 320 RMSE: 31.06 Df Residuals: 318 MAE: 20.79 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 34.6663 2.5633 0.000 29.9558 39.6959 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MOD_reth_regression.png" alt="MOD_reth_regression" width="600"/> <img src="./figs/MOD_reth_diagnostics.png" alt="MOD_reth_diagnostics" width="600"/> <img src="./figs/MOD_reth_bootstrap.png" alt="MOD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.990 Model: NNLS Adj. R-squared: 0.990 No. Observations: 430 RMSE: 40.16 Df Residuals: 428 MAE: 24.83 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.1414 2.7993 0.000 24.6640 35.4751 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MOD_nethermind_regression.png" alt="MOD_nethermind_regression" width="600"/> <img src="./figs/MOD_nethermind_diagnostics.png" alt="MOD_nethermind_diagnostics" width="600"/> <img src="./figs/MOD_nethermind_bootstrap.png" alt="MOD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.985 Model: NNLS Adj. R-squared: 0.985 No. Observations: 430 RMSE: 56.92 Df Residuals: 428 MAE: 33.00 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.6655 3.9946 0.000 26.0844 42.2995 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MOD_geth_regression.png" alt="MOD_geth_regression" width="600"/> <img src="./figs/MOD_geth_diagnostics.png" alt="MOD_geth_diagnostics" width="600"/> <img src="./figs/MOD_geth_bootstrap.png" alt="MOD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.977 Model: NNLS Adj. R-squared: 0.977 No. Observations: 430 RMSE: 257.81 Df Residuals: 428 MAE: 180.30 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 42.7935 18.3770 0.013 4.6972 78.3645 opcount 0.0002 0.0000 0.000 0.0002 0.0002 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MOD_besu_regression.png" alt="MOD_besu_regression" width="600"/> <img src="./figs/MOD_besu_diagnostics.png" alt="MOD_besu_diagnostics" width="600"/> <img src="./figs/MOD_besu_bootstrap.png" alt="MOD_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.996 Model: NNLS Adj. R-squared: 0.996 No. Observations: 30 RMSE: 30.18 Df Residuals: 28 MAE: 21.90 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 39.0732 8.3577 0.000 22.2512 55.7676 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/MOD_erigon_regression.png" alt="MOD_erigon_regression" width="600"/> <img src="./figs/MOD_erigon_diagnostics.png" alt="MOD_erigon_diagnostics" width="600"/> <img src="./figs/MOD_erigon_bootstrap.png" alt="MOD_erigon_bootstrap" width="600"/> # SMOD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 320 RMSE: 13.38 Df Residuals: 318 MAE: 9.28 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 31.8194 1.2095 0.000 29.4033 34.1328 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_reth_regression.png" alt="SMOD_reth_regression" width="600"/> <img src="./figs/SMOD_reth_diagnostics.png" alt="SMOD_reth_diagnostics" width="600"/> <img src="./figs/SMOD_reth_bootstrap.png" alt="SMOD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.985 Model: NNLS Adj. R-squared: 0.985 No. Observations: 430 RMSE: 16.88 Df Residuals: 428 MAE: 11.30 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.3208 1.1754 0.000 28.1543 32.6954 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_nethermind_regression.png" alt="SMOD_nethermind_regression" width="600"/> <img src="./figs/SMOD_nethermind_diagnostics.png" alt="SMOD_nethermind_diagnostics" width="600"/> <img src="./figs/SMOD_nethermind_bootstrap.png" alt="SMOD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.958 Model: NNLS Adj. R-squared: 0.958 No. Observations: 430 RMSE: 54.31 Df Residuals: 428 MAE: 26.24 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.3730 3.1894 0.000 27.0449 39.4705 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_geth_regression.png" alt="SMOD_geth_regression" width="600"/> <img src="./figs/SMOD_geth_diagnostics.png" alt="SMOD_geth_diagnostics" width="600"/> <img src="./figs/SMOD_geth_bootstrap.png" alt="SMOD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.984 Model: NNLS Adj. R-squared: 0.984 No. Observations: 430 RMSE: 44.74 Df Residuals: 428 MAE: 31.00 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.3917 3.3060 0.000 23.9998 36.2517 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_besu_regression.png" alt="SMOD_besu_regression" width="600"/> <img src="./figs/SMOD_besu_diagnostics.png" alt="SMOD_besu_diagnostics" width="600"/> <img src="./figs/SMOD_besu_bootstrap.png" alt="SMOD_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.993 Model: NNLS Adj. R-squared: 0.992 No. Observations: 30 RMSE: 24.50 Df Residuals: 28 MAE: 11.61 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 22.2938 6.5115 0.011 5.7869 31.2411 opcount 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SMOD_erigon_regression.png" alt="SMOD_erigon_regression" width="600"/> <img src="./figs/SMOD_erigon_diagnostics.png" alt="SMOD_erigon_diagnostics" width="600"/> <img src="./figs/SMOD_erigon_bootstrap.png" alt="SMOD_erigon_bootstrap" width="600"/> # DIV ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.991 Model: NNLS Adj. R-squared: 0.991 No. Observations: 320 RMSE: 43.95 Df Residuals: 318 MAE: 27.80 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.6486 3.4720 0.000 26.8360 40.5650 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/DIV_reth_regression.png" alt="DIV_reth_regression" width="600"/> <img src="./figs/DIV_reth_diagnostics.png" alt="DIV_reth_diagnostics" width="600"/> <img src="./figs/DIV_reth_bootstrap.png" alt="DIV_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 430 RMSE: 64.73 Df Residuals: 428 MAE: 39.87 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.8596 4.4705 0.000 22.2831 39.8098 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/DIV_nethermind_regression.png" alt="DIV_nethermind_regression" width="600"/> <img src="./figs/DIV_nethermind_diagnostics.png" alt="DIV_nethermind_diagnostics" width="600"/> <img src="./figs/DIV_nethermind_bootstrap.png" alt="DIV_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 430 RMSE: 70.49 Df Residuals: 428 MAE: 44.11 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 31.4015 5.1975 0.000 21.3700 41.5393 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/DIV_geth_regression.png" alt="DIV_geth_regression" width="600"/> <img src="./figs/DIV_geth_diagnostics.png" alt="DIV_geth_diagnostics" width="600"/> <img src="./figs/DIV_geth_bootstrap.png" alt="DIV_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.969 Model: NNLS Adj. R-squared: 0.969 No. Observations: 430 RMSE: 377.34 Df Residuals: 428 MAE: 276.74 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 41.3458 25.1943 0.060 0.0000 93.7752 opcount 0.0002 0.0000 0.000 0.0002 0.0002 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/DIV_besu_regression.png" alt="DIV_besu_regression" width="600"/> <img src="./figs/DIV_besu_diagnostics.png" alt="DIV_besu_diagnostics" width="600"/> <img src="./figs/DIV_besu_bootstrap.png" alt="DIV_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 1.000 Model: NNLS Adj. R-squared: 1.000 No. Observations: 30 RMSE: 9.48 Df Residuals: 28 MAE: 7.18 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.7244 3.4691 0.000 26.9306 40.5072 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/DIV_erigon_regression.png" alt="DIV_erigon_regression" width="600"/> <img src="./figs/DIV_erigon_diagnostics.png" alt="DIV_erigon_diagnostics" width="600"/> <img src="./figs/DIV_erigon_bootstrap.png" alt="DIV_erigon_bootstrap" width="600"/> # SDIV ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.990 Model: NNLS Adj. R-squared: 0.990 No. Observations: 320 RMSE: 57.16 Df Residuals: 318 MAE: 37.61 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 31.4257 4.5085 0.000 23.0489 41.0961 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SDIV_reth_regression.png" alt="SDIV_reth_regression" width="600"/> <img src="./figs/SDIV_reth_diagnostics.png" alt="SDIV_reth_diagnostics" width="600"/> <img src="./figs/SDIV_reth_bootstrap.png" alt="SDIV_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.977 Model: NNLS Adj. R-squared: 0.977 No. Observations: 430 RMSE: 108.13 Df Residuals: 428 MAE: 70.48 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 28.3499 7.6774 0.000 11.8263 42.8811 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SDIV_nethermind_regression.png" alt="SDIV_nethermind_regression" width="600"/> <img src="./figs/SDIV_nethermind_diagnostics.png" alt="SDIV_nethermind_diagnostics" width="600"/> <img src="./figs/SDIV_nethermind_bootstrap.png" alt="SDIV_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.988 Model: NNLS Adj. R-squared: 0.988 No. Observations: 430 RMSE: 68.54 Df Residuals: 428 MAE: 42.44 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 28.0247 5.5172 0.000 17.2510 38.4472 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SDIV_geth_regression.png" alt="SDIV_geth_regression" width="600"/> <img src="./figs/SDIV_geth_diagnostics.png" alt="SDIV_geth_diagnostics" width="600"/> <img src="./figs/SDIV_geth_bootstrap.png" alt="SDIV_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.971 Model: NNLS Adj. R-squared: 0.971 No. Observations: 430 RMSE: 483.08 Df Residuals: 428 MAE: 335.85 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 26.4209 27.4641 0.233 0.0000 90.8952 opcount 0.0003 0.0000 0.000 0.0003 0.0003 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SDIV_besu_regression.png" alt="SDIV_besu_regression" width="600"/> <img src="./figs/SDIV_besu_diagnostics.png" alt="SDIV_besu_diagnostics" width="600"/> <img src="./figs/SDIV_besu_bootstrap.png" alt="SDIV_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.999 Model: NNLS Adj. R-squared: 0.999 No. Observations: 30 RMSE: 17.05 Df Residuals: 28 MAE: 12.01 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 32.0771 5.4484 0.000 23.3307 44.2564 opcount 0.0001 0.0000 0.000 0.0001 0.0001 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/SDIV_erigon_regression.png" alt="SDIV_erigon_regression" width="600"/> <img src="./figs/SDIV_erigon_diagnostics.png" alt="SDIV_erigon_diagnostics" width="600"/> <img src="./figs/SDIV_erigon_bootstrap.png" alt="SDIV_erigon_bootstrap" width="600"/> # POINT_EVALUATION ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.993 Model: NNLS Adj. R-squared: 0.993 No. Observations: 320 RMSE: 364.33 Df Residuals: 318 MAE: 250.88 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.9425 27.3986 0.126 0.0000 92.9463 opcount 1.4861 0.0074 0.000 1.4701 1.4985 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/POINT_EVALUATION_reth_regression.png" alt="POINT_EVALUATION_reth_regression" width="600"/> <img src="./figs/POINT_EVALUATION_reth_diagnostics.png" alt="POINT_EVALUATION_reth_diagnostics" width="600"/> <img src="./figs/POINT_EVALUATION_reth_bootstrap.png" alt="POINT_EVALUATION_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.992 Model: NNLS Adj. R-squared: 0.992 No. Observations: 430 RMSE: 391.02 Df Residuals: 428 MAE: 255.69 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 13.1322 19.5270 0.327 0.0000 65.9079 opcount 1.4894 0.0059 0.000 1.4750 1.4982 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/POINT_EVALUATION_nethermind_regression.png" alt="POINT_EVALUATION_nethermind_regression" width="600"/> <img src="./figs/POINT_EVALUATION_nethermind_diagnostics.png" alt="POINT_EVALUATION_nethermind_diagnostics" width="600"/> <img src="./figs/POINT_EVALUATION_nethermind_bootstrap.png" alt="POINT_EVALUATION_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.992 Model: NNLS Adj. R-squared: 0.992 No. Observations: 430 RMSE: 388.20 Df Residuals: 428 MAE: 243.56 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 40.4320 26.1932 0.060 0.0000 99.7871 opcount 1.4835 0.0071 0.000 1.4683 1.4962 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/POINT_EVALUATION_geth_regression.png" alt="POINT_EVALUATION_geth_regression" width="600"/> <img src="./figs/POINT_EVALUATION_geth_diagnostics.png" alt="POINT_EVALUATION_geth_diagnostics" width="600"/> <img src="./figs/POINT_EVALUATION_geth_bootstrap.png" alt="POINT_EVALUATION_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.991 Model: NNLS Adj. R-squared: 0.991 No. Observations: 430 RMSE: 411.40 Df Residuals: 428 MAE: 305.87 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 28.5453 24.1757 0.177 0.0000 79.9144 opcount 1.4843 0.0066 0.000 1.4710 1.4964 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/POINT_EVALUATION_besu_regression.png" alt="POINT_EVALUATION_besu_regression" width="600"/> <img src="./figs/POINT_EVALUATION_besu_diagnostics.png" alt="POINT_EVALUATION_besu_diagnostics" width="600"/> <img src="./figs/POINT_EVALUATION_besu_bootstrap.png" alt="POINT_EVALUATION_besu_bootstrap" width="600"/> ## erigon NNLS model did not run... Error: No valid data remaining after dropping NaN values # BLS12_G1ADD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.990 Model: NNLS Adj. R-squared: 0.990 No. Observations: 320 RMSE: 73.12 Df Residuals: 318 MAE: 50.37 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 32.8474 6.6176 0.000 19.9333 45.6873 opcount 0.0051 0.0000 0.000 0.0051 0.0052 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G1ADD_reth_regression.png" alt="BLS12_G1ADD_reth_regression" width="600"/> <img src="./figs/BLS12_G1ADD_reth_diagnostics.png" alt="BLS12_G1ADD_reth_diagnostics" width="600"/> <img src="./figs/BLS12_G1ADD_reth_bootstrap.png" alt="BLS12_G1ADD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 430 RMSE: 100.40 Df Residuals: 428 MAE: 63.21 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 13.5899 8.7007 0.067 0.0000 31.3154 opcount 0.0059 0.0000 0.000 0.0058 0.0060 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G1ADD_nethermind_regression.png" alt="BLS12_G1ADD_nethermind_regression" width="600"/> <img src="./figs/BLS12_G1ADD_nethermind_diagnostics.png" alt="BLS12_G1ADD_nethermind_diagnostics" width="600"/> <img src="./figs/BLS12_G1ADD_nethermind_bootstrap.png" alt="BLS12_G1ADD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.992 Model: NNLS Adj. R-squared: 0.992 No. Observations: 430 RMSE: 66.89 Df Residuals: 428 MAE: 45.46 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.3366 4.9335 0.000 23.4914 42.7542 opcount 0.0051 0.0000 0.000 0.0051 0.0052 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G1ADD_geth_regression.png" alt="BLS12_G1ADD_geth_regression" width="600"/> <img src="./figs/BLS12_G1ADD_geth_diagnostics.png" alt="BLS12_G1ADD_geth_diagnostics" width="600"/> <img src="./figs/BLS12_G1ADD_geth_bootstrap.png" alt="BLS12_G1ADD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.943 Model: NNLS Adj. R-squared: 0.943 No. Observations: 430 RMSE: 376.50 Df Residuals: 428 MAE: 282.35 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 4.7707 17.4892 0.398 0.0000 58.1477 opcount 0.0107 0.0001 0.000 0.0104 0.0109 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G1ADD_besu_regression.png" alt="BLS12_G1ADD_besu_regression" width="600"/> <img src="./figs/BLS12_G1ADD_besu_diagnostics.png" alt="BLS12_G1ADD_besu_diagnostics" width="600"/> <img src="./figs/BLS12_G1ADD_besu_bootstrap.png" alt="BLS12_G1ADD_besu_bootstrap" width="600"/> ## erigon NNLS model did not run... Error: No valid data remaining after dropping NaN values # BLS12_G2ADD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.991 Model: NNLS Adj. R-squared: 0.991 No. Observations: 320 RMSE: 60.02 Df Residuals: 318 MAE: 41.12 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 34.2802 4.9762 0.000 24.8162 44.7806 opcount 0.0074 0.0000 0.000 0.0073 0.0075 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G2ADD_reth_regression.png" alt="BLS12_G2ADD_reth_regression" width="600"/> <img src="./figs/BLS12_G2ADD_reth_diagnostics.png" alt="BLS12_G2ADD_reth_diagnostics" width="600"/> <img src="./figs/BLS12_G2ADD_reth_bootstrap.png" alt="BLS12_G2ADD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.990 Model: NNLS Adj. R-squared: 0.990 No. Observations: 430 RMSE: 79.95 Df Residuals: 428 MAE: 52.21 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 0.0000 2.1068 1.000 0.0000 7.6520 opcount 0.0092 0.0000 0.000 0.0091 0.0093 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G2ADD_nethermind_regression.png" alt="BLS12_G2ADD_nethermind_regression" width="600"/> <img src="./figs/BLS12_G2ADD_nethermind_diagnostics.png" alt="BLS12_G2ADD_nethermind_diagnostics" width="600"/> <img src="./figs/BLS12_G2ADD_nethermind_bootstrap.png" alt="BLS12_G2ADD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.992 Model: NNLS Adj. R-squared: 0.992 No. Observations: 430 RMSE: 52.54 Df Residuals: 428 MAE: 35.01 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 29.6103 3.8388 0.000 22.2773 37.6501 opcount 0.0070 0.0000 0.000 0.0069 0.0071 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G2ADD_geth_regression.png" alt="BLS12_G2ADD_geth_regression" width="600"/> <img src="./figs/BLS12_G2ADD_geth_diagnostics.png" alt="BLS12_G2ADD_geth_diagnostics" width="600"/> <img src="./figs/BLS12_G2ADD_geth_bootstrap.png" alt="BLS12_G2ADD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.958 Model: NNLS Adj. R-squared: 0.958 No. Observations: 430 RMSE: 229.33 Df Residuals: 428 MAE: 173.41 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 1.9380 11.0376 0.482 0.0000 37.3520 opcount 0.0127 0.0001 0.000 0.0125 0.0129 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLS12_G2ADD_besu_regression.png" alt="BLS12_G2ADD_besu_regression" width="600"/> <img src="./figs/BLS12_G2ADD_besu_diagnostics.png" alt="BLS12_G2ADD_besu_diagnostics" width="600"/> <img src="./figs/BLS12_G2ADD_besu_bootstrap.png" alt="BLS12_G2ADD_besu_bootstrap" width="600"/> ## erigon NNLS model did not run... Error: No valid data remaining after dropping NaN values # ECADD ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.991 Model: NNLS Adj. R-squared: 0.991 No. Observations: 320 RMSE: 104.34 Df Residuals: 318 MAE: 76.32 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 29.7112 8.6267 0.001 13.3779 46.9809 opcount 0.0038 0.0000 0.000 0.0037 0.0038 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECADD_reth_regression.png" alt="ECADD_reth_regression" width="600"/> <img src="./figs/ECADD_reth_diagnostics.png" alt="ECADD_reth_diagnostics" width="600"/> <img src="./figs/ECADD_reth_bootstrap.png" alt="ECADD_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.985 No. Observations: 430 RMSE: 84.76 Df Residuals: 428 MAE: 55.88 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 14.8697 5.7797 0.005 3.2806 26.1806 opcount 0.0024 0.0000 0.000 0.0024 0.0025 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECADD_nethermind_regression.png" alt="ECADD_nethermind_regression" width="600"/> <img src="./figs/ECADD_nethermind_diagnostics.png" alt="ECADD_nethermind_diagnostics" width="600"/> <img src="./figs/ECADD_nethermind_bootstrap.png" alt="ECADD_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.989 Model: NNLS Adj. R-squared: 0.989 No. Observations: 430 RMSE: 86.48 Df Residuals: 428 MAE: 59.62 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 21.6074 6.2813 0.000 10.0396 34.1265 opcount 0.0029 0.0000 0.000 0.0029 0.0029 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECADD_geth_regression.png" alt="ECADD_geth_regression" width="600"/> <img src="./figs/ECADD_geth_diagnostics.png" alt="ECADD_geth_diagnostics" width="600"/> <img src="./figs/ECADD_geth_bootstrap.png" alt="ECADD_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.982 Model: NNLS Adj. R-squared: 0.982 No. Observations: 430 RMSE: 204.25 Df Residuals: 428 MAE: 144.53 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 25.9624 13.9894 0.034 0.0000 53.1046 opcount 0.0052 0.0000 0.000 0.0052 0.0053 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECADD_besu_regression.png" alt="ECADD_besu_regression" width="600"/> <img src="./figs/ECADD_besu_diagnostics.png" alt="ECADD_besu_diagnostics" width="600"/> <img src="./figs/ECADD_besu_bootstrap.png" alt="ECADD_besu_bootstrap" width="600"/> ## erigon NNLS model did not run... Error: No valid data remaining after dropping NaN values # ECRECOVER ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.990 Model: NNLS Adj. R-squared: 0.990 No. Observations: 320 RMSE: 106.43 Df Residuals: 318 MAE: 69.10 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 40.5342 9.2076 0.000 23.0866 59.6352 opcount 0.0469 0.0003 0.000 0.0463 0.0475 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECRECOVER_reth_regression.png" alt="ECRECOVER_reth_regression" width="600"/> <img src="./figs/ECRECOVER_reth_diagnostics.png" alt="ECRECOVER_reth_diagnostics" width="600"/> <img src="./figs/ECRECOVER_reth_bootstrap.png" alt="ECRECOVER_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.991 Model: NNLS Adj. R-squared: 0.991 No. Observations: 430 RMSE: 98.35 Df Residuals: 428 MAE: 63.25 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.1650 6.9901 0.000 16.7049 44.6032 opcount 0.0446 0.0002 0.000 0.0441 0.0450 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECRECOVER_nethermind_regression.png" alt="ECRECOVER_nethermind_regression" width="600"/> <img src="./figs/ECRECOVER_nethermind_diagnostics.png" alt="ECRECOVER_nethermind_diagnostics" width="600"/> <img src="./figs/ECRECOVER_nethermind_bootstrap.png" alt="ECRECOVER_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.993 Model: NNLS Adj. R-squared: 0.993 No. Observations: 430 RMSE: 94.49 Df Residuals: 428 MAE: 63.08 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 36.6028 6.4618 0.000 24.6673 49.6262 opcount 0.0480 0.0002 0.000 0.0477 0.0484 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECRECOVER_geth_regression.png" alt="ECRECOVER_geth_regression" width="600"/> <img src="./figs/ECRECOVER_geth_diagnostics.png" alt="ECRECOVER_geth_diagnostics" width="600"/> <img src="./figs/ECRECOVER_geth_bootstrap.png" alt="ECRECOVER_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.985 Model: NNLS Adj. R-squared: 0.985 No. Observations: 430 RMSE: 135.74 Df Residuals: 428 MAE: 91.87 Df Model: 1 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 29.7974 9.8595 0.001 11.3764 49.1138 opcount 0.0484 0.0003 0.000 0.0478 0.0490 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECRECOVER_besu_regression.png" alt="ECRECOVER_besu_regression" width="600"/> <img src="./figs/ECRECOVER_besu_diagnostics.png" alt="ECRECOVER_besu_diagnostics" width="600"/> <img src="./figs/ECRECOVER_besu_bootstrap.png" alt="ECRECOVER_besu_bootstrap" width="600"/> ## erigon NNLS model did not run... Error: No valid data remaining after dropping NaN values # KECCAK256 ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.993 Model: NNLS Adj. R-squared: 0.993 No. Observations: 5120 RMSE: 59.67 Df Residuals: 5117 MAE: 39.23 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 30.8731 1.1967 0.000 28.6487 33.2196 opcount 0.0000 0.0000 0.000 0.0000 0.0000 msg_size 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/KECCAK256_reth_regression.png" alt="KECCAK256_reth_regression" width="600"/> <img src="./figs/KECCAK256_reth_diagnostics.png" alt="KECCAK256_reth_diagnostics" width="600"/> <img src="./figs/KECCAK256_reth_bootstrap.png" alt="KECCAK256_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.985 Model: NNLS Adj. R-squared: 0.985 No. Observations: 6880 RMSE: 98.77 Df Residuals: 6877 MAE: 77.41 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 27.1124 1.7795 0.000 23.5517 30.5938 opcount 0.0000 0.0000 0.000 0.0000 0.0000 msg_size 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/KECCAK256_nethermind_regression.png" alt="KECCAK256_nethermind_regression" width="600"/> <img src="./figs/KECCAK256_nethermind_diagnostics.png" alt="KECCAK256_nethermind_diagnostics" width="600"/> <img src="./figs/KECCAK256_nethermind_bootstrap.png" alt="KECCAK256_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.925 Model: NNLS Adj. R-squared: 0.925 No. Observations: 6880 RMSE: 239.33 Df Residuals: 6877 MAE: 168.50 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 7.8135 4.3612 0.044 0.0000 16.3268 opcount 0.0005 0.0000 0.000 0.0005 0.0005 msg_size 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/KECCAK256_geth_regression.png" alt="KECCAK256_geth_regression" width="600"/> <img src="./figs/KECCAK256_geth_diagnostics.png" alt="KECCAK256_geth_diagnostics" width="600"/> <img src="./figs/KECCAK256_geth_bootstrap.png" alt="KECCAK256_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.955 Model: NNLS Adj. R-squared: 0.955 No. Observations: 6880 RMSE: 263.59 Df Residuals: 6877 MAE: 198.95 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 5.8207 4.2703 0.096 0.0000 14.6842 opcount 0.0007 0.0000 0.000 0.0007 0.0007 msg_size 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/KECCAK256_besu_regression.png" alt="KECCAK256_besu_regression" width="600"/> <img src="./figs/KECCAK256_besu_diagnostics.png" alt="KECCAK256_besu_diagnostics" width="600"/> <img src="./figs/KECCAK256_besu_bootstrap.png" alt="KECCAK256_besu_bootstrap" width="600"/> ## erigon ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.947 Model: NNLS Adj. R-squared: 0.947 No. Observations: 480 RMSE: 189.92 Df Residuals: 477 MAE: 154.33 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 11.2532 10.4939 0.175 0.0000 35.1932 opcount 0.0004 0.0000 0.000 0.0004 0.0005 msg_size 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/KECCAK256_erigon_regression.png" alt="KECCAK256_erigon_regression" width="600"/> <img src="./figs/KECCAK256_erigon_diagnostics.png" alt="KECCAK256_erigon_diagnostics" width="600"/> <img src="./figs/KECCAK256_erigon_bootstrap.png" alt="KECCAK256_erigon_bootstrap" width="600"/> # BLAKE2F ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.952 Model: NNLS Adj. R-squared: 0.952 No. Observations: 1280 RMSE: 115.39 Df Residuals: 1277 MAE: 92.63 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 14.8301 4.6685 0.001 5.5662 24.3891 opcount 0.0006 0.0000 0.000 0.0006 0.0006 num_rounds 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLAKE2F_reth_regression.png" alt="BLAKE2F_reth_regression" width="600"/> <img src="./figs/BLAKE2F_reth_diagnostics.png" alt="BLAKE2F_reth_diagnostics" width="600"/> <img src="./figs/BLAKE2F_reth_bootstrap.png" alt="BLAKE2F_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.977 Model: NNLS Adj. R-squared: 0.977 No. Observations: 1720 RMSE: 77.08 Df Residuals: 1717 MAE: 54.97 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 0.0000 0.0000 1.000 0.0000 0.0000 opcount 0.0007 0.0000 0.000 0.0007 0.0007 num_rounds 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLAKE2F_nethermind_regression.png" alt="BLAKE2F_nethermind_regression" width="600"/> <img src="./figs/BLAKE2F_nethermind_diagnostics.png" alt="BLAKE2F_nethermind_diagnostics" width="600"/> <img src="./figs/BLAKE2F_nethermind_bootstrap.png" alt="BLAKE2F_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.988 Model: NNLS Adj. R-squared: 0.988 No. Observations: 1720 RMSE: 56.02 Df Residuals: 1717 MAE: 41.08 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 17.6718 1.9910 0.000 13.6075 21.6085 opcount 0.0007 0.0000 0.000 0.0007 0.0007 num_rounds 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLAKE2F_geth_regression.png" alt="BLAKE2F_geth_regression" width="600"/> <img src="./figs/BLAKE2F_geth_diagnostics.png" alt="BLAKE2F_geth_diagnostics" width="600"/> <img src="./figs/BLAKE2F_geth_bootstrap.png" alt="BLAKE2F_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.975 Model: NNLS Adj. R-squared: 0.975 No. Observations: 1720 RMSE: 277.67 Df Residuals: 1717 MAE: 196.53 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 62.5567 10.3996 0.000 42.2762 82.6965 opcount 0.0028 0.0000 0.000 0.0028 0.0028 num_rounds 0.0000 0.0000 0.000 0.0000 0.0000 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/BLAKE2F_besu_regression.png" alt="BLAKE2F_besu_regression" width="600"/> <img src="./figs/BLAKE2F_besu_diagnostics.png" alt="BLAKE2F_besu_diagnostics" width="600"/> <img src="./figs/BLAKE2F_besu_bootstrap.png" alt="BLAKE2F_besu_bootstrap" width="600"/> ## erigon NNLS model did not run... Error: No valid data remaining after dropping NaN values # ECPAIRING ## reth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.988 Model: NNLS Adj. R-squared: 0.988 No. Observations: 1432 RMSE: 93.51 Df Residuals: 1429 MAE: 50.85 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 34.1944 3.4072 0.000 27.9524 41.3956 opcount 0.5785 0.0055 0.000 0.5678 0.5895 num_pairs 0.4691 0.0016 0.000 0.4658 0.4721 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECPAIRING_reth_regression.png" alt="ECPAIRING_reth_regression" width="600"/> <img src="./figs/ECPAIRING_reth_diagnostics.png" alt="ECPAIRING_reth_diagnostics" width="600"/> <img src="./figs/ECPAIRING_reth_bootstrap.png" alt="ECPAIRING_reth_bootstrap" width="600"/> ## nethermind ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.990 Model: NNLS Adj. R-squared: 0.990 No. Observations: 1982 RMSE: 96.86 Df Residuals: 1979 MAE: 56.12 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 33.2452 3.2925 0.000 26.9497 39.7779 opcount 0.3005 0.0043 0.000 0.2925 0.3093 num_pairs 0.5684 0.0016 0.000 0.5651 0.5714 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECPAIRING_nethermind_regression.png" alt="ECPAIRING_nethermind_regression" width="600"/> <img src="./figs/ECPAIRING_nethermind_diagnostics.png" alt="ECPAIRING_nethermind_diagnostics" width="600"/> <img src="./figs/ECPAIRING_nethermind_bootstrap.png" alt="ECPAIRING_nethermind_bootstrap" width="600"/> ## geth ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.989 Model: NNLS Adj. R-squared: 0.989 No. Observations: 1982 RMSE: 41.44 Df Residuals: 1979 MAE: 21.09 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 35.2135 1.3674 0.000 32.7371 38.0138 opcount 0.3013 0.0022 0.000 0.2973 0.3058 num_pairs 0.2147 0.0006 0.000 0.2135 0.2159 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECPAIRING_geth_regression.png" alt="ECPAIRING_geth_regression" width="600"/> <img src="./figs/ECPAIRING_geth_diagnostics.png" alt="ECPAIRING_geth_diagnostics" width="600"/> <img src="./figs/ECPAIRING_geth_bootstrap.png" alt="ECPAIRING_geth_bootstrap" width="600"/> ## besu ```python ============================================================================== NNLS Regression Results ============================================================================== Dep. Variable: run_duration_ms R-squared: 0.986 Model: NNLS Adj. R-squared: 0.986 No. Observations: 1982 RMSE: 46.00 Df Residuals: 1979 MAE: 27.86 Df Model: 2 ============================================================================== coef std err P-value [0.025 0.975] ------------------------------------------------------------------------------ const 31.3547 1.5207 0.000 28.2816 34.4007 opcount 0.3031 0.0024 0.000 0.2986 0.3077 num_pairs 0.2107 0.0007 0.000 0.2093 0.2121 ============================================================================== Notes: Non-negative least squares with bootstrap inference (1000 iterations) ============================================================================== ``` <img src="./figs/ECPAIRING_besu_regression.png" alt="ECPAIRING_besu_regression" width="600"/> <img src="./figs/ECPAIRING_besu_diagnostics.png" alt="ECPAIRING_besu_diagnostics" width="600"/> <img src="./figs/ECPAIRING_besu_bootstrap.png" alt="ECPAIRING_besu_bootstrap" width="600"/> ## erigon NNLS model did not run... Error: No valid data remaining after dropping NaN values https://eips.ethereum.org/assets/eip-7904/runtime_estimation/2026-01-15_2026-01-29/runtime_estimation_autogenerated_report https://eips.ethereum.org/assets/eip-7904/runtime_estimation/2026-01-15_2026-01-29/runtime_estimation_autogenerated_report Block Access List (BAL) Size Analysis / # Block Access List (BAL) Size Analysis > Analysis done with the BAL version https://github.com/ethereum/EIPs/blob/5cff3c4c11d2e06a269ade5b9ca005bb674f6b5f/EIPS/eip-7928.md ## Executive Summary This report presents an empirical analysis of Block Access List (BAL) sizes across 100 historical Ethereum blocks. The analysis examines BAL encoding efficiency using SSZ format and compares configurations with and without storage read tracking. ## Methodology - **Sample Size**: 100 blocks from the Ethereum mainnet - **Block Range**: Blocks 22615032 to 22616022 (sampled every 10 blocks) - **Encoding Format**: SSZ - **Compression**: Snappy compression - **Configurations**: Analysis performed both with and without storage read tracking ## Key Findings ### 1. Overall BAL Sizes #### Configuration: With Storage Reads - **Raw Size**: 91.3 KB average (25.1 - 164.8 KB range) - **Compressed Size**: 42.7 KB average (11.7 - 78.7 KB range) - **Compression Ratio**: 2.1x #### Configuration: Without Storage Reads - **Raw Size**: 63.6 KB average (17.4 - 117.3 KB range) - **Compressed Size**: 29.3 KB average (7.9 - 56.2 KB range) - **Compression Ratio**: 2.2x #### Impact of Storage Reads - **Size Increase**: 45.6% when including storage reads - **Absolute Difference**: 13.4 KB average increase ### 2. Component Breakdown Average compressed sizes by component type (with storage reads): - **Storage Writes**: 23.0 KB (54.0% of total) - **Storage Reads**: 13.4 KB (31.3% of total) - **Balance Changes**: 5.8 KB (13.6% of total) - **Code Deployments**: 0.5 KB (1.1% of total) - **Nonce Updates**: 0.0 KB (0.0% of total) ### 3. Block Activity Metrics Average per block: - **Transactions**: 183.4 (min: 54, max: 365) - **Unique Accounts**: 407.0 - **Storage Writes**: 583.2 - **Storage Reads**: 818.2 ### 4. Size Distribution Compressed BAL size percentiles (with reads): - **P10**: 21.7 KB - **P25**: 28.9 KB - **P50**: 42.6 KB (median) - **P75**: 54.6 KB - **P90**: 64.7 KB - **P95**: 73.7 KB - **P99**: 78.7 KB ### 5. Correlation Analysis - **Size vs Transactions**: Pearson correlation = 0.876 - **Size vs Storage Writes**: Pearson correlation = 0.973 - **Size vs Unique Accounts**: Pearson correlation = 0.956 ## Technical Details ### BAL Structure The Block Access List uses an account-centric design with hierarchical organization: ``` BlockAccessList └── AccountChanges[] ├── address: Address (20 bytes) ├── storage_changes: SlotChanges[] │ ├── slot: StorageKey (32 bytes) │ └── changes: StorageChange[] │ ├── tx_index: uint16 │ └── new_value: StorageValue (32 bytes) ├── storage_reads: SlotRead[] │ └── slot: StorageKey (32 bytes) ├── balance_changes: BalanceChange[] │ ├── tx_index: uint16 │ └── post_balance: Balance (12 bytes) ├── nonce_changes: NonceChange[] │ ├── tx_index: uint16 │ └── new_nonce: uint64 └── code_changes: CodeChange[] ├── tx_index: uint16 └── new_code: CodeData (variable) ``` ### Encoding Efficiency Features 1. **Address Deduplication**: Each address appears only once, regardless of how many changes it has 2. **Slot Deduplication**: Each storage slot appears only once per account 3. **Transaction Indexing**: Uses uint16 (2 bytes) instead of full transaction hashes 4. **Optimized Field Sizes**: - Balance: 12 bytes (sufficient for total ETH supply) - Transaction index: 2 bytes (supports up to 65,535 transactions) - Address: 20 bytes (standard Ethereum address) ## Key Insights 1. **Storage Operations Dominate**: Storage changes and reads account for 85.3% of the total BAL size, making storage optimization critical. 2. **Read Tracking Cost**: Including storage reads adds approximately 13.4 KB per block on average, a 45.6% increase. 3. **Scalability**: The median block (178 transactions) produces a 42.6 KB compressed BAL, while the 95th percentile block (286 transactions) produces 73.7 KB. 4. **Network Impact**: At current block production rates (12 seconds), BALs would add approximately 300.2 MB/day to node bandwidth requirements. ## Conclusions The SSZ-encoded Block Access List provides an efficient method for recording state access patterns: - **Typical blocks** (25th-75th percentile) generate compressed BALs of 28.9-54.6 KB - **Large blocks** (95th percentile) remain under 73.7 KB compressed - **Compression effectiveness** of 2.1x makes network transmission practical - **Read tracking overhead** of 45.6% is still considered acceptable for the benefits provided, but might be removed in the future. https://eips.ethereum.org/assets/eip-7928/bal_size_analysis https://eips.ethereum.org/assets/eip-7928/bal_size_analysis EIP-7928 Component Size &amp; Compression Analysis - 1000 Blocks / # EIP-7928 Component Size & Compression Analysis - 1000 Blocks ## Dataset - **Blocks Analyzed**: 1000 blocks (23,991,474 to 23,992,473) - **Encoding**: RLP format - **Compression**: Snappy algorithm ## Per-Block Component Statistics (KiB) | Component | Avg Raw | Median Raw | Avg Compressed | Median Compressed | Avg Ratio | Median Ratio | |-----------|---------|------------|----------------|-------------------|-----------|-------------- | Storage Writes | 52.6 | 49.6 | 29.2 | 28.0 | 1.79x | 1.78x | | Storage Reads | 31.7 | 29.7 | 18.7 | 17.5 | 1.71x | 1.71x | | Balance Changes | 6.8 | 6.6 | 6.7 | 6.5 | 1.02x | 1.00x | | Nonce Changes | 1.1 | 1.0 | 1.1 | 1.0 | 0.99x | 1.00x | | Code Changes | 2.1 | 0.2 | 1.2 | 0.2 | 1.37x | 1.16x | | Account Addresses (w/ Changes) | 8.1 | 8.0 | 7.7 | 7.6 | 1.05x | 1.05x | | Touched-Only Addresses | 3.6 | 3.6 | 3.5 | 3.4 | 1.03x | 1.06x | | RLP Encoding Overhead | 4.6 | 4.5 | 4.4 | 4.3 | 1.05x | 1.05x | | **Full BAL** | **110.8** | **106.0** | **72.4** | **70.5** | **1.52x** | **1.52x** | ## Component Size Distribution (KiB) | Component | Min Raw | Max Raw | Std Dev Raw | Min Compressed | Max Compressed | Std Dev Compressed | |-----------|---------|---------|-------------|----------------|----------------|-------------------| | Storage Writes | 4.5 | 197.0 | 23.7 | 2.8 | 113.8 | 12.8 | | Storage Reads | 1.2 | 105.7 | 15.0 | 0.9 | 88.9 | 9.2 | | Balance Changes | 0.7 | 22.4 | 2.8 | 0.7 | 22.4 | 2.7 | | Nonce Changes | 0.1 | 4.4 | 0.5 | 0.1 | 4.5 | 0.5 | | Code Changes | 0.0 | 72.6 | 5.6 | 0.0 | 25.3 | 2.9 | | Account Addresses (w/ Changes) | 1.9 | 29.5 | 3.2 | 1.8 | 28.1 | 3.0 | | Touched-Only Addresses | 0.8 | 12.6 | 1.4 | 0.8 | 12.2 | 1.3 | | RLP Encoding Overhead | 1.2 | 16.8 | 2.1 | 1.1 | 16.2 | 2.0 | | **Full BAL** | **10.9** | **301.9** | **45.5** | **8.6** | **191.4** | **28.8** | ## Compression Ratio Distribution | Component | Min Ratio | Max Ratio | Std Dev | 25th Percentile | 75th Percentile | |-----------|-----------|-----------|---------|-----------------|----------------- | Storage Writes | 1.54x | 2.86x | 0.12x | 1.74x | 1.83x | | Storage Reads | 1.07x | 2.33x | 0.16x | 1.61x | 1.81x | | Balance Changes | 1.00x | 1.50x | 0.04x | 1.00x | 1.03x | | Nonce Changes | 0.97x | 1.07x | 0.00x | 0.99x | 1.00x | | Code Changes | 0.93x | 8.67x | 0.65x | 0.99x | 1.56x | | Account Addresses (w/ Changes) | 1.02x | 1.08x | 0.02x | 1.04x | 1.06x | | Touched-Only Addresses | 1.00x | 1.10x | 0.03x | 1.02x | 1.05x | | RLP Encoding Overhead | 1.02x | 1.12x | 0.03x | 1.03x | 1.07x | | **Full BAL** | **1.19x** | **1.98x** | **0.09x** | **1.47x** | **1.56x** | ## Block Activity Metrics (per block) | Metric | Average | Median | Min | Max | |--------|---------|--------|-----|-----| | Total Accounts | 603 | 600 | 98 | 1474 | | Storage Writes Count | 700 | 667 | 65 | 2521 | | Storage Reads Count | 982 | 922 | 36 | 3279 | | Balance Changes Count | 612 | 598 | 62 | 1812 | | Nonce Changes Count | 229 | 224 | 18 | 770 | ## Component Percentage of Full BAL | Component | % of Raw Size | % of Compressed Size | |-----------|---------------|---------------------| | Storage Writes | 47.5% | 40.3% | | Storage Reads | 28.6% | 25.8% | | Balance Changes | 6.2% | 9.2% | | Nonce Changes | 1.0% | 1.5% | | Code Changes | 1.9% | 1.6% | | Account Addresses (w/ Changes) | 7.3% | 10.7% | | Touched-Only Addresses | 3.3% | 4.8% | | RLP Encoding Overhead | 4.1% | 6.1% | ## BAL vs Block Size Comparison Comparison using compressed block average of **71.71 KiB**: | Metric | BAL Size (KiB) | Block Size (KiB) | Ratio (BAL/Block) | Size Difference | |--------|---------------|------------------|-------------------|------------------| | **Full BAL (with reads)** | 72.4 | 71.7 | 1.01x | +0.7 KiB | | **BAL without reads** | 49.4 | 71.7 | 0.69x | -22.3 KiB | - Full BAL **with reads** is 1.01x the size of a compressed block - BAL **without reads** is 0.69x the size of a compressed block - Storage reads add **23.0 KiB** (46.6%) to BAL size - BAL overhead vs blocks: **+1.0%** (with reads), **-31.1%** (without reads) ## Storage Reads Impact Analysis - **WITH reads** (Full BAL): 72.4 KiB compressed - **WITHOUT reads**: 49.4 KiB compressed - **Storage reads overhead**: 23.0 KiB (46.6%) ## Summary 1. **Component dominance**: Storage writes are 47.5% of raw BAL size 2. **Account addressing**: Accounts with changes (10.7%) vs touched-only (4.8%) 3. **Pure RLP overhead**: Encoding structure accounts for 6.1% of compressed size 4. **Compression efficiency**: Overall 1.52x compression ratio 5. **Size variability**: BAL sizes vary from 8.6 to 191.4 KiB compressed 6. **Block size ratio**: Full BALs are 1.01x compressed block size https://eips.ethereum.org/assets/eip-7928/bal_size_analysis_60m https://eips.ethereum.org/assets/eip-7928/bal_size_analysis_60m EIP-7976 Empirical Report (64/64 Pricing at the Floor) / # EIP-7976 Empirical Report (64/64 Pricing at the Floor) *The following represents a summary with empirical findings from analyzing EIP-7976's impact on transactions.* *Date: January, 2026* ## Dataset - **Period**: 150 days of Ethereum mainnet data (August 2025 - January 2026) - **Blocks analyzed**: 1,080,000 blocks - **Total transactions**: 245,624,335 ## Overall Impact Metrics ### Transaction Impact Summary | Metric | Value | |--------|-------| | Total unaffected transactions | 240,588,721 (97.95%) | | Total affected transactions | 5,035,614 (2.05%) | | Transactions already affected by EIP-7623 | 2,093,004 (0.85%) | | New transactions affected by EIP-7976 only | 2,942,610 (1.20%) | | EIP-7623 overlap percentage | 41.6% | ### Address Distribution | Metric | Value | |--------|-------| | Unique affected senders | 636,577 | | Unique affected recipients | 521,874 | | Avg transactions per affected sender | 7.91 | | Avg transactions per affected recipient | 9.65 | ## Gas Usage Analysis (Affected Transactions) ### Basic Gas Metrics | Metric | Value | |--------|-------| | Mean gas used | 140,959 | | Median gas used | 38,031 | | Average calldata bytes | 3,460 | | Average zero bytes | 1,883 | | Average non-zero bytes | 1,577 | ## Most Affected Senders ### Top 30 Senders by Additional Cost Impact | Rank | Address | Transactions | Total Cost Increase (gas) | Avg Cost/Tx | Etherscan Link | |------|---------|--------------|---------------------------|-------------|----------------| | 1 | 0x54b839d988c9e712cd36cbf7c95dedc2b9f9ae6c | 44,296 | 100,215,386,242 | 2,262,402 | [View](https://etherscan.io/address/0x54b839d988c9e712cd36cbf7c95dedc2b9f9ae6c) | | 2 | 0xcbe6fbf5e3c427013688e04d0fde56705890c4be | 27,031 | 93,199,568,422 | 3,447,877 | [View](https://etherscan.io/address/0xcbe6fbf5e3c427013688e04d0fde56705890c4be) | | 3 | 0xe08cdadd44440e32ef153956a7ec40804a32dd74 | 3,360 | 24,782,661,408 | 7,375,792 | [View](https://etherscan.io/address/0xe08cdadd44440e32ef153956a7ec40804a32dd74) | | 4 | 0xc17ea94008d5a8ee86f120e092cd35a679166416 | 59,548 | 12,647,040,432 | 212,383 | [View](https://etherscan.io/address/0xc17ea94008d5a8ee86f120e092cd35a679166416) | | 5 | 0x148ee7daf16574cd020afa34cc658f8f3fbd2800 | 4,409 | 11,475,576,948 | 2,602,761 | [View](https://etherscan.io/address/0x148ee7daf16574cd020afa34cc658f8f3fbd2800) | | 6 | 0x16f09b37b20bfbb07130bba8226299926e39b488 | 14,598 | 9,858,634,629 | 675,341 | [View](https://etherscan.io/address/0x16f09b37b20bfbb07130bba8226299926e39b488) | | 7 | 0x6860c4ee678d847ae67771f2e5eea96ccb7fdf8d | 81,588 | 8,129,909,932 | 99,645 | [View](https://etherscan.io/address/0x6860c4ee678d847ae67771f2e5eea96ccb7fdf8d) | | 8 | 0xf4ceb19b2467ef784b5e83b863418c50997b1646 | 18,119 | 7,588,481,162 | 418,813 | [View](https://etherscan.io/address/0xf4ceb19b2467ef784b5e83b863418c50997b1646) | | 9 | 0x646c4fbdf82b5766c5eaf1fab9a8927fb5992d38 | 118,451 | 7,384,356,334 | 62,341 | [View](https://etherscan.io/address/0x646c4fbdf82b5766c5eaf1fab9a8927fb5992d38) | | 10 | 0x0373b1ed3b9e601bb8b17afde70b0ccab76a981d | 158,514 | 7,277,663,018 | 45,911 | [View](https://etherscan.io/address/0x0373b1ed3b9e601bb8b17afde70b0ccab76a981d) | | 11 | 0xe2da046340e00264c4f0443243a0565007ae08ac | 3,944 | 5,940,541,350 | 1,506,222 | [View](https://etherscan.io/address/0xe2da046340e00264c4f0443243a0565007ae08ac) | | 12 | 0xa7ec2be4ed79ef315b4301aeca424a2dfdeaf09a | 65,856 | 5,616,659,491 | 85,286 | [View](https://etherscan.io/address/0xa7ec2be4ed79ef315b4301aeca424a2dfdeaf09a) | | 13 | 0x7835fb36a8143a014a2c381363cd1a4dee586d2a | 2,887 | 5,601,056,603 | 1,940,095 | [View](https://etherscan.io/address/0x7835fb36a8143a014a2c381363cd1a4dee586d2a) | | 14 | 0xf2099c4783921f44ac988b67e743daefd4a00efd | 1,436 | 4,201,896,151 | 2,926,111 | [View](https://etherscan.io/address/0xf2099c4783921f44ac988b67e743daefd4a00efd) | | 15 | 0x7804405f18e134c3c47d71ae02eb454d25722d88 | 678 | 4,153,379,856 | 6,125,928 | [View](https://etherscan.io/address/0x7804405f18e134c3c47d71ae02eb454d25722d88) | | 16 | 0xfe9dcec48761d2826e3e3d95597462dfb281db79 | 48,221 | 4,047,228,659 | 83,930 | [View](https://etherscan.io/address/0xfe9dcec48761d2826e3e3d95597462dfb281db79) | | 17 | 0x1346d9c6315f6c23fe280b49ef215aebd49338b2 | 6,211 | 3,673,122,501 | 591,389 | [View](https://etherscan.io/address/0x1346d9c6315f6c23fe280b49ef215aebd49338b2) | | 18 | 0x5f62d006c10c009ff50c878cd6157ac861c99990 | 7,952 | 3,655,219,300 | 459,660 | [View](https://etherscan.io/address/0x5f62d006c10c009ff50c878cd6157ac861c99990) | | 19 | 0x3f773dc3ccc70b3d2a549713ac8d556af949d4e8 | 1,323 | 3,653,595,781 | 2,761,599 | [View](https://etherscan.io/address/0x3f773dc3ccc70b3d2a549713ac8d556af949d4e8) | | 20 | 0xc8a5849a02ad01b572a0108aebf5a0d27777a552 | 63,707 | 3,484,943,560 | 54,702 | [View](https://etherscan.io/address/0xc8a5849a02ad01b572a0108aebf5a0d27777a552) | | 21 | 0x30c2f77eaa93aace5e56ea4dcba5f21f794b58be | 687 | 3,326,641,119 | 4,842,272 | [View](https://etherscan.io/address/0x30c2f77eaa93aace5e56ea4dcba5f21f794b58be) | | 22 | 0xcbeb5d484b54498d3893a0c3eb790331962e9e9d | 7,602 | 2,716,498,081 | 357,339 | [View](https://etherscan.io/address/0xcbeb5d484b54498d3893a0c3eb790331962e9e9d) | | 23 | 0xd312535f0104a45ebd16cd29756fe9e6f8fe633c | 42,892 | 2,461,082,112 | 57,378 | [View](https://etherscan.io/address/0xd312535f0104a45ebd16cd29756fe9e6f8fe633c) | | 24 | 0xb947d63b578fb48233de4076407dd0498dcf36ab | 584 | 2,431,099,134 | 4,162,840 | [View](https://etherscan.io/address/0xb947d63b578fb48233de4076407dd0498dcf36ab) | | 25 | 0x1c9a7a489f62a75e276d3790ba92aaf12af13469 | 6,923 | 2,145,392,271 | 309,893 | [View](https://etherscan.io/address/0x1c9a7a489f62a75e276d3790ba92aaf12af13469) | | 26 | 0xf3d021d51a725f5dbdce253248e826a8644be3c1 | 3,693 | 2,063,909,478 | 558,870 | [View](https://etherscan.io/address/0xf3d021d51a725f5dbdce253248e826a8644be3c1) | | 27 | 0x2b4820042fe6a5b8ab01b29ede19203181d625fa | 18,285 | 1,880,349,910 | 102,835 | [View](https://etherscan.io/address/0x2b4820042fe6a5b8ab01b29ede19203181d625fa) | | 28 | 0xf6309d5a91fa559cbf8f6ff3c5ec8fb67fe38577 | 628 | 1,830,917,976 | 2,915,474 | [View](https://etherscan.io/address/0xf6309d5a91fa559cbf8f6ff3c5ec8fb67fe38577) | | 29 | 0x000cb000e880a92a8f383d69da2142a969b93de7 | 5,223 | 1,787,396,594 | 342,216 | [View](https://etherscan.io/address/0x000cb000e880a92a8f383d69da2142a969b93de7) | | 30 | 0x785cd82bb016c740d41ca9e0b1bacc3a2439dc0d | 23,798 | 1,666,264,939 | 70,017 | [View](https://etherscan.io/address/0x785cd82bb016c740d41ca9e0b1bacc3a2439dc0d) | ### Key Observations - **Top single address** (0x54b839d988c9e712cd36cbf7c95dedc2b9f9ae6c) accounts for 19.6% of all additional costs with 44,296 transactions - **Highest volume address** (0x0373b1ed3b9e601bb8b17afde70b0ccab76a981d) has 158,514 affected transactions but only 45,911 gas average increase per transaction - **Highest per-transaction impact** (0xe08cdadd44440e32ef153956a7ec40804a32dd74) shows 7.4M gas average increase per transaction ### Cost Impact | Metric | Value | |--------|-------| | Mean cost increase per transaction | 101,489.08 gas units | | Median cost increase per transaction | 11,444 gas units | ## Address Concentration Analysis ### Transaction Distribution | Address Group | Count | Percentage | |---------------|-------|------------| | 1 affected transaction | 388,216 | 60.98% | | ≤10 affected transactions | 611,619 | 96.08% | | ≤50 affected transactions | 632,916 | 99.43% | | ≤100 affected transactions | 634,730 | 99.71% | | ≤200 affected transactions | 635,491 | 99.83% | | ≤400 affected transactions | 635,926 | 99.90% | ### Transaction Volume Concentration | Top Addresses | % of Affected Transactions | |---------------|---------------------------| | Top 10 | 26.79% | | Top 20 | 33.47% | | Top 30 | 37.17% | | Top 40 | 39.70% | | Top 50 | 41.76% | ### Transaction Volume by Percentiles | Address Percentile | % of Affected Transactions | |-------------------|---------------------------| | Top 10% | 47.70% | | Top 20% | 54.00% | | Top 30% | 56.74% | | Top 40% | 58.57% | | Top 50% | 59.92% | ### Cost Impact Concentration | Top Addresses | % of Additional Costs | |---------------|----------------------| | Top 10 | 55.28% | | Top 20 | 63.90% | | Top 30 | 68.26% | | Top 40 | 71.15% | | Top 50 | 73.64% | ### Cost Impact by Percentiles | Address Percentile | % of Additional Costs | |-------------------|----------------------| | Top 1% | 91.44% | | Top 10% | 97.31% | | Top 20% | 98.75% | | Top 30% | 99.40% | | Top 40% | 99.72% | | Top 50% | 99.87% | ## Method Analysis ### Top 20 Affected Function Selectors | Rank | Function Selector | Transactions | Total Cost Increase | Avg Cost/Tx | Method Name | |------|------------------|--------------|---------------------|-------------|-------------| | 1 | 0x5578ceae | 28,355 | 94,835,044,230 | 3,343,786 | registerContinuousMemoryPage(...) | | 2 | 0x538f9406 | 27,826 | 93,972,171,674 | 3,377,149 | updateState(uint256[],uint256[]) | | 3 | 0x87201b41 | 70,794 | 26,600,051,568 | 375,772 | fulfillAvailableAdvancedOrders(...) | | 4 | 0x5e10b3f0 | 379,355 | 22,244,424,770 | 58,646 | workMyDirefulOwner(uint256,uint256) | | 5 | 0xfd9f1e10 | 191,576 | 18,205,559,712 | 95,012 | cancel(...) | | 6 | 0xf074ba62 | 3,827 | 9,634,717,355 | 2,517,565 | verifyCheckpointProofs(...) | | 7 | 0x09c5eabe | 42,105 | 8,765,393,130 | 208,186 | execute(bytes) | | 8 | 0x6fadcf72 | 72,208 | 5,516,170,528 | 76,366 | forward(address,bytes) | | 9 | 0xe85a6a28 | 16,654 | 4,985,983,858 | 299,377 | verifyFRI(...) | | 10 | 0x415e2848 | 74,876 | 3,076,701,516 | 41,091 | swap_6269342730() | | 11 | 0x3fe317a6 | 7,137 | 2,743,013,450 | 384,350 | verifyMerkle(...) | | 12 | 0x55944a42 | 35,064 | 2,610,534,480 | 74,445 | matchAdvancedOrders(...) | | 13 | 0x82ad56cb | 19,638 | 2,582,341,458 | 131,491 | aggregate3((address,bool,bytes)[]) | | 14 | 0xe7acab24 | 25,484 | 2,080,247,964 | 81,621 | fulfillAdvancedOrder(...) | | 15 | 0x13d79a0b | 21,713 | 1,555,462,876 | 71,652 | settleOrders(bytes) | | 16 | 0xbb2f45e1 | 4,214 | 1,061,775,096 | 251,964 | submitV1(...) | | 17 | 0x64971c46 | 13,972 | 1,002,671,000 | 71,750 | swap(...) | | 18 | 0x4c2c47bd | 630 | 931,755,480 | 1,478,976 | bulkRegisterValidator(...) | ### Key Methods by Category #### Zero-Knowledge Proof Systems - **registerContinuousMemoryPage**: 28,355 txs, avg 3,343,786 gas increase - **updateState**: 27,826 txs, avg 3,377,149 gas increase - **verifyCheckpointProofs**: 3,827 txs, avg 2,517,565 gas increase - **verifyFRI**: 16,654 txs, avg 299,377 gas increase - **verifyMerkle**: 7,137 txs, avg 384,350 gas increase #### NFT Marketplace Operations - **fulfillAvailableAdvancedOrders**: 70,794 txs, avg 375,772 gas increase - **matchAdvancedOrders**: 35,064 txs, avg 74,445 gas increase - **fulfillAdvancedOrder**: 25,484 txs, avg 81,621 gas increase - **cancel**: 191,576 txs, avg 95,012 gas increase #### Multi-signature/Proxy Operations - **forward**: 72,208 txs, avg 76,366 gas increase - **execute**: 42,105 txs, avg 208,186 gas increase - **aggregate3**: 19,638 txs, avg 131,491 gas increase ## EIP-7623 Interaction Analysis ### Linear Cost Increase The analysis reveals that **41.6% of transactions affected by EIP-7976 are already impacted by EIP-7623**. This means: - **2,093,004 transactions** (0.85% of all transactions) will experience **linear cost increases** as calldata pricing moves from EIP-7623 rates to EIP-7976 rates - **2,942,610 transactions** (1.20% of all transactions) represent new impact from EIP-7976 ### Pricing Structure Comparison | Byte Type | Current | EIP-7623 | EIP-7976 | 7623→7976 Increase | |-----------|---------|----------|----------|-------------------| | Zero bytes | 4 gas | 10 gas | 64 gas | +54 gas (540%) | | Non-zero bytes | 16 gas | 40 gas | 64 gas | +24 gas (60%) | ### Key Findings 1. **High Concentration**: Cost impact is extremely concentrated with top 1% of addresses responsible for 91.44% of additional costs 2. **EIP-7623 Linear Escalation**: A significant portion of affected transactions (41.6%) will see linear cost increases from existing EIP-7623 pricing 3. **Address Distribution**: 60.98% of affected addresses have only 1 affected transaction, indicating diverse but minimal user impact 4. **Methods**: Impact is dominated by zero-knowledge proof operations and NFT marketplace operations, with additional impact from multi-signature/proxy operations 5. **Cost Variance**: Median increase (11,444 gas) vs mean increase (101,489.08 gas) shows high variance in impact severity 6. **Broader Impact**: With 64/64 pricing, 2.05% of transactions are affected (vs 1.48% with 15/60 pricing), representing a 38.5% increase in affected transaction count https://eips.ethereum.org/assets/eip-7976/eip7976_empirical_analysis https://eips.ethereum.org/assets/eip-7976/eip7976_empirical_analysis Compute and memory operations / # Compute and memory operations ```python # Keccak Op KECCAK = 0x20 # Environmental Ops CALLDATACOPY = 0x37 CODECOPY = 0x39 RETURNDATACOPY = 0x3E # Memory Operations MLOAD = 0x51 MSTORE = 0x52 MSTORE8 = 0x53 MCOPY = 0x5E # System Operations RETURN = 0xF3 REVERT = 0xFD ``` https://eips.ethereum.org/assets/eip-8011/compute_mem_ops https://eips.ethereum.org/assets/eip-8011/compute_mem_ops Pure compute operations / # Pure compute operations ```python # Arithmetic Ops ADD = 0x01 MUL = 0x02 SUB = 0x03 DIV = 0x04 SDIV = 0x05 MOD = 0x06 SMOD = 0x07 ADDMOD = 0x08 MULMOD = 0x09 EXP = 0x0A SIGNEXTEND = 0x0B # Comparison Ops LT = 0x10 GT = 0x11 SLT = 0x12 SGT = 0x13 EQ = 0x14 ISZERO = 0x15 # Bitwise Ops AND = 0x16 OR = 0x17 XOR = 0x18 NOT = 0x19 BYTE = 0x1A SHL = 0x1B SHR = 0x1C SAR = 0x1D # Environmental Ops ADDRESS = 0x30 ORIGIN = 0x32 CALLER = 0x33 CALLVALUE = 0x34 CALLDATALOAD = 0x35 CALLDATASIZE = 0x36 CODESIZE = 0x38 GASPRICE = 0x3A RETURNDATASIZE = 0x3D # Block Ops BLOCKHASH = 0x40 COINBASE = 0x41 TIMESTAMP = 0x42 NUMBER = 0x43 PREVRANDAO = 0x44 GASLIMIT = 0x45 CHAINID = 0x46 SELFBALANCE = 0x47 BASEFEE = 0x48 BLOBHASH = 0x49 BLOBBASEFEE = 0x4A # Control Flow Ops STOP = 0x00 JUMP = 0x56 JUMPI = 0x57 PC = 0x58 GAS = 0x5A JUMPDEST = 0x5B # Storage Ops TLOAD = 0x5C TSTORE = 0x5D # Pop Operation POP = 0x50 # Push Operations PUSH0 = 0x5F PUSH1 = 0x60 PUSH2 = 0x61 PUSH3 = 0x62 PUSH4 = 0x63 PUSH5 = 0x64 PUSH6 = 0x65 PUSH7 = 0x66 PUSH8 = 0x67 PUSH9 = 0x68 PUSH10 = 0x69 PUSH11 = 0x6A PUSH12 = 0x6B PUSH13 = 0x6C PUSH14 = 0x6D PUSH15 = 0x6E PUSH16 = 0x6F PUSH17 = 0x70 PUSH18 = 0x71 PUSH19 = 0x72 PUSH20 = 0x73 PUSH21 = 0x74 PUSH22 = 0x75 PUSH23 = 0x76 PUSH24 = 0x77 PUSH25 = 0x78 PUSH26 = 0x79 PUSH27 = 0x7A PUSH28 = 0x7B PUSH29 = 0x7C PUSH30 = 0x7D PUSH31 = 0x7E PUSH32 = 0x7F # Dup operations DUP1 = 0x80 DUP2 = 0x81 DUP3 = 0x82 DUP4 = 0x83 DUP5 = 0x84 DUP6 = 0x85 DUP7 = 0x86 DUP8 = 0x87 DUP9 = 0x88 DUP10 = 0x89 DUP11 = 0x8A DUP12 = 0x8B DUP13 = 0x8C DUP14 = 0x8D DUP15 = 0x8E DUP16 = 0x8F # Swap operations SWAP1 = 0x90 SWAP2 = 0x91 SWAP3 = 0x92 SWAP4 = 0x93 SWAP5 = 0x94 SWAP6 = 0x95 SWAP7 = 0x96 SWAP8 = 0x97 SWAP9 = 0x98 SWAP10 = 0x99 SWAP11 = 0x9A SWAP12 = 0x9B SWAP13 = 0x9C SWAP14 = 0x9D SWAP15 = 0x9E SWAP16 = 0x9F # Memory Operations MSIZE = 0x59 ``` https://eips.ethereum.org/assets/eip-8011/compute_ops https://eips.ethereum.org/assets/eip-8011/compute_ops LOG operations / # LOG operations ```python # Log Operations LOG0 = 0xA0 LOG1 = 0xA1 LOG2 = 0xA2 LOG3 = 0xA3 LOG4 = 0xA4 ``` https://eips.ethereum.org/assets/eip-8011/log_ops https://eips.ethereum.org/assets/eip-8011/log_ops Going multidimensional - an empirical analysis on gas metering in the EVM / # Going multidimensional - an empirical analysis on gas metering in the EVM **This document is a copy-paste from [this ethresearch post](https://ethresear.ch/t/going-multidimensional-an-empirical-analysis-on-gas-metering-in-the-evm/22621)** This post summarizes the key takeaways from an empirical analysis focused on understanding how different EVM gas metering schemes impact network throughput and block utilization. Concretely, we were focused on multidimensional schemes, where the usage of different resources is metered separately. For conciseness, I am jumping over many technical details. Please refer to the [project documentation](https://hackmd.io/@nightingale/evm-gas-meter) for more details. I would like to thank @dcrapis for the valuable review, comments, and discussion, [Shouqiao Wang](https://x.com/qiaoqiao2001?lang=en) for the early discussions and for sharing his initial analysis, and the ethPandaOps team for access to their amazing data. This project was supported by the grant [ROP-15: EVM Gas Metering](https://blog.ethereum.org/2025/05/08/allocation-q1-25) provided by the [Robust Incentives Group](https://rig.ethereum.org/). ## Gas metering and block utilization Gas is the unit that quantifies the computational work needed to perform operations on the Ethereum network. Every transaction on Ethereum consumes resources, and to prevent spam and endless loops, users must pay for these resources. An essential component of this process is the gas metering scheme, i.e., the function responsible for measuring how full a block is and how many resources remain available. All decentralized networks have limited resources, and thus, protocols must have a way to meter usage and decide when a block is reaching those limits. In Ethereum, the current metering scheme attributes a cost to each operation (measured in units of gas) and adds the gas of each transaction. Then, it compares this sum against a fixed limit of 36 million gas units. Once a block reaches 36 million gas units, it is considered completely full. In addition to this limit, the protocol also compares the gas utilized by the block against a target of 18 million, which is used to set the base fee all transactions must pay. This scheme has the advantage of being simple and, thus, easy to interface with. However, it has the drawback of overestimating how close a block is to being at the limits of the network resources. To illustrate this point, let us start with a simple example. In this example, we have two blocks, $B_1$ and $B_2$, and a network that only cares about two resources, $x$ and $y$, which with a limit of 1. $B_1$ has a usage by resource of $(x=1, y=0)$ and $B_2$ has a usage by resource of $(x=0.5, y=0.5)$. According to the current scheme, both blocks have the same usage of 1 unit. However, we can see that neither block is reaching the limits of the available resources. $B_1$ is at the limit of resource $x$, but it does not use resource $y$. On the other hand, $B_2$ is only using half of both resources. This lack of expressivity in the current scheme led to the idea of replacing it with a scheme in which the usage and limits of different resources are considered separately. These are commonly referred to as "multidimensional schemes". A possible approach is a scheme similar to the one [described by Vitalik](https://vitalik.eth.limo/general/2024/05/09/multidim.html). In this approach, we separate the resources into groups (in our previous example, resource $x$ would be one group, and resource $y$ would be the other). Then, for each block, we add the gas units for each group ($g_x$ and $g_y$) and define the block resource utilization as the maximum of the groups ( $\text{utilization}=\max(c_x*r_x+c_y*r_y, c'_x*r_x, g_y)$). Note however that Vitalik's approach is at transaction-level, instead of at block-level. We can see that in our previous example, this metering scheme would allow us to fill both blocks with more transactions: $B_1$ can additionally include 0.5 units of each resource, while block $B_2$ can include 1 unit of resource $y$ without reaching the block limit. This example highlights a potential advantage of multidimensional metering. By allowing for a more efficient account of resource utilization, we can increase network throughput (i.e., process more transactions in a block) without significantly impacting the risk of resource overuse. However, there are two key questions to consider here: 1. What are the actual throughput gains we should expect from going multidimensional? 2. What is the design space for multidimensional schemes? And what are the next steps to decide on the best design? We will try to address each of these questions in the following sections. ## Going multidimensional. Why? ### Historical gas usage by resource To understand the potential throughput gains of multidimensional metering, we first need to examine how much gas is being used by each resource. To this end, we designed a data pipeline that collects raw transaction data from [Xatu’s dataset](https://ethpandaops.io/data/xatu/) and the [debug traces](https://github.com/akegaviar/Erigon-Geth-debug_traceTransaction-guide/) from an Erigon node, processes and aggregates this data to compute individual gas cost components (intrinsic costs, input data, opcodes, and refunds) by transaction and maps these costs to specific EVM resources (compute, memory, state, history, access, and bloom topics). The mapping between operations and resources is a major assumption underlying this analysis; different mappings will have a significant impact on the final resource breakdown. Our mapping is based on the knowledge of the underlying operations (e.g., we know that some opcodes only use compute resources) and a partial breakdown of the [cost of some opcodes by resource](https://docs.google.com/spreadsheets/d/1IBf9qD0VUQErsw-oPtaEFa2P3L5w-K46cGPB_n8j0jU/edit?usp=sharing) made when the gas model was first designed. We should further note that this analysis overlooks the costs and resource utilization associated with blobs. Although this is a parallel free market at the moment, it will nevertheless impose constraints on bandwidth limits and, thus, should be considered when designing a new gas metering model. The plot below shows the contribution of each resource to the total gas consumption observed between blocks 22000000 and 22005000 (which were processed on March 8th). For improved visibility, we aggregate costs across groups of 10 consecutive blocks. Since each bar is a sum over 10 blocks, the maximum gas that can be used per bar is 360 million units, while the target gas is 180 million units. We plot the target line of 180 million units. ![plot_1](/assets/eip-8011/plot_1.png) In our data, state represents a significant portion of the gas used in Ethereum blocks, accounting for 30.2% of all gas consumed between blocks 22000000 and 22005000. The second resource with the most gas used is compute (26.8%), followed by access (21.9%). History, bandwidth, and bloom topics have less relevant contributions, accounting for 9.9%, 6.9%, and 1.6% of all the gas used, respectively. This means that state, compute, and access are the bottleneck resources, as they cover a significant portion of the available block space. Thus, we expect that metering models that separate these resources will show the biggest gains. When considering resource constraints and the impact of a multidimensional metering scheme on network scalability, looking into the times of congestion or "high load" is also relevant. Using the same data as before, we filtered the blocks with a high utilization rate (more than 95%) and plotted the distribution of block utilization rate by resource and the block count by top resource. These blocks constitute 9.7% of the consecutive blocks dataset. | | | |---|---| |![plot_2](/assets/eip-8011/plot_2.png)| ![plot_3](/assets/eip-8011/plot_3.png)| Interestingly, state dominates in these blocks (with some contribution from compute and access), which is a significant change when compared with the average block. This indicates that, during periods of high demand, the types of operations more commonly used differ from those used in the average block. Thus, for the current usage of the EVM, state is likely the most important resource to consider when designing multidimensional schemes. ### Block building simulation and metering schemes By now, we know that state, compute, and access are the most likely resources to achieve throughput gains. However, we still have not answered what the actual gains might be. To accomplish this, we built a simulation based on the [Monte-Carlo method](https://en.wikipedia.org/wiki/Monte_Carlo_method) that uses repeated random sampling to estimate the throughput observed under different metering schemes and transaction demand levels. We model transaction demand through scenarios. They control the number of transactions and which transactions arrive at the mempool at each 12-second slot. For each slot, we refresh the mempool with the transactions generated by the demand scenario. Then, we build a block for the slot. First, we order the mempool transactions by their transaction fees (the highest are first). Second, we iteratively add transactions to the block until it is full according to the metering scheme being tested. Of course, once we add a transaction to block, we remove it from the mempool so that it cannot be selected again. This mempool refresh and block-building cycle is repeated for a pre-defined number of blocks. The first scenario we want to discuss aims to mimic an infinite demand for historical transactions. In other words, it tries to estimate the maximum gains we could achieve under different metering schemes, assuming that there are always more transactions available to fill a block up to the 36 million gas units limit. This scenario samples transactions from the same historical blocks processed on March 8th until the block is full. The following table displays the average gains in transaction throughput (i.e., the number of transactions included in a block) and total gas used (i.e., the total number of gas units included in a block) for various metering schemes. The averages are computed over 100,000 Monte Carlo iterations of a single block built under this scenario. | **Metering scheme** | **Average gain in throughput** | **Average gain in gas used** | |:---:|:---:|:---:| | Compute vs. Others | 60.1% | 44.0% | | State vs. Others | 58.9% | 52.5% | | Access vs. Others | 49.6% | 34.1% | | Bandwidth vs. Others | 26.2% | 11.7% | | State vs. Compute vs. Others | 145.2% | 133.8% | | State vs. Compute vs. Access vs. Others | 241.3% | 219.1% | Between the two-dimensional schemes, Compute vs. Others and State vs. Others show the largest gain in throughput compared to the current one-dimensional scheme. Access vs. Others also shows a significant gain, although slightly lower than the other two schemes. Additionally, both the three-dimensional and the four-dimensional schemes result in even larger gains over the current scheme, which highlights that compute, state and access have relevant gas usage in historical transactions and, as such, metering these resources separately can have a significant impact in throughput in a case with infinite demand of these transactions. This trend is also observed in the total gas units included in the block. Although, the gains for the gas used are slightly lower than those observed in transaction throughput. Now that we estimated the maximum gains one could observe in the various metering schemes, it is natural to question how much additional demand would be required in each metering scheme to fill Ethereum blocks and achieve the throughput previously observed. To this end, we designed a set of scenarios where we sample historical transactions from March 8th with varying demand levels. The demand is modeled by the empirical distribution observed on March 8th, with a multiplier to increase the average demand. For example, a multiplier of 2x will result in an average demand that is double the demand observed on March 8th. The plot below shows the transaction arrival count distributions for the four demand multipliers tested. ![plot_4](/assets/eip-8011/plot_4.png) The next plot shows the median block utilization and the inter-quartile range (IQR) by metering scheme and demand level. Recall that the block utilization represents how full a block is and is defined as the metered gas of a block divided by the 36 million gas units limit. ![plot_5](/assets/eip-8011/plot_5.png) In line with previous results, the base demand (multiplier = 1x) is insufficient to achieve high utilization rates across all metering schemes. As demand levels increase, median utilization rates also rise. In the two-dimensional schemes, a demand level of 3x is needed to achieve full blocks for the median case. The three-dimensional scheme requires a demand of 5x. Regarding the four-dimensional model, all demand levels tested result in partially filled blocks in the median case. ## Going multidimensional. What do? Based on our empirical analysis, there is a significant gain in L1 scalability in moving to a multidimensional metering scheme. However, are there any downsides? The key tradeoff is complexity. There are two levels on which multidimensional metering increases complexity. The first level is implementation complexity. We need to be able to track the amount of gas each EVM operation consumes per resource, and this requires a hard fork on the execution clients to add the new resource dimensions. In addition, we need to encode the mapping between each operation and each resource. This mapping is crucial to ensuring the network continues to function properly; therefore, it is essential to conduct in-depth benchmarks on the resource usage of each operation. This could be an analysis akin to [gas-cost-estimator](https://github.com/imapp-pl/gas-cost-estimator/tree/master) but for all the relevant EVM resources. Finally, we are introducing a new variable that is only used to track block utilization. At the same time, we continue to use the total gas to compute transaction fees, which can be confusing. The second level of complexity relates to block building. Even though the experience for users remains the same - transactions cost the same, and users continue to submit a single gas limit and maximum fee - block builders now have a more complicated optimization problem. Not only do they need to consider the MEV and transaction fees, but also how to efficiently pack blocks into the various resources. https://eips.ethereum.org/assets/eip-8011/multidim_empirical_analysis https://eips.ethereum.org/assets/eip-8011/multidim_empirical_analysis State operations / # State operations ```python # Environmental Ops BALANCE = 0x31 EXTCODESIZE = 0x3B EXTCODECOPY = 0x3C EXTCODEHASH = 0x3F # Storage Ops SLOAD = 0x54 SSTORE = 0x55 # System Operations CREATE = 0xF0 CALL = 0xF1 CALLCODE = 0xF2 DELEGATECALL = 0xF4 CREATE2 = 0xF5 STATICCALL = 0xFA SELFDESTRUCT = 0xFF ``` https://eips.ethereum.org/assets/eip-8011/state_ops https://eips.ethereum.org/assets/eip-8011/state_ops EIP-8131 Empirical Impact / # EIP-8131 Empirical Impact Isolated EIP-8131 impact, assuming EIP-7976 is active. Mainnet, last 6 months (2025-11-08 to 2026-05-08), via Xatu. | | | |---|---:| | All mainnet txs | 376,262,548 | | All mainnet senders | 54,160,707 | | Type-4 txs | 2,658,513 (0.71% of all) | | Type-4 senders | 208,978 (0.39% of all) | | **Affected txs** | **3,288** (0.124% of type-4 / 0.001% of all) | | **Affected senders** | **689** (0.330% of type-4 senders) | | **Total extra gas (6 mo)** | **27,648,764** | | Δ per affected tx (median / p95 / p99) | 6,464 / 19,392 / 71,104 | | Mean / median Δ as share of `gas_C_7976` (EIP-7976 baseline) | 5.53% / 5.18% | | Affected-tx success rate | **22.0%** (725 succ / 2,563 reverted; vs. 93.6% across all type-4) | Median Δ = `FLOOR_COST_PER_AUTH` exactly; 80.8% of affected txs are 1-auth delegations whose `intrinsic + execution` already sat below `floor_C`, so EIP-8131 layers cleanly on top. The bulk of the floor-bound population are *reverted* txs whose execution path doesn't burn enough gas to clear the new floor. ## Top affected senders | # | sender | affected txs | extra gas | max auths | total auths | |---|---|---:|---:|---:|---:| | 1 | [`0x59aab1bd…25e16b`](https://etherscan.io/address/0x59aab1bd0d26290274398c07b55955c15425e16b) | 296 | 7,757,005 | 31 | 2,138 | | 2 | [`0xfc152f3c…40e2b`](https://etherscan.io/address/0xfc152f3cf5c2d2370ee84555bf3d8b1320640e2b) | 7 | 1,639,149 | 130 | 640 | | 3 | [`0xe46f81fa…0b99ae`](https://etherscan.io/address/0xe46f81faaf19199b3d68762fc3879e42ff0b99ae) | 120 | 771,627 | 1 | 120 | | 4 | [`0xb9d00655…24da7c`](https://etherscan.io/address/0xb9d00655cae73b4d0905d199150c82d3b124da7c) | 99 | 610,031 | 1 | 99 | | 5 | [`0x35f8f66c…b4586f`](https://etherscan.io/address/0x35f8f66c6c440433f971ae0775d3bf30f5b4586f) | 98 | 597,045 | 1 | 98 | | 6 | [`0xbb4d1438…41bcf`](https://etherscan.io/address/0xbb4d14380a6272237cebeb05a98a1cd20bd41bcf) | 90 | 551,606 | 1 | 90 | | 7 | [`0xec103c6e…58b915`](https://etherscan.io/address/0xec103c6e7e3a674eebc580797fea1b4f9258b915) | 53 | 338,304 | 1 | 53 | | 8 | [`0x34f41c98…35404f`](https://etherscan.io/address/0x34f41c98898ed0c2f7d004538a7cbde33b35404f) | 53 | 332,248 | 1 | 53 | | 9 | [`0x6d2ccc86…97df85`](https://etherscan.io/address/0x6d2ccc86fa7afcf6b1b79a32e3167d98ec97df85) | 50 | 312,367 | 1 | 50 | | 10 | [`0x7d8f6522…1af30a`](https://etherscan.io/address/0x7d8f6522ff026b87e3ae7b202b1afd21191af30a) | 50 | 312,316 | 1 | 50 | The top sender alone accounts for ~28% of all extra gas. #2 is the cleanest "bypass-shaped" sender: 7 txs at up to 130 auths each. ## Affected by auth count | auths | type-4 | affected | extra gas | share | |---:|---:|---:|---:|---:| | 1 | 2,138,203 | 2,994 | 17,493,597 | 63% | | 2 | 75,539 | 76 | 800,509 | 3% | | 3 | 63,608 | 54 | 876,717 | 3% | | 4-5 | 93,768 | 43 | 996,673 | 4% | | 6-10 | 118,930 | 29 | 1,042,062 | 4% | | 11-20 | 98,125 | 48 | 3,085,595 | 11% | | 21-50 | 57,085 | 37 | 1,714,462 | 6% | | 51-200 | 10,949 | 7 | 1,639,149 | 6% | | >200 | 2,306 | 0 | 0 | 0% | ## Method `num_authorizations` estimated from `tx.size − tx.call_data_size` (≈92 bytes/auth + 117-byte envelope on mainnet); bucket modes verified against the empirical histogram (boundary buckets disagree by ≤1 auth). Today's `gas_used` used as proxy for `intrinsic + execution`, exact for 99.95% of type-4 txs (1,248 rows / 0.05% have `gas_used == floor_A_today`, where the proxy is loose; the isolated metric `Δ = floor_D − floor_C` is invariant to the proxy in that regime, so unaffected). 0 spec violations (`gas_used < floor_A_today`). Long auth-tail (≥51 auths) contributes <6% of total Δ. ## Appendix: context deltas vs. today | scenario | affected | senders | total extra gas | median Δ | mean Δ / `g` | |---|---:|---:|---:|---:|---:| | EIP-8131 only (10/token floor) | 1,595 | 358 | 10,670,600 | 6,464 | 6.2% | | EIP-7976 only | 2,657 | 565 | 175,924,489 | 31,596 | 32.3% | | EIP-7976 + EIP-8131 | 3,288 | 689 | 203,573,253 | 33,062 | 32.9% | Isolated EIP-8131 portion = 27,648,764 (target row above). https://eips.ethereum.org/assets/eip-8131/impact_report https://eips.ethereum.org/assets/eip-8131/impact_report / | Variable | Symbol | Value | Unit | Source | | -------------------|--------------|---------------|---------------|--------| | Network Hashrate |H<sub>N</sub> | 296000 | GH/s | https://etherscan.io/chart/hashrate | | GPU Hashrate |H<sub>M</sub> | 31.2 | MH/s | https://www.legitreviews.com/geforce-gtx-1070-ethereum-mining-small-tweaks-great-hashrate-low-power_195451 | | GPU Power |P<sub>M</sub> | 110.6 | W | https://www.reddit.com/r/ethereum/comments/7vewys/10000_tons_co2_per_day_and_climbing_eip_858/dtrswyz/ | ## Network Power Consumption (P<sub>N</sub>) A baseline value for network power consumption can be found by multiplying the total network hashrate with a "best case" value for the power/hashrate ratio that a miner can achieve. > P<sub>N</sub> = H<sub>N</sub> x P<sub>M</sub> / H<sub>M</sub> > > P<sub>N</sub> = 296000 (GH/s) x 110.6 (W) x 1000 (MH/GH) / ( 31.2 (MH/s) x 10^6 (W/MW) ) > > P<sub>N</sub> = 1049 MW As a side note, people often confuse power (W) and energy (power x time, eg. Wh). For instance, assuming an average daily P<sub>Nd</sub> of 1049 MW we can calculate that days Energy consumption by multiplying by the number of hours in a day. > E<sub>Nd</sub> = P<sub>Nd</sub> x T<sub>d</sub> > > E<sub>Nd</sub> = 1049 (MW) x 24 (h/d) / 1000 (GW/MW) > > E<sub>Nd</sub> = 19.7 GWh https://eips.ethereum.org/assets/eip-858/calculations https://eips.ethereum.org/assets/eip-858/calculations / This directory contains contract sources for EIP 3267 draft. The audit of the contracts was paid for, now it is in progress. (There are some FIXME/TODO comments for the auditors.) The contracts are to be compiled with Solidity 0.7.6. Dependencies (Node.js packages): - @openzeppelin/contracts 3.3.0 - abdk-libraries-solidity 2.4.0 The contracts to be deployed are: - SalaryWithDAO - DefaultDAOInterface The sources: - [ERC1155/ERC1155.sol](/assets/eip-3267/contracts/ERC1155/ERC1155.sol) - [ERC1155/ERC1155TokenReceiver.sol](/assets/eip-3267/contracts/ERC1155/ERC1155TokenReceiver.sol) - [ERC1155/ERC1155WithTotals.sol](/assets/eip-3267/contracts/ERC1155/ERC1155WithTotals.sol) - [ERC1155/IERC1155.sol](/assets/eip-3267/contracts/ERC1155/IERC1155.sol) - [ERC1155/IERC1155TokenReceiver.sol](/assets/eip-3267/contracts/ERC1155/IERC1155TokenReceiver.sol) - [BaseBidOnAddresses.sol](/assets/eip-3267/contracts/BaseBidOnAddresses.sol) - [BaseLock.sol](/assets/eip-3267/contracts/BaseLock.sol) - [BaseRestorableSalary.sol](/assets/eip-3267/contracts/BaseRestorableSalary.sol) - [BaseSalary.sol](/assets/eip-3267/contracts/BaseSalary.sol) - [BidOnAddresses.sol](/assets/eip-3267/contracts/BidOnAddresses.sol) - [DAOInterface.sol](/assets/eip-3267/contracts/DAOInterface.sol) - [DefaultDAOInterface.sol](/assets/eip-3267/contracts/DefaultDAOInterface.sol) - [Salary.sol](/assets/eip-3267/contracts/Salary.sol) - [SalaryWithDAO.sol](/assets/eip-3267/contracts/SalaryWithDAO.sol) https://eips.ethereum.org/assets/eip-3267/contracts/ https://eips.ethereum.org/assets/eip-3267/contracts/ EIP-3525 / # EIP-3525 ## Demonstration only The code included in this directory is ONLY for the purpose of demonstrating how to implement this proposal, it is not a full-featured implementation ready for production. So please DO NOT use the code here for purposes other than study. https://eips.ethereum.org/assets/eip-3525/ https://eips.ethereum.org/assets/eip-3525/ / <div align="center"> # ERC721 Consumable Extension [![License: CC0-1.0](https://img.shields.io/badge/License-CC0-yellow.svg)](https://creativecommons.org/publicdomain/zero/1.0/) </div> This project provides a reference implementation of the proposed `ERC721Consumer` OPTIONAL extension. ## Install In order to install the required dependencies you need to execute: ```shell npm install ``` ## Compile In order to compile the solidity contracts you need to execute: ```shell npx hardhat compile ``` ## Tests ```shell npx hardhat test ``` https://eips.ethereum.org/assets/eip-4400/ https://eips.ethereum.org/assets/eip-4400/ / #EIP4519 Proof of Concept - Firmware This firmware is designed for a device using an ESP32 as a smart asset associated with an EIP4519 SmartNFT. The device has two operation modes: registration mode and application mode. ##Registration mode In this mode, the device generates 51 bytes with the TRNG of the ESP32 core. Those bytes are used for the initial values of a CTR-DRBG PRNG to generate the private key of the Ethereum account. Only the address of this account is shared. The UART port is needed for communications with this device. The commands in this mode are: >‘0’ – Check if the device is ready. >‘1’ – Share the address of the account. >‘2’ – Save the initial values of CTR-DRBG PRNG in an EEPROM and changes the operation mode. ##Application Mode The device reads the EEPROM to obtain the initial values of the CTR-DRBG PRNG and recover the Ethereum account. The device connects to a WiFi station. With Infura, the device checks the state of its associated SmartNFT registered on an EIP4519 Smart Contract and also checks if the device must be engaged with the owner or the user. The UART port is needed for communications with this device. The commands in this mode are: >'Z'+OWNER/USER_ADDRESS – The device checks if the address must be authenticated and generates a nonce. >'Y'+SIGN_D+'#'+NONCE_D – The device checks the signature, signs NONCE_D, and sends the signature. >'Y'+SIGNED_PK+'#'+PK – The device checks the signature, generates the shared key, and sends the transaction to the EIP4519 Smart Contract. >'C' – The EEPROM is cleared, only for debug process. >'R' – The device is restarted to refresh the SmartNFT state, only for debug process. https://eips.ethereum.org/assets/eip-4519/ESP32_Firmware/ https://eips.ethereum.org/assets/eip-4519/ESP32_Firmware/ Proof of concept of an implementation of an Smart Non Fungible Token / # Proof of concept of an implementation of an Smart Non Fungible Token This proof of concept is launch in the Ethereum Kovan Testnet with the address 0x7eB5A03E7ED70ABf70fee48965D0411d37F335aC. Use the proposal Non Fungible Token binding assets with SmartNFT and define the user management of the assets. https://eips.ethereum.org/assets/eip-4519/PoC_SmartNFT/ https://eips.ethereum.org/assets/eip-4519/PoC_SmartNFT/ Multi-Fractional Non-Fungible Token / # Multi-Fractional Non-Fungible Token Solidity Implementation of Multi-Fractional Non-Fungible Token. ## Problem Trying to solve Before, ERC20 Token contract should be deployed every time when fractionalizing a specific NFT. To solve this problem, this standard proposes a token standard to cover multiple fractionalized nft in a contract without having to deploy each time. Issue : https://github.com/ethereum/EIPs/issues/4674 PR : https://github.com/ethereum/EIPs/pull/4675 ## How to use ``` contracts/ helper/ interface/ math/ MFNFT.sol NFT.sol ERC20Token.sol ``` ### Contracts ``MFNFT.sol`` : Multi-Fractional Non-Fungible Token Contract ``NFT.sol`` : Non-Fungible Token Contract ``ERC20Token.sol`` : Sample ERC-20 Token Contract ``helper/Verifier.sol`` : Contract that verifies the ownership of NFT before fractionalization ``math/SafeMath.sol`` : Openzeppelin SafeMath Library ``interface/IERC20.sol`` : ERC-20 Token Interface ``interface/IERC721.sol`` : ERC-721 Token Interface ``interface/IMFNFT`` : MFNFT Token Interface ### Install & Test Installation ``` npm install ``` Test ``` npx hardhat test ``` Coverage ``` npx hardhat coverage ``` https://eips.ethereum.org/assets/eip-4675/ https://eips.ethereum.org/assets/eip-4675/ EIP-4907 / # EIP-4907 EIP-4907 is an extension of ERC-721. It proposes an additional role **user** and a valid duration indicator **expires**. It allows users and developers manage the use right more simple and efficient. ### Tools * [Visual Studio Code](https://code.visualstudio.com/) * [Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Solidity support for Visual Studio code * [Truffle](https://truffleframework.com/) - the most popular development framework for Ethereum ### Install ``` npm install ``` ### Test ``` truffle test ``` ### Additional Resources * [Official Truffle Documentation](http://truffleframework.com/docs/) for complete and detailed guides, tips, and sample code. https://eips.ethereum.org/assets/eip-4907/ https://eips.ethereum.org/assets/eip-4907/ EIP-5007 / # EIP-5007 This standard is an extension of [ERC-721](/EIPS/eip-721). It proposes some additional functions (`startTime`, `endTime`) to help with on-chain time management. ## Tools * [Truffle](https://truffleframework.com/) - a development framework for Ethereum ## Install ``` npm install truffle -g npm install ``` ## Test ``` truffle test ``` https://eips.ethereum.org/assets/eip-5007/ https://eips.ethereum.org/assets/eip-5007/ EIP-5218 Reference Implementations / # EIP-5218 Reference Implementations This is the source code for a reference implementation of EIP-5218. ## Build and Test The repo expects a Foundry build system, optionally using visual studio code for editing. You can run the test suite with: ```bash forge test -vvvvv ``` https://eips.ethereum.org/assets/eip-5218/contracts/ https://eips.ethereum.org/assets/eip-5218/contracts/ EIP 5252 implementation / # EIP 5252 implementation This project is a reference implementation of EIP-5252. Try running some of the following tasks: ```shell npx hardhat help npx hardhat test GAS_REPORT=true npx hardhat test npx hardhat node npx hardhat run scripts/deploy.ts ``` https://eips.ethereum.org/assets/eip-5252/ https://eips.ethereum.org/assets/eip-5252/ EIP-5725: Transferrable Vesting NFT - Reference Implementation / # EIP-5725: Transferrable Vesting NFT - Reference Implementation This repository serves as a reference implementation for **EIP-5725 Transferrable Vesting NFT Standard**. A Non-Fungible Token (NFT) standard used to vest ERC-20 tokens over a vesting release curve. ## Contents - [EIP-5725 Specification](/assets/eip-5725/contracts/IERC5725.sol): Interface and definitions for the EIP-5725 specification. - [ERC-5725 Implementation (abstract)](/assets/eip-5725/contracts/ERC5725.sol): ERC-5725 contract which can be extended to implement the specification. - [VestingNFT Implementation](/assets/eip-5725/contracts/reference/LinearVestingNFT.sol): Full ERC-5725 implementation using cliff vesting curve. - [LinearVestingNFT Implementation](/assets/eip-5725/contracts/reference/VestingNFT.sol): Full ERC-5725 implementation using linear vesting curve. https://eips.ethereum.org/assets/eip-5725/ https://eips.ethereum.org/assets/eip-5725/ SDC Solidity implementation / # SDC Solidity implementation ## Description The reference SDC implementation can be unit tested with Hardhat to understand the trade process logic. ### Compile and run tests with Hardhat We provide the essential steps to compile the contracts and run the provided unit tests. ### Provided Contracts and Tests #### Interfaces - `contracts/ISDC.sol` - Interface contract (aggregation of `ISDCTrade`, `ISDCSettlement`, `IAsyncTransferCallback`) - `contracts/ISDCTrade.sol` - Interface related to trade incept/confirm/terminate - `contracts/ISDCSettlement.sol` - Interface related to settlement initiate/perform/after - `contracts/IAsyncTransferCallback.sol` - Interface related to transfer. - `contracts/IAsyncTransfer.sol` - Interface (extending the ERC-20) for settlement tokens used in `SDCPledgedBalance`. #### Implementations - `contracts/SDCSingleTrade.sol` - SDC abstract contract for an OTC Derivative (single trade case only) - `contracts/SDCSingleTradePledgedBalance.sol` - SDC full implementation for an OTC Derivative (single trade case only) - `contracts/ERC20Settlement.sol` - Mintable settlement token contract implementing `IERC20Settlement` for unit tests #### Tests - `test/SDCTests.js` - Unit tests for the life-cycle of the sdc implementation ### Compile and run tests with Hardhat Install dependencies: ```shell npm i ``` Compile: ```shell npx hardhat compile ``` Run all tests: ```shell npx hardhat test ``` ### Configuration files - `package.js` - Javascript package definition. - `hardhat.config.js` - Hardhat config. ### Used javascript-based testing libraries for solidity - `ethereum-waffle`: Waffle is a Solidity testing library. It allows you to write tests for your contracts with JavaScript. - `chai`: Chai is an assertion library and provides functions like expect. - `ethers`: This is a popular Ethereum client library. It allows you to interface with blockchains that implement the Ethereum API. - `solidity-coverage`: This library gives you coverage reports on unit tests with the help of Istanbul. ## Version history / release notes ### 0.8.0 - Re-introduced the method `afterSettlement` that can be used to check pre-conditions of the next settlement cycle, e.g., triggered by a time-oracle. - Added the event `SettlementAwaitingInitiation` which should be issued when the trade goes active and when `afterSettlement` veryfied that the trade is ready for the next settlement. https://eips.ethereum.org/assets/eip-6123/ https://eips.ethereum.org/assets/eip-6123/ Example implementation of EIP-6358 / # Example implementation of EIP-6358 ## Prerequisites - truffle >= v5.7.9 - node >= v18.12.1 - npm >= 8.19.2 - npx >= 8.19.2 ## Installation ``` npm install ``` Add the configuration file `truffle-config.js` into the directory `./`. The file `truffle-config.js` can be generated by executing the command in an $empty directory$: ``` npx truffle init ``` **Note that:** - type `N` when asked `Overwrite contracts?` - type `N` when asked `Overwrite migrations?` - type `N` when asked `Overwrite test?` After `truffle-config.js` is generated, then: - Uncommnet the content of `development`, like this: ``` development: { host: "127.0.0.1", // Localhost (default: none) port: 8545, // Standard Ethereum port (default: none) network_id: "*", // Any network (default: none) }, ``` ## Compilation ``` touch .secret npx truffle compile ``` ## Unit test ### Launch local testnet ``` npx ganache -s 0 ``` ### Test Open another terminate ``` npx truffle test ``` https://eips.ethereum.org/assets/eip-6358/src/ https://eips.ethereum.org/assets/eip-6358/src/ ERC-6604 / ERC-6604 ======== * [`AbstractERC20.sol`](/assets/eip-6604/contracts/AbstractERC20.sol) * [`AbstractToken.sol`](/assets/eip-6604/contracts/AbstractToken.sol) * [`GenericEIP712.sol`](/assets/eip-6604/contracts/GenericEIP712.sol) * [`IAbstractToken.sol`](/assets/eip-6604/contracts/IAbstractToken.sol) https://eips.ethereum.org/assets/eip-6604/ https://eips.ethereum.org/assets/eip-6604/ / <div align="center"> # ERC6786 Royalty Debt Registry </div> This project provides a reference implementation of the proposed `ERC-6786 Royalty Debt Registry`. ## Install In order to install the required dependencies you need to execute: ```shell npm install ``` ## Compile In order to compile the solidity contracts you need to execute: ```shell npx hardhat compile ``` ## Tests ```shell npx hardhat test ``` https://eips.ethereum.org/assets/eip-6786/ https://eips.ethereum.org/assets/eip-6786/ EIP-6808 implementation / # EIP-6808 implementation This project is a reference implementation of EIP-6808. Try running some of the following tasks: ```shell npm i truffle compile truffle test ``` https://eips.ethereum.org/assets/eip-6808/ https://eips.ethereum.org/assets/eip-6808/ EIP 6809 implementation / # EIP 6809 implementation This project is a reference implementation of EIP-6809. Try running some of the following tasks: ```shell npm i truffle compile truffle test ``` https://eips.ethereum.org/assets/eip-6809/ https://eips.ethereum.org/assets/eip-6809/ ERCxxxx Reference implementation / # ERCxxxx Reference implementation This reference implementation is [MIT](/assets/eip-6956/LICENSE) licensed and can therefore be freely used in any project. ## Getting started From this directory, run ``` npm install && npx hardhat test ``` https://eips.ethereum.org/assets/eip-6956/ https://eips.ethereum.org/assets/eip-6956/ EIP 6982 implementation / # EIP 6982 implementation As a reference implementation of EIP-6982 we use the Nduja Labs ERC721Lockable contract. To run the tests, run the following commands: ```shell npm i -g pnpm pnpm i pnpm test ``` https://eips.ethereum.org/assets/eip-6982/ https://eips.ethereum.org/assets/eip-6982/ ERC-7007 Reference Implementation / # ERC-7007 Reference Implementation This is a WIP implementation of ERC-7007 based on the discussions in the [EIP-7007 issue thread](https://github.com/ethereum/EIPs/issues/7007). ## Setup Run `npm install` in the root directory. ## Testing Try running some of the following tasks: ```shell npx hardhat help npx hardhat test REPORT_GAS=true npx hardhat test ``` ## Metadata Standard ```json { "title": "AIGC Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this NFT represents" }, "description": { "type": "string", "description": "Describes the asset to which this NFT represents" }, "image": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." }, "prompt": { "type": "string", "description": "Identifies the prompt from which this AIGC NFT generated" }, "seed": { "type": "uint256", "description": "Identifies the seed from which this AIGC NFT generated" }, "aigc_type": { "type": "string", "description": "image/video/audio..." }, "aigc_data": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which this AIGC NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." } } } ``` https://eips.ethereum.org/assets/eip-7007/ https://eips.ethereum.org/assets/eip-7007/ Reference implementation of ERC-7208 and usage examples / # Reference implementation of ERC-7208 and usage examples ## List of contracts ### Interfaces - [IDataIndex](/assets/eip-7208/contracts/interfaces/IDataIndex.sol) - Interface of **DataIndex** - [IDataObject](/assets/eip-7208/contracts/interfaces/IDataObject.sol) - Interface of **DataObject** - [IDataPointRegistry](/assets/eip-7208/contracts/interfaces/IDataPointRegistry.sol) - Interface of Data Point Registry - [IIDManager](/assets/eip-7208/contracts/interfaces/IIDManager.sol) - Interface for building and querying Data Index user identifiers ### Implementation - [DataIndex](/assets/eip-7208/contracts/DataIndex.sol) - Data Index (implements `IDataIndex` and `IIDManager`) - [DataPointRegistry](/assets/eip-7208/contracts/DataPointRegistry.sol) - Data Point Registry (implements `IDataPointRegistry`) - [DataPoints](/assets/eip-7208/contracts/utils/DataPoints.sol) - Library implementing DataPoint type and its encode/decode functions - [ChainidTools](/assets/eip-7208/contracts/utils/ChainidTools.sol) - Library implementing utility functions to work with chain ids ### Usage examples - [IFractionTransferEventEmitter](/assets/eip-7208/contracts/interfaces/IFractionTransferEventEmitter.sol) - Interface used for **DataManagers** communication to emit ERC20 Transfer events - [IFungibleFractionsOperations](/assets/eip-7208/contracts/interfaces/IFungibleFractionsOperations.sol) - Interface defines **DataObject** operations, which can be called by **DataManager** - [MinimalisticFungibleFractionsDO](/assets/eip-7208/contracts/dataobjects/MinimalisticFungibleFractionsDO.sol) - **DataObject** implements data storage and related logic for token with Fungible Fractions (like ERC1155) - [MinimalisticERC1155WithERC20FractionsDataManager](/assets/eip-7208/contracts/datamanagers/MinimalisticERC1155WithERC20FractionsDataManager.sol) - **DataManager** implements token with fungible fractions with ERC1155 interface, linked to a DataManager which implements ERC20 interface for same token - [MinimalisticERC20FractionDataManager](/assets/eip-7208/contracts/datamanagers/MinimalisticERC20FractionDataManager.sol) - implements token with ERC20 interface, linked to a **DataManager** which implements ERC1155 interface for same token - [MinimalisticERC20FractionDataManagerFactory](/assets/eip-7208/contracts/datamanagers/MinimalisticERC20FractionDataManagerFactory.sol) - factory of **DataManagers** implementing ERC20 interface for token with fungible fractions --- An audited implementation can be found [here](https://github.com/Nexera-Foundation/Minimalistic-ERC-7208/). https://eips.ethereum.org/assets/eip-7208/contracts/ https://eips.ethereum.org/assets/eip-7208/contracts/ PBM Solidity implementation / # PBM Solidity implementation ## Description We provide a list of sample PBM implementation for reference. ### Provided Contracts and Tests <!-- TBD: Explain the folder structure --> - `contracts/preloaded-pbm/XXXX.sol` - PBMRC1 implementation contract to demonstrate preloaded PBMs - `contracts/non-preloaded-pbm/XXXX.sol` - Interface contract <!-- - `contracts/attest-unlock-pbm/XXXX.sol` - contract to demonstrate a 3rd party attestation to allow unwrap of a PBM --> - `contracts/XXXX.sol` - Interface contract - `contracts/ERC20.sol` - ERC20 token contract for unit tests - `test/XXXXX.js` - Unit tests for livecycle of the PBM implementation ### Used javascript based testing libraries for solidity <!-- TBD: Fill this up with libraries used --> - `hardhat`: hardhat allows for testing of contracts with JavaScript via Mocha as the test runner - `chai`: Chai is an assertion library and provides functions like expect. - `ethers`: This is a popular Ethereum client library. It allows you to interface with blockchains that implement the Ethereum API. ### Compile and run tests with hardhat <!-- TBD: Improve this with nix file --> We provide the essential steps to compile the contracts and run provided unit tests Check that you have the latest version of npm and node via `npm -version` and `node -v` (should be a LTS version for hardhat support) 1. Check out project 2. Go to folder and initialise a new npm project: `npm init -y`. A basic `package.json` file should occur 3. Install Hardhat as local solidity dev environment: `npx hardhat` 4. Select following option: Create an empty hardhat.config.js 5. Install Hardhat as a development dependency: `npm install --save-dev hardhat` 6. Install further testing dependencies: `npm install --save-dev @nomiclabs/hardhat-waffle @nomiclabs/hardhat-ethers ethereum-waffle chai ethers solidity-coverage` 7. Install open zeppelin contracts: `npm install @openzeppelin/contracts` 8. add plugins to hardhat.config.ts: ``` require("@nomiclabs/hardhat-waffle"); require('solidity-coverage'); ``` 9. Adding commands to `package.json`: ``` "scripts": { "build": "hardhat compile", "test:light": "hardhat test", "test": "hardhat coverage" }, ``` 9. run `npm run build` 10. run `npm run test` https://eips.ethereum.org/assets/eip-7291/ https://eips.ethereum.org/assets/eip-7291/ Ethereum Entity Component System / # Ethereum Entity Component System World contracts are containers for entities, component contracts, and system contracts. Its core principle is to establish the relationship between entities and component contracts, and different entities will attach different components. And use the system contract to dynamically change the data of the entity in the component. Usual workflow when building ECS-based programs 1. Implement the `IWorld` interface to create a world contract. 2. Call `createEntity()` of the world contract to create an entity. 3. Implement the `IComponent` interface to create a Component contract. 4. Call `registerComponent()` of the world contract to register the component contract. 5. Call `addComponent()` of the world contract to attach the component to the entity. 6. Create a system contract, which is a contract without interface restrictions, and you can define any function in the system contract. 7. Call `registerSystem()` of the world contract to register the system contract. 8. Run the system. - [`System.sol`](/assets/eip-7509/System.sol) - [`Types.sol`](/assets/eip-7509/Types.sol) - [`World.sol`](/assets/eip-7509/World.sol) - [`Component.sol`](/assets/eip-7509/Component.sol) https://eips.ethereum.org/assets/eip-7509/ https://eips.ethereum.org/assets/eip-7509/ DvP Solidity implementation / # DvP Solidity implementation ## Description The interfaces in this proposal model a functional transaction scheme to establish a secure *delivery-versus-payment* across two blockchains, where a) no intermediary is required and b) one of the two chains can securely interact with a stateless "decryption oracle". Here, *delivery-versus-payment* refers to the exchange of, e.g., an asset against a payment; however, the concept is generic to make a transfer of one token on one chain (e.g., the payment) conditional to the successful transfer of another token on another chain (e.g., the asset). The scheme is realized by two smart contracts, one on each chain. One smart contract implements the `ILockingContract` interface on one chain (e.g. the "asset chain"), and another smart contract implements the `IDecryptionContract` interface on the other chain (e.g., the "payment chain"). The smart contract implementing `ILockingContract` locks a token (e.g., the asset) on its chain until a key is presented to encrypt to one of two given values. The smart contract implementing `IDecryptionContract`, decrypts one of two keys (via the decryption oracle) conditional to the success or failure of the token transfer (e.g., the payment). A stateless decryption oracle is attached to the chain running `IDecryptionContract` for the decryption. ### Provided Contracts #### DvP - `contracts/ILockingContract.sol` - Contract locking transfer with given encrypted keys or hashes. - `contracts/IDecryptionContract.sol` - Contract performing conditional upon transfer decryption (possibly based on an external oracle). #### Decryption Oracle - `contracts/IKeyDecryptionOracle.sol` - Interface implemented by a decryption oracle proxy contract. - `contracts/IKeyDecryptionOracleCallback.sol` - Interface to be implemented by a callback receiving the decrypted key. ### Documentation - `doc/DvP-Seq-Diag.png` - Sequence diagram of the DvP - `doc/multi-party-dvp.svg` - Sequence diagram of a multi-party-dvp. https://eips.ethereum.org/assets/eip-7573/ https://eips.ethereum.org/assets/eip-7573/ ERC7641: Intrinsic RevShare Token / # ERC7641: Intrinsic RevShare Token An ERC-20 extension that integrates a revenue-sharing mechanism, ensuring tokens intrinsically represent a share of a communal revenue pool https://eips.ethereum.org/assets/eip-7641/ https://eips.ethereum.org/assets/eip-7641/ EIP-7701: Native Account Abstraction explained / # EIP-7701: Native Account Abstraction explained The purpose of this document is to provide more details about the design of EIP-7701, while keeping the [Specification](/EIPS/eip-7701#specification) section of the core document concise. ## Definitions for terms used in EIP-7701 * **Smart Contract Account**: an Ethereum smart contract that serves as the user's account and on-chain identity. It is responsible for holding user's assets, verifying user requests, and executing actions on the user's behalf. * **Sender**: the Smart Contract Account sending the current AA transaction. * **Paymaster**: a smart contract that is requested to pay gas fees for the current AA transaction on behalf of the `Sender` contract. * **Deployer**: a smart contract that performs a deployment for a new `Sender` contract if necessary in the context of the current AA transaction. * **Entity**: a common term for any of the smart contracts mentioned above in the context of an EIP-7701 Transaction. * **Transaction Validity**: A property of an Ethereum transaction that describes whether this transaction can be included in a block without a violation of the ethereum execution and consensus rules. This property depends on both the inputs of the transaction and the current state of the Ethereum blockchain and can change over time. * **EIP-7701 Transaction**: the entire transaction initiated by the `Sender` Smart Contract Account and represented with an [EIP-2718](../../EIPS/eip-2718) compatible Transaction Envelope object. * **Call Frame**: The context and state for a specific function call during contract execution, including input parameters, local variables, and the execution environment. * **Top-Level Call Frame**: The initial execution context of a transaction accessing the contract, the "entry point" to the EVM code. * **EIP-7701 Call Frame**: A single atomic element of EVM code execution, represented by a single top-level call to a specific address with a given data.\ An EIP-7701 call frame may contain inner call frames as well, but they are not referred to as "EIP-7701 call frames".\ An EIP-7701 call frame may either succeed or revert. * **Frame's Role**: An identifier of an action that the invoked contract is asked to make during the current call frame. An Entity may have one or more roles as part of the EIP-7701 Transaction flow. * **EIP-7701 Transaction Phase**: A set of EIP-7701 Call Frames that form a single step in an EIP-7701 Transaction flow. There are two phases in an EIP-7701 Transaction: *validation* and *execution* * **Validation phase**: A set of EIP-7701 Call Frames that define the current EIP-7701 Transaction's **Validity** by executing the **validation** EVM code. * **Execution phase**: A set of EIP-7701 Call Frames that perform the actions according to the `Sender` and the `Paymaster` contracts' interpretation of the user input. These frames do not define the **Validity** of the transaction. ## A frame context `current_context_role` variable During the execution of the `Sender`, `Paymaster` or a `Deployer` code as defined by the `AA_TX_TYPE` transaction, the frame context `current_context_role` variable is set to the corresponding role. The `current_context_role` remains set only for the top-level frame, as well as for inner frames made in the context of the entity, through an uninterrupted chain of `DELEGATECALL` calls. By default, the value for `current_context_role` is set to `ROLE_SENDER_EXECUTION`. Call frames initiated with any opcodes other than `DELEGATECALL` run with the `ROLE_SENDER_EXECUTION` role. If by the end of the execution of the `Sender`, `Paymaster` or a `Deployer` code `current_context_role` is not explicitly accepted by using the `ACCEPT_ROLE` opcode, the EIP-7701 Call Frame reverts. An EIP-7701 transaction is valid if and only if the following conditions are met for each of `role_sender_deployment`, `role_sender_validation`, `role_paymaster_validation`: * The top-level call frame did not revert. * `ACCEPT_ROLE` was called at least once with the role input parameter equal to `current_context_role` in a frame that did not revert. ### New `TXPARAMLOAD`, `TXPARAMSIZE`, and `TXPARAMCOPY` opcodes Accessing transaction details within call frames is performed using the new `TXPARAM*` opcode family. The instructions accept the parameter identifier value that we call `txparam_id`. The `TXPARAMDLOAD`, `TXPARAMSIZE`, `TXPARAMCOPY` follow the pattern of `CALLDATA*` / `RETURNDATA*` opcode families. ### Limitations on `TXPARAM*` opcodes The `TXPARAM*` opcodes are only functional in the top level frames for all roles. Calling these opcodes in another context returns zero values and zero lengths. Requesting `execution_status` and `execution_gas_used` parameters outside the `role_paymaster_post_op` role's frame returns zero values. Contracts may use `CURRENT_ROLE` (`current_context_role`) to determine the current frame role. ## Paymaster post-operation frame (optional) This step is performed with the `role_paymaster_post_op` role. It is intended to provide the Paymaster contract with an opportunity to finalize any calculations after the results of the Sender Execution are known. The `execution_status` and `execution_gas_cost` values are runtime introspection parameters only accessible during this frame via the `TXPARAMLOAD` opcode. The post-operation frame is considered an integral part of the transaction execution phase. It means that if the post-operation frame reverts its execution, the Sender Execution state changes are also reverted. ## Transaction Execution Flow All legacy transaction types only have an implicit validation phase where balance, nonce, and signature are checked, and an implicit execution phase with a single top-level execution frame. For all legacy transaction types, during the single top-level execution frame, the `ORIGIN` (`0x32`, `tx.origin`) and `CALLER` (`0x33`, `msg.sender`) are both equal to the address that is determined by the transaction's ECDSA signature (`yParity`, `r`, `s`). When processing an EIP-7701 transaction, however, multiple execution frames will be created. The full list of possible frames and their corresponding role definitions is as follows: 1. **Validation Phase** * `sender` deployment frame (once per account) - `role_sender_deployment` * `sender` validation frame (required) - `role_sender_validation` * `paymaster` validation frame (optional) - `role_paymaster_validation` 2. **Execution Phase** * `sender` execution frame (required) - `role_sender_execution` * `paymaster` post-operation frame (optional) - `role_paymaster_post_op` All execution frames in the **Validation Phase** must be completed successfully without reverting in order for the transaction to be considered valid for a given position in a block. ## Transaction execution context Note that some behaviours in the EVM depend on the transaction context. These behaviours include: 1. Costs of the `SSTORE (0x55)` opcode per [EIP-2200](../../EIPS/eip-2200) 2. Costs of accessing cold addresses and slots per [EIP-2929](../../EIPS/eip-2929) 3. Values available within the transient storage per [EIP-1153](../../EIPS/eip-1153) 4. Maximum amount of gas refund assigned after the execution per [EIP-3529](../../EIPS/eip-3529) These features are not affected by the separation of the transaction into multiple frames. Meaning, for example, that a value set with `TSTORE (0x5D)` in one frame will remain available in the next one. ### Flow diagrams #### Simple AA Transaction flow ![Simple AA transaction flow diagram](/assets/eip-7701/simple_flow.svg) #### Complete AA transaction flow ![Simple AA transaction flow diagram](/assets/eip-7701/complete_flow.svg) ## Rationale ### Introduction of the `TXPARAM*` opcode family The validation calls of a Smart Contract Account code need to have full access to the majority of transaction details in order to be able to make an informed decision about either accepting or rejecting the transaction. A small subset of this data is available with the existing opcodes, like `CALLER (0x33)` or `GASPRICE (0x3A)`. However, creating an opcode for every transaction parameter is not feasible or desirable. The `TXPARAM*` opcode family provides the Account Abstraction contracts with access to this data. These values are not made accessible to the transactions' execution or to legacy transaction types. This limitation prevents the `TXPARAM*` opcode family from becoming a new source of a globally observable state, which could create backwards compatibility issues in the future. ### Reverting execution on `postOp` frame revert The `postOp` frame is part of the execution phase and is a way for Paymasters to manage their bookkeeping, refund the user, and enforce post-execution conditions to make sure the Sender did what the Paymaster expected it to. It is not a part of transaction validation, meaning that if it reverts, the Paymaster still pays for the transaction. If the `postOp` frame reverts it indicates that these post-execution conditions, defined by the paymaster, were not met. This could occur if, for example: * A user failed to perform the specific action the Paymaster intended to pay for * A user provided false information during validation that was found to be false when checked in the `postOp` frame. * An "intent" was not correctly fulfilled by a solver as verified in the `postOp` frame. By reverting the main execution frame when the `postOp` frame reverts: * The user receives no value from the transaction, as their intended operation is undone. This removes an important potential incentive for users to exploit the paymaster. * The paymaster is protected from sponsoring unintended or abusive operations. While the paymaster still incurs the gas costs for the transaction, they prevent non-compliant operation from successfully completing. * The paymaster is able to identify the offending Sender account and take action, such as refusing future transactions. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). https://eips.ethereum.org/assets/eip-7701/ https://eips.ethereum.org/assets/eip-7701/ References for ERC-7746 / # References for ERC-7746 In this directory you can find a reference implementation of the ILayer interface and a sample MockERC20 contract. In this test, a [Protected.sol](/assets/eip-7746/test/Protected.sol) contract is protected by a [RateLimitLayer.sol](/assets/eip-7746/test/RateLimitLayer.sol) layer. The RateLimitLayer implements the ILayer interface and enforces a rate which client has configured. The Drainer simulates a vulnerable contract that acts in a malicious way. In the `test.ts` The Drainer contract is trying to drain the funds from the Protected contract. It is assumed that Protected contract has bug that allows partial unauthorized access to the state. The RateLimitLayer is configured to allow only 10 transactions per block from same sender. The test checks that the Drainer contract is not able to drain the funds from the Protected contract. https://eips.ethereum.org/assets/eip-7746/ https://eips.ethereum.org/assets/eip-7746/ ERC-7818 / # ERC-7818 This is reference implementation of ERC-7818 ## Implementation Describe #### Sliding Window Algorithm to look for expiration balance This contract creates an abstract implementation that adopts the `Sliding Window Algorithm` to maintain a window over a period of time (block height). This efficient approach allows for the look back and calculation of `usable balances` for each account within that window period. With this approach, the contract does not require a variable acting as a `counter` or a `state` to keep updating the latest state, nor does it need any interaction calls to keep updating the current period, which is an effortful and costly design. <p align="center"> <img src="implementation.svg" alt="Sliding Window Maintain Balance is Epoch"> </p> #### `epoch` and `list` for storing data in vertical and horizontal way ```solidity // skipping struct Epoch { uint256 totalBalance; mapping(uint256 => uint256) blockBalances; SortedList.List list; } // skipping // O(n→) fot traversal each epoch. // O(n↓) for traversal each element in list. mapping(uint256 => mapping(address => Epoch))) private _balances; mapping(uint256 => uint256) private _worldStateBalance; ``` With `epoch` it provides an abstract loop in a horizontal way more efficient for calculating the usable balance of the account because it provides `totalBalance` which acts as suffix balance, so you don't need to get to iterate or traversal over the `list` in vertical to calculate the entire balance if the `epoch` can presume not to expire. The `_worldStateBalance` mapping tracks the total token balance across all accounts that minted tokens within a particular block. This structure allows the contract to trace expired balances easily. By consolidating balance data for each block. #### Buffering 1 `epoch` rule for ensuring safety In this design, the buffering slot is the critical element that requires careful calculation to ensure accurate handling of balances nearing expiration. By incorporating this buffer, the contract guarantees that any expiring balance is correctly accounted for within the sliding window mechanism, ensuring reliability and preventing premature expiration or missed balances. #### First-In-First-Out (FIFO) priority to enforce token expiration rules Enforcing `FIFO` priority ensures that tokens nearing expiration are processed before newer ones, aligning with the token lifecycle and expiration rules. This method eliminates the need for additional `off-chain` computation and ensures that all token processing occurs efficiently `on-chain`, fully compliant with the ERC20 interface. A **sorted** list is integral to this approach. Each `epoch` maintains its own list, sorted by token creation which is can be `block.timestamp` or `blocknumber`, preventing any overlap with other `epoch`. This separation ensures that tokens in one `epoch` do not interfere with the balance handling in another. The contract can then independently manage token expirations within each `epoch`, minimizing computation while maintaining accuracy and predictability in processing balances. --- #### Token Receipt and Transaction Likelihood across various blocktime Assuming each year contains 4 `epoch`, which aligns with familiar time-based divisions like a year being divided into four quarters, the following table presents various scenarios based on block time and token receipt intervals. It illustrates the potential transaction frequency and likelihood of receiving tokens within a given period. | Block Time (ms) | Receive Token Every (ms) | Index/Epoch | Frequency | Likelihood | | --------------- | ------------------------ | ----------- | ------------------- | ------------- | | 100 | 100 | 78,892,315 | 864,000 _times/day_ | Very Unlikely | | 500 | 500 | 15,778,463 | 172,800 _times/day_ | Very Unlikely | | 1000 | 1000 | 7,889,231 | 86,400 _times/day_ | Very Unlikely | | 1000 | 28,800,000 | 273 | 3 _times/day_ | Unlikely | | 1000 | 86,400,000 | 91 | 1 _times/day_ | Possible | | 5000 | 86,400,000 | 18 | 1 _times/month_ | Very Likely | | 10000 | 86,400,000 | 9 | 3 _times/month_ | Very Likely | > [!IMPORTANT] > - Transactions per day are assumed based on loyalty point earnings. > - Likelihood varies depending on the use case; for instance, gaming use cases may have higher transaction volumes than the given estimates. ## Security Considerations in The Reference Implementation - Solidity Division Rounding Down This implementation contract may encounter scenarios where the calculated expiration block is shorter than the actual expiration block. However, contract mitigates this risk by enforcing valid block times within the defined limits of `MINIMUM_BLOCK_TIME` and `MAXIMUM_BLOCK_TIME`. ## Usage #### Install Dependencies ```bash yarn install ``` #### Compile the Contract Compile the reference implementation ```bash yarn compile ``` #### Run Tests Execute the provided test suite to verify the contract's functionality and integrity ```bash yarn test ``` ### Cleaning Build Artifacts To clean up compiled files and artifacts generated during testing or deployment ```bash yarn clean ``` https://eips.ethereum.org/assets/eip-7818/ https://eips.ethereum.org/assets/eip-7818/ ERC-7858 / # ERC-7858 This is reference implementation of ERC-7858 ## Implementation Describe ### Per-Token Expiry Default `ERC7858` is each token has its own independent start and end date, stored using `block.timestamp` or `block.number`. This provides flexibility, allowing tokens to expire at different dates/blocks. ### Epoch-based Expiry `ERC7858Epoch` similar to ERC-7818, this method enforces a shared lifetime duration for all tokens, ensuring they expire simultaneously. This can be useful for fixed-term subscriptions or time-based access control. ## Usage #### Install Dependencies ```bash yarn install ``` #### Compile the Contract Compile the reference implementation ```bash yarn compile ``` #### Run Tests Execute the provided test suite to verify the contract's functionality and integrity ```bash yarn test ``` ### Cleaning Build Artifacts To clean up compiled files and artifacts generated during testing or deployment ```bash yarn clean ``` https://eips.ethereum.org/assets/eip-7858/ https://eips.ethereum.org/assets/eip-7858/ NTT-EIP as a building block for FALCON, DILITHIUM and STARK verifiers / # NTT-EIP as a building block for FALCON, DILITHIUM and STARK verifiers This repository contains the EIP for NTT transform, along with a python reference code, and a solidity implementation. ## Context ### The threat With the release of Willow cheap, the concern for quantum threat against Ethereum seems to accelerate. Post by [Asanso](https://ethresear.ch/t/so-you-wanna-post-quantum-ethereum-transaction-signature/21291) and [PMiller](https://ethresear.ch/t/tidbits-of-post-quantum-eth/21296) summarize those stakes and possible solutions. Those solutions include use of lattice based signatures such as Dillithium or FALCON (the latter being more optimized for onchain constraints), STARKs and FHE. There is a consensus in the cryptographic research community around lattices as the future of asymetric protocols, and STARKs won the race for ZKEVMs implementation (as used by Scroll, Starknet and ZKsync). Those protocols have in common to require fast polynomial multiplication over prime fields, and use NTT (a special [FFT](https://vitalik.eth.limo/general/2019/05/12/fft.html) adapted to prime fields). While in the past Montgomery multipliers over elliptic curve fields were the critical target of optimizations (both hardware and software), NTT optimization is the key to a performant PQ implementation. ### Discussion In the past Ethereum chose specificity by picking secp256k1 as its sole candidate for signature. Later, after dedicated hardware and proving systems working on other hardwares were realeased, a zoo of EIP flourished to propose alternative curves. There where attempt to have higher level EIPs to enable all of those at once, such as EWASM, SIMD, EVMMAX, or RIP7696 (by decreasing order of genericity and complexity). Picking NTT as EIP instead of a given scheme would provide massive gas cost reduction for all schemes relying on it. - **pros** : massive reduction to all cited protocols, more agility for evolutions. - **cons**: requires to be wrapped into implementations, not optimal for a given target compared to dedicated EIP, not stateless. ## Overview The NTT operates on sequences of numbers (often coefficients of polynomials) in a modular arithmetic system. It maps these sequences into a different domain where convolution operations (e.g., polynomial multiplication) become simpler and faster, akin to how FFT simplifies signal convolution. Compared to FFT which uses root of unity in complex plane, NTT uses roots of unity in a finite field or ring. The NTT is based on the Discrete Fourier Transform (DFT), defined as: $$ X[k] = \sum_{j=0}^{N-1} x[j] \cdot \omega^{j \cdot k} \mod q$$ Where: - $x[j]$: Input sequence of length N. - $X[k]$: Transformed sequence, - $q$: A prime modulus, - $\omega$: A primitive N-th root of unity modulo $q$, with $\omega^N \equiv 1 \mod q \quad \text{and} \quad \omega^k \not\equiv 1 \mod q \; \forall \; 0 < k < N$ NTT computation uses the a similar approach as Cooley-Tukey algorithm to provide a O(N log N) complexity. The NTT algorithm transforms a sequence $(x[j])$ to $(X[k])$ using modular arithmetic. It is invertible, allowing reconstruction of the original sequence via the Inverse NTT (INTT). The inverse process is similar but requires dividing by \(N\) (mod \(q\)) and using $(\omega^{-1}$) (the modular inverse of $\omega$). The following algorithm is extracted from [[LN16]](https://eprint.iacr.org/2016/504.pdf), and describe how to compute the NTT when $R_q= \mathbb{Z}_q[X]/X^n+1$ (Negative Wrap Convolution). ![alt text](/assets/eip-7885/image.png) The Inverse NTT is computed through the following algorithm: ![alt text](/assets/eip-7885/image-1.png) ## Benchmarks ### Python | Field | $n$ | Recursive NTT (Tetration) | Iterative NTT (ZKNox) | Iterative InvNTT (ZKNox)| |-|-|-|-|-| |Falcon | 512 | 761 μs | 528 μs | 561 μs | |Falcon | 1024 | 1642 μs | 1076 μs | 1199 μs | |Dilithium| 128 | 165 μs | 114 μs | 113 μs | |Dilithium| 256 | 371 μs | 258 μs | 260 μs | |BabyBear | 256 | 531 μs | 389 μs | 404 μs | The recursive inverse NTT is very costly because of the required inversions. For Falcon, the field is small enough so that field inversions can be precomputed, but the cost is still higher than the iterative inverse NTT. The field arithmetic has not been optimized. In the case of BabyBear, this becomes significant and so the comparison is not really significant. ### Solidity | Function | Description | gas cost | Tests Status | |------------------------|---------------------|---------------------|---------------------| | NTT recursive | original gas cost from [falcon-solidity](https://github.com/Tetration-Lab/falcon-solidity/blob/main/src/Falcon.sol) | 6.9M | OK| | InvNTT recursive | original gas cost from [falcon-solidity](https://github.com/Tetration-Lab/falcon-solidity/blob/main/src/Falcon.sol) | 7.8M | OK| | Full Falcon verification | original gas cost from [falcon-solidity](https://github.com/Tetration-Lab/falcon-solidity/blob/main/src/Falcon.sol) | 24 M| OK| | NTT iterative | ZKNOX | 4M | OK| | InvNTT iterative | ZKNOX | 4.2M | OK| | Full Falcon verification | ZKNOX | 8.5 M| OK| ### Yul Further optimizations are reached by using Yul for critical sections and using the CODECOPY and EXTCODECOPY trick detailed in of [[RD23]](https://eprint.iacr.org/2023/939.pdf) (section 3.3, "Hacking EVM memory access cost"). | Function | Description | gas cost | Tests Status | |------------------------|---------------------|---------------------|---------------------| | ntt.NTTFW | ZKNOX_NTTFW, iterative yuled | 1.9M | OK| | falcon.verify_opt | Full falcon verification with precomputated pubkey | 3.6M | OK| ### Go Ethereum (WIP) ZKNOX is planning a client implementation for node of the considered EIP. ## Conclusion We provided an optimized version of FALCON, using an optimized version of NTT. This code can be used to speed up Stark verification as well as other lattices primitives (Dilithium, Kyber, etc.). While it seems achievable to use FALCON as a progressive precompile, the cost remains very high. Using a client implementation with NTT-EIP (in a Geth fork for example), ETHEREUM could become from a PQ-Friendly and ZK-Friendly chain. This work is supported by the Ethereum Foundation. ## References - [[LN16]](https://eprint.iacr.org/2016/504.pdf) Speeding up the Number Theoretic Transform for Faster Ideal Lattice-Based Cryptography. Patrick Longa, Michael Naehrig. - [[EIP616]](https://eips.ethereum.org/EIPS/eip-616) EIP-616: SIMD Operations for the EVM. Greg Colvin. - [[RD23]](https://eprint.iacr.org/2023/939.pdf) Speeding up elliptic computations for Ethereum Account Abstraction. Renaud Dubois. - [[DILITHIUM]](https://eprint.iacr.org/2017/633.pdf) CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme. Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, Peter Schwabe, Gregor Seiler and Damien Stehlé. https://eips.ethereum.org/assets/eip-7885/ https://eips.ethereum.org/assets/eip-7885/ Optimism-geth with NTT Precompiles (liboqs Implementation) / # Optimism-geth with NTT Precompiles (liboqs Implementation) Fork of `op-geth` with precompiled contracts for Number Theoretic Transform (NTT) operations using open-quantum-safe liboqs via CGO bindings, enabling efficient on-chain post-quantum cryptographic operations. ## Precompiled Contracts | Address | Name | Description | | ------- | --------- | ---------------------------------------------------------------------- | | `0x12` | NTT_FW | Forward NTT using liboqs (Falcon-512/1024, ML-DSA) | | `0x13` | NTT_INV | Inverse NTT using liboqs (same schemes as NTT_FW) | | `0x14` | VECMULMOD | Element-wise modular multiplication: `result[i] = (a[i] * b[i]) mod q` | | `0x15` | VECADDMOD | Element-wise modular addition: `result[i] = (a[i] + b[i]) mod q` | ### Supported Schemes | Scheme | Ring Degree | Modulus | Element Size | | ----------- | ----------- | ------- | ---------------- | | Falcon-512 | 512 | 12289 | uint16 (2 bytes) | | Falcon-1024 | 1024 | 12289 | uint16 (2 bytes) | | ML-DSA | 256 | 8380417 | int32 (4 bytes) | ## Installation ### 1. Install liboqs with NTT CGO Bindings ```bash # Clone and install dependencies git clone -b feature/ntt-cgo-bindings https://github.com/yhl125/liboqs.git sudo apt install astyle cmake gcc ninja-build libssl-dev python3-pytest python3-pytest-xdist unzip xsltproc doxygen graphviz python3-yaml valgrind pkg-config # Build liboqs and Go bindings cd liboqs/bindings/go make all ``` ### 2. Configure Environment ```bash # Set paths (adjust to your installation directory) export PKG_CONFIG_PATH=/path/to/liboqs/bindings/go/.config:$PKG_CONFIG_PATH export DYLD_LIBRARY_PATH=/path/to/liboqs/build/lib:$DYLD_LIBRARY_PATH # macOS export LD_LIBRARY_PATH=/path/to/liboqs/build/lib:$LD_LIBRARY_PATH # Linux ``` ### 3. Build op-geth ```bash make geth ``` ## API Reference ### NTT_FW (0x12) - Forward Transform Transforms coefficients into NTT domain using liboqs. **Input:** ``` [0:4] ring_degree (uint32, big-endian) [4:12] modulus (uint64, big-endian) [12:*] coefficients (Falcon: uint16×N, ML-DSA: int32×N, big-endian) ``` **Output:** NTT-transformed coefficients (same format as input) **Gas Cost:** - Falcon-512: 500 gas (~9.4μs, 53 mgas/s) - Falcon-1024: 1,080 gas (~20.4μs, 53 mgas/s) - ML-DSA: 256 gas (~4.8μs, 53 mgas/s) ### NTT_INV (0x13) - Inverse Transform Transforms NTT domain coefficients back to standard representation. **Input:** Same as NTT_FW (coefficients in NTT domain) **Output:** Coefficients in standard representation **Gas Cost:** - Falcon-512: 500 gas (~9.4μs, 53 mgas/s) - Falcon-1024: 1,080 gas (~20.3μs, 53 mgas/s) - ML-DSA: 340 gas (~6.4μs, 53 mgas/s) ### VECMULMOD (0x14) - Vector Multiplication Element-wise modular multiplication in NTT domain. **Input:** ``` [0:4] ring_degree (uint32, big-endian) [4:12] modulus (uint64, big-endian) [12:12+n*size] vector_a [12+n*size:*] vector_b ``` **Output:** Element-wise product `(a[i] * b[i]) mod q` **Gas Cost:** `ceil(0.32 × n)` - Falcon-512: 164 gas (~2.9μs, 56 mgas/s) - Falcon-1024: 328 gas (~6.0μs, 55 mgas/s) - ML-DSA: 82 gas (~2.0μs, 42 mgas/s) ### VECADDMOD (0x15) - Vector Addition Element-wise modular addition. **Input:** Same as VECMULMOD **Output:** Element-wise sum `(a[i] + b[i]) mod q` **Gas Cost:** `ceil(0.3 × n)` - Falcon-512: 154 gas (~2.8μs, 55 mgas/s) - Falcon-1024: 308 gas (~5.8μs, 53 mgas/s) - ML-DSA: 77 gas (~1.6μs, 47 mgas/s) ## Testing ```bash cd core/vm # All NTT tests go test -v -run TestPrecompiled.*NTT # Specific tests go test -v -run TestPrecompiledNTT_FW go test -v -run TestPrecompiledNTT_VECMULMOD # Benchmarks go test -bench=BenchmarkPrecompiledNTT -benchtime=5s ``` **Test Coverage:** - Scheme detection (Falcon-512/1024, ML-DSA) - Input validation (malformed inputs, invalid parameters) - Round-trip verification (`INTT(NTT(x)) = x`) - Cross-scheme isolation - Performance benchmarks with crypto standards ### Benchmark Results Benchmarks were run on an Intel(R) Xeon(R) CPU @ 2.20GHz. For detailed results, please see the files below: - [Ecrecover Benchmark Test Results](/assets/eip-7885/op-geth/cgo/benchmark_results/BenchmarkPrecompiledEcrecover) - [NTT & NTT Vector Operations Benchmark Test Results](/assets/eip-7885/op-geth/cgo/benchmark_results/BenchmarkPrecompiledNTT) https://eips.ethereum.org/assets/eip-7885/op-geth/cgo/ https://eips.ethereum.org/assets/eip-7885/op-geth/cgo/ Optimism-geth with Pure Go NTT Precompiles / # Optimism-geth with Pure Go NTT Precompiles Fork of `op-geth` with precompiled contracts for Number Theoretic Transform (NTT) operations implemented in pure Go, enabling efficient on-chain post-quantum cryptographic operations without external dependencies. ## Precompiled Contracts | Address | Name | Description | | ------- | --------- | ---------------------------------------------------------------------- | | `0x12` | NTT_FW | Forward NTT (Falcon-512/1024, ML-DSA) | | `0x13` | NTT_INV | Inverse NTT (Falcon-512/1024, ML-DSA) | | `0x14` | VECMULMOD | Element-wise modular multiplication: `result[i] = (a[i] * b[i]) mod q` | | `0x15` | VECADDMOD | Element-wise modular addition: `result[i] = (a[i] + b[i]) mod q` | ### Supported Schemes | Scheme | Ring Degree | Modulus | Element Size | | ----------- | ----------- | ------- | ---------------- | | Falcon-512 | 512 | 12289 | uint16 (2 bytes) | | Falcon-1024 | 1024 | 12289 | uint16 (2 bytes) | | ML-DSA | 256 | 8380417 | int32 (4 bytes) | ## Implementation Details This implementation uses **pure Go** for all NTT operations, located in `crypto/ntt/`: - `falcon.go`: Falcon NTT with Montgomery arithmetic - `falcon_tables.go`: Pre-computed twiddle factors for Falcon - `dilithium.go`: ML-DSA/Dilithium NTT implementation - `dilithium_tables.go`: Pre-computed zetas for ML-DSA ## API Reference ### NTT_FW (0x12) - Forward Transform Transforms coefficients into NTT domain. **Input:** ``` [0:4] ring_degree (uint32, big-endian) [4:12] modulus (uint64, big-endian) [12:*] coefficients (Falcon: uint16×N, ML-DSA: int32×N, big-endian) ``` **Output:** NTT-transformed coefficients (same format as input) **Gas Cost:** - Falcon-512: 790 gas - Falcon-1024: 1,750 gas - ML-DSA: 220 gas ### NTT_INV (0x13) - Inverse Transform Transforms NTT domain coefficients back to standard representation. **Input:** Same as NTT_FW (coefficients in NTT domain) **Output:** Coefficients in standard representation **Gas Cost:** - Falcon-512: 790 gas - Falcon-1024: 1,750 gas - ML-DSA: 270 gas ### VECMULMOD (0x14) - Vector Multiplication Element-wise modular multiplication in NTT domain. **Input:** ``` [0:4] ring_degree (uint32, big-endian) [4:12] modulus (uint64, big-endian) [12:12+n*size] vector_a [12+n*size:*] vector_b ``` **Output:** Element-wise product `(a[i] * b[i]) mod q` **Gas Cost:** `ceil(0.32 × n)` - Falcon-512: 164 gas - Falcon-1024: 328 gas - ML-DSA: 82 gas ### VECADDMOD (0x15) - Vector Addition Element-wise modular addition. **Input:** Same as VECMULMOD **Output:** Element-wise sum `(a[i] + b[i]) mod q` **Gas Cost:** `ceil(0.3 × n)` - Falcon-512: 154 gas - Falcon-1024: 308 gas - ML-DSA: 77 gas ## Testing ```bash cd core/vm # All NTT tests go test -v -run TestPrecompiled.*NTT go test -v -run TestPrecompiledVectorOp # Benchmarks go test -bench=BenchmarkPrecompiledNTT ``` **Test Coverage:** - Scheme detection (Falcon-512/1024, ML-DSA) - Input validation (malformed inputs, invalid parameters) - Round-trip verification (`INTT(NTT(x)) = x`) - Cross-scheme isolation - Performance benchmarks ### Benchmark Results Benchmarks were run on an Intel(R) Xeon(R) CPU @ 2.20GHz. For detailed results, please see: - [Ecrecover Benchmark Test Results](/assets/eip-7885/op-geth/nocgo/benchmark_results/BenchmarkPrecompiledEcrecover) - [NTT & NTT Vector Operations Benchmark Test Results](/assets/eip-7885/op-geth/nocgo/benchmark_results/BenchmarkPrecompiledNTT) https://eips.ethereum.org/assets/eip-7885/op-geth/nocgo/ https://eips.ethereum.org/assets/eip-7885/op-geth/nocgo/ NTT / # NTT Generic implementation of the Number Theoretic Transform in the context of cryptography applications. We provide tests for various NTT-friendly rings, including Falcon's ring with `q = 12*1024+1` and the defining polynomial `x¹⁰²⁴+1`. The implementation requires the file `ntt_constants.py`, generated using `python generate_constants.py`. ## Install ``` make install ``` ## Tests For running all tests: ``` make test ``` For running a specific test, use: ``` make test TEST=test_ntt_recursive.TestNTTRecursive.test_ntt_intt ``` ## Benchmarks For running the benchmarks: ``` make bench ``` Note that the field arithmetic is not optimized. For example, Montgomery multiplication is not implemented here. https://eips.ethereum.org/assets/eip-7885/pythonref/ https://eips.ethereum.org/assets/eip-7885/pythonref/ ERC-7943 uRWA Minimal Package / # ERC-7943 uRWA Minimal Package ## Install dependencies ```bash forge install OpenZeppelin/openzeppelin-contracts forge install foundry-rs/forge-std ``` ## Build ```bash forge build ``` ## Test ```bash forge test -vv ``` ## Gas report ```bash forge test --gas-report ``` ## Coverage ```bash forge coverage ``` https://eips.ethereum.org/assets/eip-7943/ https://eips.ethereum.org/assets/eip-7943/ KAT vectors / # KAT vectors We provide two files containing Known Answer Test vectors: - [mldsa_nist.rsp](/assets/eip-8051/mldsa_nist.rsp) containing the NIST submission KAT file for security level II, - [mldsa_evm.rsp](/assets/eip-8051/mldsa_evm.rsp) containing test vectors for the EVM-friendly version with the same format as NIST. https://eips.ethereum.org/assets/eip-8051/ https://eips.ethereum.org/assets/eip-8051/ / Groups reference implementation assets - After creating the Ethereum Magicians discussion, update `discussions-to` in `ERCS/erc-8063.md` with the live URL. - Contracts: - `IERC8063.sol`: interface - `ERC8063.sol`: minimal implementation - `ERC8063ERC20.sol`: optional ERC-20 compatibility implementation (decimals=0) https://eips.ethereum.org/assets/eip-8063/ https://eips.ethereum.org/assets/eip-8063/ / <?xml version="1.0" encoding="utf-8"?>{% if page.xsl %}<?xml-stylesheet type="text/xml" href="{{ '/feed.xslt.xml' | absolute_url }}"?>{% endif %}<feed xmlns="http://www.w3.org/2005/Atom" {% if site.lang %}xml:lang="{{ site.lang }}"{% endif %}><generator uri="https://jekyllrb.com/" version="{{ jekyll.version }}">Jekyll</generator><link href="{{ page.url | absolute_url }}" rel="self" type="application/atom+xml" /><link href="{{ '/' | absolute_url }}" rel="alternate" type="text/html" {% if site.lang %}hreflang="{{ site.lang }}" {% endif %}/><updated>{{ site.time | date_to_xmlschema }}</updated><id>{{ page.url | absolute_url | xml_escape }}</id>{% assign title = site.title | default: site.name %}{% if page.collection != "posts" %}{% assign collection = page.collection | capitalize %}{% assign title = title | append: " | " | append: collection %}{% endif %}{% if page.category %}{% assign category = page.category | capitalize %}{% assign title = title | append: " | " | append: category %}{% endif %}{% if title %}<title type="html">{{ title | smartify | xml_escape }}</title>{% endif %}{% if site.description %}<subtitle>{{ site.description | xml_escape }}</subtitle>{% endif %}{% if site.author %}<author><name>{{ site.author.name | default: site.author | xml_escape }}</name>{% if site.author.email %}<email>{{ site.author.email | xml_escape }}</email>{% endif %}{% if site.author.uri %}<uri>{{ site.author.uri | xml_escape }}</uri>{% endif %}</author>{% endif %}{% if page.tags %}{% assign posts = site.tags[page.tags] %}{% else %}{% assign posts = site[page.collection] %}{% endif %}{% if page.category %}{% assign posts = posts | where: "category", page.category %}{% endif %}{% unless site.show_drafts %}{% assign posts = posts | where_exp: "post", "post.draft != true" %}{% endunless %}{% assign posts = posts | sort: "date" | reverse %}{% assign posts_limit = site.feed.posts_limit | default: 10 %}{% for post in posts limit: posts_limit %}<entry{% if post.lang %}{{" "}}xml:lang="{{ post.lang }}"{% endif %}>{% assign post_title = post.title | smartify | strip_html | normalize_whitespace | xml_escape %}<title type="html">{{ post_title }}</title><link href="{{ post.url | absolute_url }}" rel="alternate" type="text/html" title="{{ post_title }}" /><published>{{ post.date | date_to_xmlschema }}</published><updated>{{ post.last_modified_at | default: post.date | date_to_xmlschema }}</updated><id>{{ post.id | absolute_url | xml_escape }}</id>{% assign excerpt_only = post.feed.excerpt_only | default: site.feed.excerpt_only %}{% unless excerpt_only %}<content type="html" xml:base="{{ post.url | absolute_url | xml_escape }}">{{ post.content | strip | xml_escape }}</content>{% endunless %}{% assign post_author = post.author | default: post.authors[0] | default: site.author %}{% assign post_author = site.data.authors[post_author] | default: post_author %}{% assign post_author_email = post_author.email | default: nil %}{% assign post_author_uri = post_author.uri | default: nil %}{% assign post_author_name = post_author.name | default: post_author %}<author><name>{{ post_author_name | default: "" | xml_escape }}</name>{% if post_author_email %}<email>{{ post_author_email | xml_escape }}</email>{% endif %}{% if post_author_uri %}<uri>{{ post_author_uri | xml_escape }}</uri>{% endif %}</author>{% if post.category %}<category term="{{ post.category | xml_escape }}" />{% elsif post.categories %}{% for category in post.categories %}<category term="{{ category | xml_escape }}" />{% endfor %}{% endif %}{% for tag in post.tags %}<category term="{{ tag | xml_escape }}" />{% endfor %}{% if post.excerpt and post.excerpt != empty %}<summary type="html">{{ post.excerpt | strip_html | normalize_whitespace | xml_escape }}</summary>{% endif %}{% assign post_image = post.image.path | default: post.image %}{% if post_image %}{% unless post_image contains "://" %}{% assign post_image = post_image | absolute_url %}{% endunless %}<media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="{{ post_image | xml_escape }}" /><media:content medium="image" url="{{ post_image | xml_escape }}" xmlns:media="http://search.yahoo.com/mrss/" />{% endif %}</entry>{% endfor %}</feed> https://eips.ethereum.org/feed.xml https://eips.ethereum.org/feed.xml EIP Purpose and Guidelines Meta/ ## What is an EIP? EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions. ## EIP Rationale We intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally, each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library. ## EIP Types There are three types of EIP: - A **Standards Track EIP** describes any change that affects most or all Ethereum implementations, such as: a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the [formal specification](https://github.com/ethereum/yellowpaper). Furthermore, Standards Track EIPs can be broken down into the following categories: - **Core**: improvements requiring a consensus fork (e.g. [EIP-5](/EIPS/eip-5), [EIP-101](/EIPS/eip-101)), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of [EIP-86](/EIPS/eip-86)). - **Networking**: includes improvements around [devp2p](https://github.com/ethereum/devp2p/blob/readme-spec-links/rlpx.md) ([EIP-8](/EIPS/eip-8)) and [Light Ethereum Subprotocol](https://ethereum.org/en/developers/docs/nodes-and-clients/#light-node), as well as proposed improvements to network protocol specifications of [whisper](https://github.com/ethereum/go-ethereum/issues/16013#issuecomment-364639309) and [swarm](https://github.com/ethereum/go-ethereum/pull/2959). - **Interface**: includes improvements around language-level standards like method names ([EIP-6](/EIPS/eip-6)) and [contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html). - **ERC**: application-level standards and conventions, including contract standards such as token standards ([ERC-20](/EIPS/eip-20)), name registries ([ERC-137](/EIPS/eip-137)), URI schemes, library/package formats, and wallet formats. - A **Meta EIP** describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP. - An **Informational EIP** describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice. It is highly recommended that a single EIP contain a single key proposal or new idea. The more focused the EIP, the more successful it tends to be. A change to one client doesn't require an EIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does. An EIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. ### Special requirements for Core EIPs If a **Core** EIP mentions or proposes changes to the EVM (Ethereum Virtual Machine), it should refer to the instructions by their mnemonics and define the opcodes of those mnemonics at least once. A preferred way is the following: ``` REVERT (0xfe) ``` ## EIP Work Flow ### Shepherding an EIP Parties involved in the process are you, the champion or *EIP author*, the [*EIP editors*](#eip-editors), and the [*Ethereum Core Developers*](https://github.com/ethereum/pm). Before you begin writing a formal EIP, you should vet your idea. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread on [the Ethereum Magicians forum](https://ethereum-magicians.org/) to do this. Once the idea has been vetted, your next responsibility will be to present (by means of an EIP) the idea to the reviewers and all interested parties, invite editors, developers, and the community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your EIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core EIP will be much greater than for an ERC and the EIP will need sufficient interest from the Ethereum client teams. Negative community feedback will be taken into consideration and may prevent your EIP from moving past the Draft stage. ### Core EIPs For Core EIPs, given that they require client implementations to be considered **Final** (see "EIPs Process" below), you will need to either provide an implementation for clients or convince clients to implement your EIP. The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an [AllCoreDevs agenda GitHub Issue](https://github.com/ethereum/pm/issues). The AllCoreDevs call serves as a way for client implementers to do three things. First, to discuss the technical merits of EIPs. Second, to gauge what other clients will be implementing. Third, to coordinate EIP implementation for network upgrades. These calls generally result in a "rough consensus" around what EIPs should be implemented. This "rough consensus" rests on the assumptions that EIPs are not contentious enough to cause a network split and that they are technically sound. :warning: The EIPs process and AllCoreDevs call were not designed to address contentious non-technical issues, but, due to the lack of other ways to address these, often end up entangled in them. This puts the burden on client implementers to try and gauge community sentiment, which hinders the technical coordination function of EIPs and AllCoreDevs calls. If you are shepherding an EIP, you can make the process of building community consensus easier by making sure that [the Ethereum Magicians forum](https://ethereum-magicians.org/) thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented. *In short, your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.* ### EIP Process The following is the standardization process for all EIPs in all tracks: ![EIP Status Diagram](/assets/eip-1/EIP-process-update.jpg) **Idea** - An idea that is pre-draft. This is not tracked within the EIP Repository. **Draft** - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted. **Review** - An EIP Author marks an EIP as ready for and requesting Peer Review. **Last Call** - This is the final review window for an EIP before it is moved to `Final`. An EIP enters `Last Call` when the specification is stable and the author opens a PR with a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to `Review`. **Final** - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications. A PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it. **Stagnant** - Any EIP in `Draft` or `Review` or `Last Call` if inactive for a period of 6 months or greater is moved to `Stagnant`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `Draft` or its earlier status. If not resurrected, a proposal may stay forever in this status. >*EIP Authors are notified of any algorithmic change to the status of their EIP* **Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at a later date, it is considered a new proposal. **Living** - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1. ## What belongs in a successful EIP? Each EIP should have the following parts: - Preamble - RFC 822 style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](/EIPS/eip-1#eip-header-preamble) for details. - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. - Motivation *(optional)* - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident. - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others). - Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should discuss important objections or concerns raised during discussion around the EIP. - Backwards Compatibility *(optional)* - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backward incompatibilities, but this section must be included if backward incompatibilities exist. - Test Cases *(optional)* - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs) or included in `../assets/eip-###/<filename>`. This section may be omitted for non-Core proposals. - Reference Implementation *(optional)* - An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. This section may be omitted for all EIPs. - Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g., include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. - Copyright Waiver - All EIPs must be in the public domain. The copyright waiver MUST link to the license file and use the following wording: `Copyright and related rights waived via [CC0](/LICENSE).` ## EIP Formats and Templates EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) format. There is a [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) and [contributor](https://github.com/ethereum/EIPs/blob/master/CONTRIBUTING.md) guidelines to follow. ## EIP Header Preamble Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. `eip`: *EIP number* `title`: *The EIP title is a few words, not a complete sentence* `description`: *Description is one full (short) sentence* `author`: *The list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.* `discussions-to`: *The url pointing to the official discussion thread* `status`: *Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living* `last-call-deadline`: *The date last call period ends on* (Optional field, only needed when status is `Last Call`) `type`: *One of `Standards Track`, `Meta`, or `Informational`* `category`: *One of `Core`, `Networking`, `Interface`, or `ERC`* (Optional field, only needed for `Standards Track` EIPs) `created`: *Date the EIP was created on* `requires`: *EIP number(s)* (Optional field) `withdrawal-reason`: *A sentence explaining why the EIP was withdrawn.* (Optional field, only needed when status is `Withdrawn`) Headers that permit lists must separate elements with commas. Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd). ### `author` header The `author` header lists the names, email addresses or usernames of the authors/owners of the EIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the `author` header value must be: > Random J. User &lt;address@dom.ain&gt; or > Random J. User (@username) or > Random J. User (@username) &lt;address@dom.ain&gt; if the email address and/or GitHub username is included, and > Random J. User if neither the email address nor the GitHub username are given. At least one author must use a GitHub username, in order to get notified on change requests and have the capability to approve or reject them. ### `discussions-to` header While an EIP is a draft, a `discussions-to` header will indicate the URL where the EIP is being discussed. The preferred discussion URL is a topic on [Ethereum Magicians](https://ethereum-magicians.org/). The URL cannot point to Github pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics). ### `type` header The `type` header specifies the type of EIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC). ### `category` header The `category` header specifies the EIP's category. This is required for standards-track EIPs only. ### `created` header The `created` header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. ### `requires` header EIPs may have a `requires` header, indicating the EIP numbers that this EIP depends on. If such a dependency exists, this field is required. A `requires` dependency is created when the current EIP cannot be understood or implemented without a concept or technical element from another EIP. Merely mentioning another EIP does not necessarily create such a dependency. ## Linking to External Resources Other than the specific exceptions listed below, links to external resources **SHOULD NOT** be included. External resources may disappear, move, or change unexpectedly. The process governing permitted external resources is described in [EIP-5757](/EIPS/eip-5757). ### Execution Client Specifications Links to the Ethereum Execution Client Specifications may be included using normal markdown syntax, such as: ```markdown [Ethereum Execution Client Specifications](https://github.com/ethereum/execution-specs/blob/9a1f22311f517401fed6c939a159b55600c454af/README.md) ``` Which renders to: [Ethereum Execution Client Specifications](https://github.com/ethereum/execution-specs/blob/9a1f22311f517401fed6c939a159b55600c454af/README.md) Permitted Execution Client Specifications URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^(https://github.com/ethereum/execution-specs/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$ ``` ### Execution Specification Tests Links to the Ethereum Execution Specification Tests (EEST) may be included using normal markdown syntax, such as: ```markdown [Ethereum Execution Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/c9b9307ff320c9bb0ecb9a951aeab0da4d9d1684/README.md) ``` Which renders to: [Ethereum Execution Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/c9b9307ff320c9bb0ecb9a951aeab0da4d9d1684/README.md) Permitted Execution Specification Tests URLs must anchor to a specific commit, and so must match one of these regular expressions: ```regex ^https://(www\.)?github\.com/ethereum/execution-spec-tests/(blob|tree)/[a-f0-9]{40}/.+$ ``` ```regex ^https://(www\.)?github\.com/ethereum/execution-spec-tests/commit/[a-f0-9]{40}$ ``` ### Consensus Layer Specifications Links to specific commits of files within the Ethereum Consensus Layer Specifications may be included using normal markdown syntax, such as: ```markdown [Beacon Chain](https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md) ``` Which renders to: [Beacon Chain](https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md) Permitted Consensus Layer Specifications URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^https://github.com/ethereum/consensus-specs/(blob|commit)/[0-9a-f]{40}/.*$ ``` ### Networking Specifications Links to specific commits of files within the Ethereum Networking Specifications may be included using normal markdown syntax, such as: ```markdown [Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md) ``` Which renders as: [Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md) Permitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^https://github.com/ethereum/devp2p/(blob|commit)/[0-9a-f]{40}/.*$ ``` ### Portal Specifications Links to specific commits of files within the Ethereum Portal Specifications may be included using normal markdown syntax, such as: ```markdown [Portal Wire Protocol](https://github.com/ethereum/portal-network-specs/blob/5e321567b67bded7527355be714993c24371de1a/portal-wire-protocol.md) ``` Which renders as: [Portal Wire Protocol](https://github.com/ethereum/portal-network-specs/blob/5e321567b67bded7527355be714993c24371de1a/portal-wire-protocol.md) Permitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^https://github.com/ethereum/portal-network-specs/(blob|commit)/[0-9a-f]{40}/.*$ ``` ### World Wide Web Consortium (W3C) Links to a W3C "Recommendation" status specification may be included using normal markdown syntax. For example, the following link would be allowed: ```markdown [Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/) ``` Which renders as: [Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/) Permitted W3C recommendation URLs MUST anchor to a specification in the technical reports namespace with a date, and so MUST match this regular expression: ```regex ^https://www\.w3\.org/TR/[0-9][0-9][0-9][0-9]/.*$ ``` ### Web Hypertext Application Technology Working Group (WHATWG) Links to WHATWG specifications may be included using normal markdown syntax, such as: ```markdown [HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/) ``` Which renders as: [HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/) Permitted WHATWG specification URLs must anchor to a specification defined in the `spec` subdomain (idea specifications are not allowed) and to a commit snapshot, and so must match this regular expression: ```regex ^https:\/\/[a-z]*\.spec\.whatwg\.org/commit-snapshots/[0-9a-f]{40}/$ ``` Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard. ### Internet Engineering Task Force (IETF) Links to an IETF Request For Comment (RFC) specification may be included using normal markdown syntax, such as: ```markdown [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) ``` Which renders as: [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) Permitted IETF specification URLs MUST anchor to a specification with an assigned RFC number (meaning cannot reference internet drafts), and so MUST match this regular expression: ```regex ^https:\/\/www.rfc-editor.org\/rfc\/.*$ ``` ### Bitcoin Improvement Proposal Links to Bitcoin Improvement Proposals may be included using normal markdown syntax, such as: ```markdown [BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki) ``` Which renders to: [BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki) Permitted Bitcoin Improvement Proposal URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^(https://github.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\.mediawiki)$ ``` ### National Vulnerability Database (NVD) Links to the Common Vulnerabilities and Exposures (CVE) system as published by the National Institute of Standards and Technology (NIST) may be included, provided they are qualified by the date of the most recent change, using the following syntax: ```markdown [CVE-2023-29638 (2023-10-17T10:14:15)](https://nvd.nist.gov/vuln/detail/CVE-2023-29638) ``` Which renders to: [CVE-2023-29638 (2023-10-17T10:14:15)](https://nvd.nist.gov/vuln/detail/CVE-2023-29638) ### Chain Agnostic Improvement Proposals (CAIPs) Links to a Chain Agnostic Improvement Proposals (CAIPs) specification may be included using normal markdown syntax, such as: ```markdown [CAIP 10](https://github.com/ChainAgnostic/CAIPs/blob/5dd3a2f541d399a82bb32590b52ca4340b09f08b/CAIPs/caip-10.md) ``` Which renders to: [CAIP 10](https://github.com/ChainAgnostic/CAIPs/blob/5dd3a2f541d399a82bb32590b52ca4340b09f08b/CAIPs/caip-10.md) Permitted Chain Agnostic URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^(https://github.com/ChainAgnostic/CAIPs/blob/[0-9a-f]{40}/CAIPs/caip-[0-9]+\.md)$ ``` ### Ethereum Yellow Paper Links to the Ethereum Yellow Paper may be included using normal markdown syntax, such as: ```markdown [Ethereum Yellow Paper](https://github.com/ethereum/yellowpaper/blob/9c601d6a58c44928d4f2b837c0350cec9d9259ed/paper.pdf) ``` Which renders to: [Ethereum Yellow Paper](https://github.com/ethereum/yellowpaper/blob/9c601d6a58c44928d4f2b837c0350cec9d9259ed/paper.pdf) Permitted Yellow Paper URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^(https://github\.com/ethereum/yellowpaper/blob/[0-9a-f]{40}/paper\.pdf)$ ``` ### Execution Client Specification Tests Links to the Ethereum Execution Client Specification Tests may be included using normal markdown syntax, such as: ```markdown [Ethereum Execution Client Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/d5a3188f122912e137aa2e21ed2a1403e806e424/README.md) ``` Which renders to: [Ethereum Execution Client Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/d5a3188f122912e137aa2e21ed2a1403e806e424/README.md) Permitted Execution Client Specification Tests URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^(https://github.com/ethereum/execution-spec-tests/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-spec-tests/tree/[0-9a-f]{40}/.*)$ ``` ### Digital Object Identifier System Links qualified with a Digital Object Identifier (DOI) may be included using the following syntax: ````markdown This is a sentence with a footnote.[^1] [^1]: ```csl-json { "type": "article", "id": 1, "author": [ { "family": "Jameson", "given": "Hudson" } ], "DOI": "00.0000/a00000-000-0000-y", "title": "An Interesting Article", "original-date": { "date-parts": [ [2022, 12, 31] ] }, "URL": "https://sly-hub.invalid/00.0000/a00000-000-0000-y", "custom": { "additional-urls": [ "https://example.com/an-interesting-article.pdf" ] } } ``` ```` Which renders to: <!-- markdownlint-capture --> <!-- markdownlint-disable code-block-style --> This is a sentence with a footnote.[^1] [^1]: ```csl-json { "type": "article", "id": 1, "author": [ { "family": "Jameson", "given": "Hudson" } ], "DOI": "00.0000/a00000-000-0000-y", "title": "An Interesting Article", "original-date": { "date-parts": [ [2022, 12, 31] ] }, "URL": "https://sly-hub.invalid/00.0000/a00000-000-0000-y", "custom": { "additional-urls": [ "https://example.com/an-interesting-article.pdf" ] } } ``` <!-- markdownlint-restore --> See the [Citation Style Language Schema](https://resource.citationstyles.org/schema/v1.0/input/json/csl-data.json) for the supported fields. In addition to passing validation against that schema, references must include a DOI and at least one URL. The top-level URL field must resolve to a copy of the referenced document which can be viewed at zero cost. Values under `additional-urls` must also resolve to a copy of the referenced document, but may charge a fee. ### Execution API Specification Links to the Ethereum Execution API Specification may be included using normal markdown syntax, such as: ```markdown [Ethereum Execution API Specification](https://github.com/ethereum/execution-apis/blob/dd00287101e368752ba264950585dde4b61cdc17/README.md) ``` Which renders to: [Ethereum Execution API Specification](https://github.com/ethereum/execution-apis/blob/dd00287101e368752ba264950585dde4b61cdc17/README.md) Permitted Execution API Specification URLs must anchor to a specific commit, and so must match this regular expression: ```regex ^(https://github.com/ethereum/execution-apis/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-apis/tree/[0-9a-f]{40}/.*)$ ``` ## Linking to other EIPs References to other EIPs should follow the format `EIP-N` where `N` is the EIP number you are referring to. Each EIP that is referenced in an EIP **MUST** be accompanied by a relative markdown link the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. The link **MUST** always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main EIPs site, mirrors of the main EIP site, etc. For example, you would link to this EIP as `./eip-1.md`. ## Auxiliary Files Images, diagrams and auxiliary files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-N` (where **N** is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as `../assets/eip-1/image.png`. Prefer SVG diagrams, then PNG, and finally everything else. ## Transferring EIP Ownership It occasionally becomes necessary to transfer ownership of EIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred EIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the EIP process, or has fallen off the face of the 'net (i.e. is unreachable or isn't responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the EIP. We try to build consensus around an EIP, but if that's not possible, you can always submit a competing EIP. If you are interested in assuming ownership of an EIP, send a message asking to take over, addressed to both the original author and the EIP editor. If the original author doesn't respond to the email in a timely manner, the EIP editor will make a unilateral decision (it's not like such decisions can't be reversed :)). ## EIP Editors The current EIP editors are - Matt Garnett (@lightclient) - Sam Wilson (@SamWilsn) - Zainan Victor Zhou (@xinbenlv) - Gajinder Singh (@g11tech) - Jochem Brouwer (@jochem-brouwer) Emeritus EIP editors are - Alex Beregszaszi (@axic) - Casey Detrio (@cdetrio) - Gavin John (@Pandapip1) - Greg Colvin (@gcolvin) - Hudson Jameson (@Souptacular) - Martin Becze (@wanderer) - Micah Zoltu (@MicahZoltu) - Nick Johnson (@arachnid) - Nick Savers (@nicksavers) - Vitalik Buterin (@vbuterin) If you would like to become an EIP editor, please check [EIP-5069](/EIPS/eip-5069). ## EIP Editor Responsibilities For each new EIP that comes in, an editor does the following: - Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. - The title should accurately describe the content. - Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style If the EIP isn't ready, the editor will send it back to the author for revision, with specific instructions. Once the EIP is ready for the repository, the EIP editor will: - Assign an EIP number (generally incremental; editors can reassign if number sniping is suspected) - Merge the corresponding [pull request](https://github.com/ethereum/EIPs/pulls) - Send a message back to the EIP author with the next step. Many EIPs are written and maintained by developers with write access to the Ethereum codebase. The EIP editors monitor EIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. The editors don't pass judgment on EIPs. We merely do the administrative & editorial part. ## Style Guide ### Titles The `title` field in the preamble: - Should be in title case. - Should not include the word "standard" or any variation thereof; and - Should not include the EIP's number. ### Descriptions The `description` field in the preamble: - Should be in sentence case. - Should not include the word "standard" or any variation thereof; and - Should not include the EIP's number. ### EIP numbers When referring to an EIP with a `category` of `ERC`, it must be written in the hyphenated form `ERC-X` where `X` is that EIP's assigned number. When referring to EIPs with any other `category`, it must be written in the hyphenated form `EIP-X` where `X` is that EIP's assigned number. ### RFC 2119 and RFC 8174 EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.html) and [RFC 8174](https://www.ietf.org/rfc/rfc8174.html) for terminology and to insert the following at the beginning of the Specification section: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. Don't use RFC 2119 keywords (all-caps SHOULD/MUST/etc.) outside of the specification section. ## History This document was derived heavily from [Bitcoin's BIP-0001](https://github.com/bitcoin/bips) written by Amir Taaki which in turn was derived from [Python's PEP-0001](https://peps.python.org/). In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 27 Oct 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1 https://eips.ethereum.org/EIPS/eip-1 Homestead Hard-fork Changes Standards Track/Core ### Meta reference [Homestead](/EIPS/eip-606). ### Parameters | FORK_BLKNUM | CHAIN_NAME | |-----------------|-------------| | 1,150,000 | Main net | | 494,000 | Morden | | 0 | Future testnets | # Specification If `block.number >= HOMESTEAD_FORK_BLKNUM`, do the following: 1. The gas cost *for creating contracts via a transaction* is increased from 21,000 to 53,000, i.e. if you send a transaction and the to address is the empty string, the initial gas subtracted is 53,000 plus the gas cost of the tx data, rather than 21,000 as is currently the case. Contract creation from a contract using the `CREATE` opcode is unaffected. 2. All transaction signatures whose s-value is greater than `secp256k1n/2` are now considered invalid. The ECDSA recover precompiled contract remains unchanged and will keep accepting high s-values; this is useful e.g. if a contract recovers old Bitcoin signatures. 3. If contract creation does not have enough gas to pay for the final gas fee for adding the contract code to the state, the contract creation fails (i.e. goes out-of-gas) rather than leaving an empty contract. 4. Change the difficulty adjustment algorithm from the current formula: `block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) + int(2**((block.number // 100000) - 2))` (where the `int(2**((block.number // 100000) - 2))` represents the exponential difficulty adjustment component) to `block_diff = parent_diff + parent_diff // 2048 * max(1 - (block_timestamp - parent_timestamp) // 10, -99) + int(2**((block.number // 100000) - 2))`, where `//` is the integer division operator, eg. `6 // 2 = 3`, `7 // 2 = 3`, `8 // 2 = 4`. The `minDifficulty` still defines the minimum difficulty allowed and no adjustment may take it below this. # Rationale Currently, there is an excess incentive to create contracts via transactions, where the cost is 21,000, rather than contracts, where the cost is 32,000. Additionally, with the help of suicide refunds, it is currently possible to make a simple ether value transfer using only 11,664 gas; the code for doing this is as follows: ```python from ethereum import tester as t > from ethereum import utils > s = t.state() > c = s.abi_contract('def init():\n suicide(0x47e25df8822538a8596b28c637896b4d143c351e)', endowment=10**15) > s.block.get_receipts()[-1].gas_used 11664 > s.block.get_balance(utils.normalize_address(0x47e25df8822538a8596b28c637896b4d143c351e)) 1000000000000000 ``` This is not a particularly serious problem, but it is nevertheless arguably a bug. Allowing transactions with any s value with `0 < s < secp256k1n`, as is currently the case, opens a transaction malleability concern, as one can take any transaction, flip the s value from `s` to `secp256k1n - s`, flip the v value (`27 -> 28`, `28 -> 27`), and the resulting signature would still be valid. This is not a serious security flaw, especially since Ethereum uses addresses and not transaction hashes as the input to an ether value transfer or other transaction, but it nevertheless creates a UI inconvenience as an attacker can cause the transaction that gets confirmed in a block to have a different hash from the transaction that any user sends, interfering with user interfaces that use transaction hashes as tracking IDs. Preventing high s values removes this problem. Making contract creation go out-of-gas if there is not enough gas to pay for the final gas fee has the benefits that: - (i) it creates a more intuitive "success or fail" distinction in the result of a contract creation process, rather than the current "success, fail, or empty contract" trichotomy; - (ii) makes failures more easily detectable, as unless contract creation fully succeeds then no contract account will be created at all; and - (iii) makes contract creation safer in the case where there is an endowment, as there is a guarantee that either the entire initiation process happens or the transaction fails and the endowment is refunded. The difficulty adjustment change conclusively solves a problem that the Ethereum protocol saw two months ago where an excessive number of miners were mining blocks that contain a timestamp equal to `parent_timestamp + 1`; this skewed the block time distribution, and so the current block time algorithm, which targets a *median* of 13 seconds, continued to target the same median but the mean started increasing. If 51% of miners had started mining blocks in this way, the mean would have increased to infinity. The proposed new formula is roughly based on targeting the mean; one can prove that with the formula in use, an average block time longer than 24 seconds is mathematically impossible in the long term. The use of `(block_timestamp - parent_timestamp) // 10` as the main input variable rather than the time difference directly serves to maintain the coarse-grained nature of the algorithm, preventing an excessive incentive to set the timestamp difference to exactly 1 in order to create a block that has slightly higher difficulty and that will thus be guaranteed to beat out any possible forks. The cap of -99 simply serves to ensure that the difficulty does not fall extremely far if two blocks happen to be very far apart in time due to a client security bug or other black-swan issue. # Implementation This is implemented in Python here: 1. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L130 2. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L129 3. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L304 4. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/blocks.py#L42 Sun, 15 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-2 https://eips.ethereum.org/EIPS/eip-2 Addition of CALLDEPTH opcode Standards Track/Core # Abstract This is a proposal to add a new opcode, `CALLDEPTH`. The `CALLDEPTH` opcode would return the remaining available call stack depth. # Motivation There is a limit specifying how deep contracts can call other contracts; the call stack. The limit is currently `256`. If a contract invokes another contract (either via `CALL` or `CALLCODE`), the operation will fail if the call stack depth limit has been reached. This behaviour makes it possible to subject a contract to a "call stack attack" [1]. In such an attack, an attacker first creates a suitable depth of the stack, e.g. by recursive calls. After this step, the attacker invokes the targeted contract. If the targeted calls another contract, that call will fail. If the return value is not properly checked to see if the call was successful, the consequences could be damaging. Example: 1. Contract `A` wants to be invoked regularly, and pays Ether to the invoker in every block. 2. When contract `A` is invoked, it calls contracts `B` and `C`, which consumes a lot of gas. After invocation, contract `A` pays Ether to the caller. 3. Malicious user `X` ensures that the stack depth is shallow before invoking A. Both calls to `B` and `C` fail, but `X` can still collect the reward. It is possible to defend against this in two ways: 1. Check return value after invocation. 2. Check call stack depth experimentally. A library [2] by Piper Merriam exists for this purpose. This method is quite costly in gas. [1] a.k.a "shallow stack attack" and "stack attack". However, to be precise, the word ''stack'' has a different meaning within the EVM, and is not to be confused with the ''call stack''. [2] https://github.com/pipermerriam/ethereum-stack-depth-lib # Specification The opcode `CALLDEPTH` should return the remaining call stack depth. A value of `0` means that the call stack is exhausted, and no further calls can be made. # Rationale The actual call stack depth, as well as the call stack depth limit, are present in the EVM during execution, but just not available within the EVM. The implementation should be fairly simple and would provide a cheap and way to protect against call stack attacks. # Implementation Not implemented. Thu, 19 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-3 https://eips.ethereum.org/EIPS/eip-3 EIP Classification Meta/ # Abstract This document describes a classification scheme for EIPs, adapted from [BIP 123](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki). EIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards EIP belongs. # Motivation Ethereum is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementers a choice of whether to support them. In order to have a EIP process which more closely reflects the interoperability requirements, it is necessary to categorize EIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed. # Specification Standards EIPs are placed in one of four layers: 1. Consensus 2. Networking 3. API/RPC 4. Applications # 1. Consensus Layer The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence. The consensus layer is not concerned with how messages are propagated on a network. Disagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks. ## Soft Forks In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules. ## Hard Forks In a hard fork, structures that were invalid under the old rules become valid under the new rules. # 2. Networking Layer The networking layer specifies the Ethereum wire protocol (eth) and the Light Ethereum Subprotocol (les). RLPx is excluded and tracked in the [devp2p repository](https://github.com/ethereum/devp2p). Only a subset of subprotocols are required for basic node interoperability. Nodes can support further optional extensions. It is always possible to add new subprotocols without breaking compatibility with existing protocols, then gradually deprecate older protocols. In this manner, the entire network can be upgraded without serious risks of service disruption. # 3. API/RPC Layer The API/RPC layer specifies higher level calls accessible to applications. Support for these EIPs is not required for basic network interoperability but might be expected by some client applications. There's room at this layer to allow for competing standards without breaking basic network interoperability. # 4. Applications Layer The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data. Tue, 17 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-4 https://eips.ethereum.org/EIPS/eip-4 Gas Usage for `RETURN` and `CALL*` Standards Track/Core ### Abstract This EIP makes it possible to call functions that return strings and other dynamically-sized arrays. Currently, when another contract / function is called from inside the Ethereum Virtual Machine, the size of the output has to be specified in advance. It is of course possible to give a larger size, but gas also has to be paid for memory that is not written to, which makes returning dynamically-sized data both costly and inflexible to the extent that it is actually unusable. The solution proposed in this EIP is to charge gas only for memory that is actually written to at the time the `CALL` returns. ### Specification The gas and memory semantics for `CALL`, `CALLCODE` and `DELEGATECALL` (called later as `CALL*`) are changed in the following way (`CREATE` does not write to memory and is thus unaffected): Suppose the arguments to `CALL*` are `gas, address, value, input_start, input_size, output_start, output_size`, then, at the beginning of the opcode, gas for growing memory is only charged for `input_start + input_size`, but not for `output_start + output_size`. If the called contract returns data of size `n`, the memory of the calling contract is grown to `output_start + min(output_size, n)` (and the calling contract is charged gas for that) and the output is written to the area `[output_start, output_start + min(n, output_size))`. The calling contract can run out of gas both at the beginning of the opcode and at the end of the opcode. After the call, the `MSIZE` opcode should return the size the memory was actually grown to. ### Motivation In general, it is good practice to reserve a certain memory area for the output of a call, because letting a subroutine write to arbitrary areas in memory might be dangerous. On the other hand, it is often hard to know the output size of a call prior to performing the call: The data could be in the storage of another contract which is generally inaccessible and determining its size would require another call to that contract. Furthermore, charging gas for areas of memory that are not actually written to is unnecessary. This proposal tries to solve both problems: A caller can choose to provide a gigantic area of memory at the end of their memory area. The callee can "write" to it by returning and the caller is only charged for the memory area that is actually written. This makes it possible to return dynamic data like strings and dynamically-sized arrays in a very flexible way. It is even possible to determine the size of the returned data: If the caller uses `output_start = MSIZE` and `output_size = 2**256-1`, the area of memory that was actually written to is `(output_start, MSIZE)` (here, `MSIZE` as evaluated after the call). This is important because it allows "proxy" contracts which call other contracts whose interface they do not know and just return their output, i.e. they both forward the input and the output. For this, it is important that the caller (1) does not need to know the size of the output in advance and (2) can determine the size of the output after the call. ### Rationale This way of dealing with the problem requires a minimal change to the Ethereum Virtual Machine. Other means of achieving a similar goal would have changed the opcodes themselves or the number of their arguments. Another possibility would have been to only change the gas mechanics if `output_size` is equal to `2**256-1`. Since the main difficulty in the implementation is that memory has to be enlarged at two points in the code around `CALL`, this would not have been a simplification. At an earlier stage, it was proposed to also add the size of the returned data on the stack, but the `MSIZE` mechanism described above should be sufficient and is much better backwards compatible. Some comments are available at https://github.com/ethereum/EIPs/issues/8 ### Backwards Compatibility This proposal changes the semantics of contracts because contracts can access the gas counter and the size of memory. On the other hand, it is unlikely that existing contracts will suffer from this change due to the following reasons: Gas: The VM will not charge more gas than before. Usually, contracts are written in a way such that their semantics do not change if they use up less gas. If more gas were used, contracts might go out-of-gas if they perform a tight estimation for gas needed by sub-calls. Here, contracts might only return more gas to their callers. Memory size: The `MSIZE` opcode is typically used to allocate memory at a previously unused spot. The change in semantics affects existing contracts in two ways: 1. Overlaps in allocated memory. By using `CALL`, a contract might have wanted to allocate a certain slice of memory, even if that is not written to by the called contract. Subsequent uses of `MSIZE` to allocate memory might overlap with this slice that is now smaller than before the change. It is, though, unlikely that such contracts exist. 2. Memory addresses change. Rather general, if memory is allocated using `MSIZE`, the addresses of objects in memory will be different after the change. Contracts should all be written in a way, though, such that objects in memory are _relocatable_, i.e. their absolute position in memory and their relative position to other objects does not matter. This is of course not the case for arrays, but they are allocated in a single allocation and not with an intermediate `CALL`. ### Implementation VM implementers should take care not to grow the memory until the end of the call and after a check that sufficient gas is still available. Typical uses of the EIP include "reserving" `2**256-1` bytes of memory for the output. Python implementation: old: http://vitalik.ca/files/old.py new: http://vitalik.ca/files/new.py Sun, 22 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-5 https://eips.ethereum.org/EIPS/eip-5 Renaming SUICIDE opcode Standards Track/Interface ### Abstract The solution proposed in this EIP is to change the name of the `SUICIDE` opcode in Ethereum programming languages with `SELFDESTRUCT`. ### Motivation Mental health is a very real issue for many people and small notions can make a difference. Those dealing with loss or depression would benefit from not seeing the word suicide in our programming languages. By some estimates, 350 million people worldwide suffer from depression. The semantics of Ethereum's programming languages need to be reviewed often if we wish to grow our ecosystem to all types of developers. An Ethereum security audit commissioned by DEVolution, GmbH and [performed by Least Authority](https://github.com/LeastAuthority/ethereum-analyses/blob/master/README.md) recommended the following: > Replace the instruction name "suicide" with a less connotative word like "self-destruct", "destroy", "terminate", or "close", especially since that is a term describing the natural conclusion of a contract. The primary reason for us to change the term suicide is to show that people matter more than code and Ethereum is a mature enough of a project to recognize the need for a change. Suicide is a heavy subject and we should make every effort possible to not affect those in our development community who suffer from depression or who have recently lost someone to suicide. Ethereum is a young platform and it will cause less headaches if we implement this change early on in its life. ### Implementation `SELFDESTRUCT` is added as an alias of `SUICIDE` opcode (rather than replacing it). https://github.com/ethereum/solidity/commit/a8736b7b271dac117f15164cf4d2dfabcdd2c6fd https://github.com/ethereum/serpent/commit/1106c3bdc8f1bd9ded58a452681788ff2e03ee7c Sun, 22 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-6 https://eips.ethereum.org/EIPS/eip-6 DELEGATECALL Standards Track/Core ### Hard Fork [Homestead](/EIPS/eip-606) ### Parameters - Activation: - Block >= 1,150,000 on Mainnet - Block >= 494,000 on Morden - Block >= 0 on future testnets ### Overview Add a new opcode, `DELEGATECALL` at `0xf4`, which is similar in idea to `CALLCODE`, except that it propagates the sender and value from the parent scope to the child scope, i.e. the call created has the same sender and value as the original call. ### Specification `DELEGATECALL`: `0xf4`, takes 6 operands: - `gas`: the amount of gas the code may use in order to execute; - `to`: the destination address whose code is to be executed; - `in_offset`: the offset into memory of the input; - `in_size`: the size of the input in bytes; - `out_offset`: the offset into memory of the output; - `out_size`: the size of the scratch pad for the output. #### Notes on gas - The basic stipend is not given; `gas` is the total amount the callee receives. - Like `CALLCODE`, account creation never happens, so the upfront gas cost is always `schedule.callGas` + `gas`. - Unused gas is refunded as normal. #### Notes on sender - `CALLER` and `VALUE` behave exactly in the callee's environment as they do in the caller's environment. #### Other notes - The depth limit of 1024 is still preserved as normal. ### Rationale Propagating the sender and value from the parent scope to the child scope makes it much easier for a contract to store another address as a mutable source of code and ''pass through'' calls to it, as the child code would execute in essentially the same environment (except for reduced gas and increased callstack depth) as the parent. Use case 1: split code to get around 3m gas barrier ```python ~calldatacopy(0, 0, ~calldatasize()) if ~calldataload(0) < 2**253: ~delegate_call(msg.gas - 10000, $ADDR1, 0, ~calldatasize(), ~calldatasize(), 10000) ~return(~calldatasize(), 10000) elif ~calldataload(0) < 2**253 * 2: ~delegate_call(msg.gas - 10000, $ADDR2, 0, ~calldatasize(), ~calldatasize(), 10000) ~return(~calldatasize(), 10000) ... ``` Use case 2: mutable address for storing the code of a contract: ```python if ~calldataload(0) / 2**224 == 0x12345678 and self.owner == msg.sender: self.delegate = ~calldataload(4) else: ~delegate_call(msg.gas - 10000, self.delegate, 0, ~calldatasize(), ~calldatasize(), 10000) ~return(~calldatasize(), 10000) ``` The child functions called by these methods can now freely reference `msg.sender` and `msg.value`. ### Possible arguments against * You can replicate this functionality by just sticking the sender into the first twenty bytes of the call data. However, this would mean that code would need to be specially compiled for delegated contracts, and would not be usable in delegated and raw contexts at the same time. Sun, 15 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-7 https://eips.ethereum.org/EIPS/eip-7 devp2p Forward Compatibility Requirements for Homestead Standards Track/Networking ### Abstract This EIP introduces new forward-compatibility requirements for implementations of the devp2p Wire Protocol, the RLPx Discovery Protocol and the RLPx TCP Transport Protocol. Clients which implement EIP-8 behave according to Postel's Law: > Be conservative in what you do, be liberal in what you accept from others. ### Specification Implementations of **the devp2p Wire Protocol** should ignore the version number of hello packets. When sending the hello packet, the version element should be set to the highest devp2p version supported. Implementations should also ignore any additional list elements at the end of the hello packet. Similarly, implementations of **the RLPx Discovery Protocol** should not validate the version number of the ping packet, ignore any additional list elements in any packet, and ignore any data after the first RLP value in any packet. Discovery packets with unknown packet type should be discarded silently. The maximum size of any discovery packet is still 1280 bytes. Finally, implementations of **the RLPx TCP Transport protocol** should accept a new encoding for the encrypted key establishment handshake packets. If an EIP-8 style RLPx `auth-packet` is received, the corresponding `ack-packet` should be sent using the rules below. Decoding the RLP data in `auth-body` and `ack-body` should ignore mismatches of `auth-vsn` and `ack-vsn`, any additional list elements and any trailing data after the list. During the transitioning period (i.e. until the old format has been retired), implementations should pad `auth-body` with at least 100 bytes of junk data. Adding a random amount in range [100, 300] is recommended to vary the size of the packet. ```text auth-vsn = 4 auth-size = size of enc-auth-body, encoded as a big-endian 16-bit integer auth-body = rlp.list(sig, initiator-pubk, initiator-nonce, auth-vsn) enc-auth-body = ecies.encrypt(recipient-pubk, auth-body, auth-size) auth-packet = auth-size || enc-auth-body ack-vsn = 4 ack-size = size of enc-ack-body, encoded as a big-endian 16-bit integer ack-body = rlp.list(recipient-ephemeral-pubk, recipient-nonce, ack-vsn) enc-ack-body = ecies.encrypt(initiator-pubk, ack-body, ack-size) ack-packet = ack-size || enc-ack-body where X || Y denotes concatenation of X and Y. X[:N] denotes an N-byte prefix of X. rlp.list(X, Y, Z, ...) denotes recursive encoding of [X, Y, Z, ...] as an RLP list. sha3(MESSAGE) is the Keccak256 hash function as used by Ethereum. ecies.encrypt(PUBKEY, MESSAGE, AUTHDATA) is the asymmetric authenticated encryption function as used by RLPx. AUTHDATA is authenticated data which is not part of the resulting ciphertext, but written to HMAC-256 before generating the message tag. ``` ### Motivation Changes to the devp2p protocols are hard to deploy because clients running an older version will refuse communication if the version number or structure of the hello (discovery ping, RLPx handshake) packet does not match local expectations. Introducing forward-compatibility requirements as part of the Homestead consensus upgrade will ensure that all client software in use on the Ethereum network can cope with future network protocol upgrades (as long as backwards-compatibility is maintained). ### Rationale The proposed changes address forward compatibility by applying Postel's Law (also known as the Robustness Principle) throughout the protocol stack. The merit and applicability of this approach has been studied repeatedly since its original application in RFC 761. For a recent perspective, see ["The Robustness Principle Reconsidered" (Eric Allman, 2011)](https://queue.acm.org/detail.cfm?id=1999945). #### Changes to the devp2p Wire Protocol All clients currently contain statements such as the following: ```python # pydevp2p/p2p_protocol.py if data['version'] != proto.version: log.debug('incompatible network protocols', peer=proto.peer, expected=proto.version, received=data['version']) return proto.send_disconnect(reason=reasons.incompatible_p2p_version) ``` These checks make it impossible to change the version or structure of the hello packet. Dropping them enables switching to a newer protocol version: Clients implementing a newer version simply send a packet with higher version and possibly additional list elements. * If such a packet is received by a node with lower version, it will blindly assume that the remote end is backwards-compatible and respond with the old handshake. * If the packet is received by a node with equal version, new features of the protocol can be used. * If the packet is received by a node with higher version, it can enable backwards-compatibility logic or drop the connection. #### Changes to the RLPx Discovery Protocol The relaxation of discovery packet decoding rules largely codifies current practice. Most existing implementations do not care about the number of list elements (an exception being go-ethereum) and do not reject nodes with mismatching version. This behaviour is not guaranteed by the spec, though. If adopted, the change makes it possible to deploy protocol changes in a similar manner to the devp2p hello change: simply bump the version and send additional information. Older clients will ignore the additional elements and can continue to operate even when the majority of the network has moved on to a newer protocol. #### Changes to the RLPx TCP Handshake Discussions of the RLPx v5 changes (chunked packets, change to key derivation) have faltered in part because the v4 handshake encoding provides only one in-band way to add a version number: shortening the random portion of the nonce. Even if the RLPx v5 handshake proposal were accepted, future upgrades are hard because the handshake packet is a fixed size ECIES ciphertext with known layout. I propose the following changes to the handshake packets: * Adding the length of the ciphertext as a plaintext header. * Encoding the body of the handshake as RLP. * Adding a version number to both packets in place of the token flag (unused). * Removing the hash of the ephemeral public key (it is redundant). These changes make it possible to upgrade the RLPx TCP transport protocol in the same manner as described for the other protocols, i.e. by adding list elements and bumping the version. Since this is the first change to the RLPx handshake packet, we can seize the opportunity to remove all currently unused fields. Additional data is permitted (and in fact required) after the RLP list because the handshake packet needs to grow in order to be distinguishable from the old format. Clients can employ logic such as the following pseudocode to handle both formats simultaneously. ```go packet = read(307, connection) if decrypt(packet) { // process as old format } else { size = unpack_16bit_big_endian(packet) packet += read(size - 307 + 2, connection) if !decrypt(packet) { // error } // process as new format } ``` The plain text size prefix is perhaps the most controversial aspect of this document. It has been argued that the prefix aids adversaries that seek to filter and identify RLPx connections on the network level. This is largely a question of how much effort the adversary is willing to expense. If the recommendation to randomise the lengths is followed, pure pattern-based packet recognition is unlikely to succeed. * For typical firewall operators, blocking all connections whose first two bytes form an integer in range [300,600] is probably too invasive. Port-based blocking would be a more effective measure to filter most RLPx traffic. * For an attacker who can afford to correlate many criteria, the size prefix would ease recognition because it adds to the indicator set. However, such an attacker could also be expected to read or participate in RLPx Discovery traffic, which would be sufficient to enable blocking of RLPx TCP connections whatever their format is. ### Backwards Compatibility This EIP is backwards-compatible, all valid version 4 packets are still accepted. ### Implementation [go-ethereum](https://github.com/ethereum/go-ethereum/pull/2091) [libweb3core](https://github.com/ethereum/libweb3core/pull/46) [pydevp2p](https://github.com/ethereum/pydevp2p/pull/32) ### Test Vectors #### devp2p Base Protocol devp2p hello packet advertising version 22 and containing a few additional list elements: ```text f87137916b6e6574682f76302e39312f706c616e39cdc5836574683dc6846d6f726b1682270fb840 fda1cff674c90c9a197539fe3dfb53086ace64f83ed7c6eabec741f7f381cc803e52ab2cd55d5569 bce4347107a310dfd5f88a010cd2ffd1005ca406f1842877c883666f6f836261720304 ``` #### RLPx Discovery Protocol Implementations should accept the following encoded discovery packets as valid. The packets are signed using the secp256k1 node key ```text b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291 ``` ping packet with version 4, additional list elements: ```text e9614ccfd9fc3e74360018522d30e1419a143407ffcce748de3e22116b7e8dc92ff74788c0b6663a aa3d67d641936511c8f8d6ad8698b820a7cf9e1be7155e9a241f556658c55428ec0563514365799a 4be2be5a685a80971ddcfa80cb422cdd0101ec04cb847f000001820cfa8215a8d790000000000000 000000000000000000018208ae820d058443b9a3550102 ``` ping packet with version 555, additional list elements and additional random data: ```text 577be4349c4dd26768081f58de4c6f375a7a22f3f7adda654d1428637412c3d7fe917cadc56d4e5e 7ffae1dbe3efffb9849feb71b262de37977e7c7a44e677295680e9e38ab26bee2fcbae207fba3ff3 d74069a50b902a82c9903ed37cc993c50001f83e82022bd79020010db83c4d001500000000abcdef 12820cfa8215a8d79020010db885a308d313198a2e037073488208ae82823a8443b9a355c5010203 040531b9019afde696e582a78fa8d95ea13ce3297d4afb8ba6433e4154caa5ac6431af1b80ba7602 3fa4090c408f6b4bc3701562c031041d4702971d102c9ab7fa5eed4cd6bab8f7af956f7d565ee191 7084a95398b6a21eac920fe3dd1345ec0a7ef39367ee69ddf092cbfe5b93e5e568ebc491983c09c7 6d922dc3 ``` pong packet with additional list elements and additional random data: ```text 09b2428d83348d27cdf7064ad9024f526cebc19e4958f0fdad87c15eb598dd61d08423e0bf66b206 9869e1724125f820d851c136684082774f870e614d95a2855d000f05d1648b2d5945470bc187c2d2 216fbe870f43ed0909009882e176a46b0102f846d79020010db885a308d313198a2e037073488208 ae82823aa0fbc914b16819237dcd8801d7e53f69e9719adecb3cc0e790c57e91ca4461c9548443b9 a355c6010203c2040506a0c969a58f6f9095004c0177a6b47f451530cab38966a25cca5cb58f0555 42124e ``` findnode packet with additional list elements and additional random data: ```text c7c44041b9f7c7e41934417ebac9a8e1a4c6298f74553f2fcfdcae6ed6fe53163eb3d2b52e39fe91 831b8a927bf4fc222c3902202027e5e9eb812195f95d20061ef5cd31d502e47ecb61183f74a504fe 04c51e73df81f25c4d506b26db4517490103f84eb840ca634cae0d49acb401d8a4c6b6fe8c55b70d 115bf400769cc1400f3258cd31387574077f301b421bc84df7266c44e9e6d569fc56be0081290476 7bf5ccd1fc7f8443b9a35582999983999999280dc62cc8255c73471e0a61da0c89acdc0e035e260a dd7fc0c04ad9ebf3919644c91cb247affc82b69bd2ca235c71eab8e49737c937a2c396 ``` neighbours packet with additional list elements and additional random data: ```text c679fc8fe0b8b12f06577f2e802d34f6fa257e6137a995f6f4cbfc9ee50ed3710faf6e66f932c4c8 d81d64343f429651328758b47d3dbc02c4042f0fff6946a50f4a49037a72bb550f3a7872363a83e1 b9ee6469856c24eb4ef80b7535bcf99c0004f9015bf90150f84d846321163782115c82115db84031 55e1427f85f10a5c9a7755877748041af1bcd8d474ec065eb33df57a97babf54bfd2103575fa8291 15d224c523596b401065a97f74010610fce76382c0bf32f84984010203040101b840312c55512422 cf9b8a4097e9a6ad79402e87a15ae909a4bfefa22398f03d20951933beea1e4dfa6f968212385e82 9f04c2d314fc2d4e255e0d3bc08792b069dbf8599020010db83c4d001500000000abcdef12820d05 820d05b84038643200b172dcfef857492156971f0e6aa2c538d8b74010f8e140811d53b98c765dd2 d96126051913f44582e8c199ad7c6d6819e9a56483f637feaac9448aacf8599020010db885a308d3 13198a2e037073488203e78203e8b8408dcab8618c3253b558d459da53bd8fa68935a719aff8b811 197101a4b2b47dd2d47295286fc00cc081bb542d760717d1bdd6bec2c37cd72eca367d6dd3b9df73 8443b9a355010203b525a138aa34383fec3d2719a0 ``` #### RLPx Handshake In these test vectors, node A initiates a connection with node B. The values contained in all packets are given below: ```text Static Key A: 49a7b37aa6f6645917e7b807e9d1c00d4fa71f18343b0d4122a4d2df64dd6fee Static Key B: b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291 Ephemeral Key A: 869d6ecf5211f1cc60418a13b9d870b22959d0c16f02bec714c960dd2298a32d Ephemeral Key B: e238eb8e04fee6511ab04c6dd3c89ce097b11f25d584863ac2b6d5b35b1847e4 Nonce A: 7e968bba13b6c50e2c4cd7f241cc0d64d1ac25c7f5952df231ac6a2bda8ee5d6 Nonce B: 559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd ``` (Auth₁) RLPx v4 format (sent from A to B): ```text 048ca79ad18e4b0659fab4853fe5bc58eb83992980f4c9cc147d2aa31532efd29a3d3dc6a3d89eaf 913150cfc777ce0ce4af2758bf4810235f6e6ceccfee1acc6b22c005e9e3a49d6448610a58e98744 ba3ac0399e82692d67c1f58849050b3024e21a52c9d3b01d871ff5f210817912773e610443a9ef14 2e91cdba0bd77b5fdf0769b05671fc35f83d83e4d3b0b000c6b2a1b1bba89e0fc51bf4e460df3105 c444f14be226458940d6061c296350937ffd5e3acaceeaaefd3c6f74be8e23e0f45163cc7ebd7622 0f0128410fd05250273156d548a414444ae2f7dea4dfca2d43c057adb701a715bf59f6fb66b2d1d2 0f2c703f851cbf5ac47396d9ca65b6260bd141ac4d53e2de585a73d1750780db4c9ee4cd4d225173 a4592ee77e2bd94d0be3691f3b406f9bba9b591fc63facc016bfa8 ``` (Auth₂) EIP-8 format with version 4 and no additional list elements (sent from A to B): ```text 01b304ab7578555167be8154d5cc456f567d5ba302662433674222360f08d5f1534499d3678b513b 0fca474f3a514b18e75683032eb63fccb16c156dc6eb2c0b1593f0d84ac74f6e475f1b8d56116b84 9634a8c458705bf83a626ea0384d4d7341aae591fae42ce6bd5c850bfe0b999a694a49bbbaf3ef6c da61110601d3b4c02ab6c30437257a6e0117792631a4b47c1d52fc0f8f89caadeb7d02770bf999cc 147d2df3b62e1ffb2c9d8c125a3984865356266bca11ce7d3a688663a51d82defaa8aad69da39ab6 d5470e81ec5f2a7a47fb865ff7cca21516f9299a07b1bc63ba56c7a1a892112841ca44b6e0034dee 70c9adabc15d76a54f443593fafdc3b27af8059703f88928e199cb122362a4b35f62386da7caad09 c001edaeb5f8a06d2b26fb6cb93c52a9fca51853b68193916982358fe1e5369e249875bb8d0d0ec3 6f917bc5e1eafd5896d46bd61ff23f1a863a8a8dcd54c7b109b771c8e61ec9c8908c733c0263440e 2aa067241aaa433f0bb053c7b31a838504b148f570c0ad62837129e547678c5190341e4f1693956c 3bf7678318e2d5b5340c9e488eefea198576344afbdf66db5f51204a6961a63ce072c8926c ``` (Auth₃) EIP-8 format with version 56 and 3 additional list elements (sent from A to B): ```text 01b8044c6c312173685d1edd268aa95e1d495474c6959bcdd10067ba4c9013df9e40ff45f5bfd6f7 2471f93a91b493f8e00abc4b80f682973de715d77ba3a005a242eb859f9a211d93a347fa64b597bf 280a6b88e26299cf263b01b8dfdb712278464fd1c25840b995e84d367d743f66c0e54a586725b7bb f12acca27170ae3283c1073adda4b6d79f27656993aefccf16e0d0409fe07db2dc398a1b7e8ee93b cd181485fd332f381d6a050fba4c7641a5112ac1b0b61168d20f01b479e19adf7fdbfa0905f63352 bfc7e23cf3357657455119d879c78d3cf8c8c06375f3f7d4861aa02a122467e069acaf513025ff19 6641f6d2810ce493f51bee9c966b15c5043505350392b57645385a18c78f14669cc4d960446c1757 1b7c5d725021babbcd786957f3d17089c084907bda22c2b2675b4378b114c601d858802a55345a15 116bc61da4193996187ed70d16730e9ae6b3bb8787ebcaea1871d850997ddc08b4f4ea668fbf3740 7ac044b55be0908ecb94d4ed172ece66fd31bfdadf2b97a8bc690163ee11f5b575a4b44e36e2bfb2 f0fce91676fd64c7773bac6a003f481fddd0bae0a1f31aa27504e2a533af4cef3b623f4791b2cca6 d490 ``` (Ack₁) RLPx v4 format (sent from B to A): ```text 049f8abcfa9c0dc65b982e98af921bc0ba6e4243169348a236abe9df5f93aa69d99cadddaa387662 b0ff2c08e9006d5a11a278b1b3331e5aaabf0a32f01281b6f4ede0e09a2d5f585b26513cb794d963 5a57563921c04a9090b4f14ee42be1a5461049af4ea7a7f49bf4c97a352d39c8d02ee4acc416388c 1c66cec761d2bc1c72da6ba143477f049c9d2dde846c252c111b904f630ac98e51609b3b1f58168d dca6505b7196532e5f85b259a20c45e1979491683fee108e9660edbf38f3add489ae73e3dda2c71b d1497113d5c755e942d1 ``` (Ack₂) EIP-8 format with version 4 and no additional list elements (sent from B to A): ```text 01ea0451958701280a56482929d3b0757da8f7fbe5286784beead59d95089c217c9b917788989470 b0e330cc6e4fb383c0340ed85fab836ec9fb8a49672712aeabbdfd1e837c1ff4cace34311cd7f4de 05d59279e3524ab26ef753a0095637ac88f2b499b9914b5f64e143eae548a1066e14cd2f4bd7f814 c4652f11b254f8a2d0191e2f5546fae6055694aed14d906df79ad3b407d94692694e259191cde171 ad542fc588fa2b7333313d82a9f887332f1dfc36cea03f831cb9a23fea05b33deb999e85489e645f 6aab1872475d488d7bd6c7c120caf28dbfc5d6833888155ed69d34dbdc39c1f299be1057810f34fb e754d021bfca14dc989753d61c413d261934e1a9c67ee060a25eefb54e81a4d14baff922180c395d 3f998d70f46f6b58306f969627ae364497e73fc27f6d17ae45a413d322cb8814276be6ddd13b885b 201b943213656cde498fa0e9ddc8e0b8f8a53824fbd82254f3e2c17e8eaea009c38b4aa0a3f306e8 797db43c25d68e86f262e564086f59a2fc60511c42abfb3057c247a8a8fe4fb3ccbadde17514b7ac 8000cdb6a912778426260c47f38919a91f25f4b5ffb455d6aaaf150f7e5529c100ce62d6d92826a7 1778d809bdf60232ae21ce8a437eca8223f45ac37f6487452ce626f549b3b5fdee26afd2072e4bc7 5833c2464c805246155289f4 ``` (Ack₃) EIP-8 format with version 57 and 3 additional list elements (sent from B to A): ```text 01f004076e58aae772bb101ab1a8e64e01ee96e64857ce82b1113817c6cdd52c09d26f7b90981cd7 ae835aeac72e1573b8a0225dd56d157a010846d888dac7464baf53f2ad4e3d584531fa203658fab0 3a06c9fd5e35737e417bc28c1cbf5e5dfc666de7090f69c3b29754725f84f75382891c561040ea1d dc0d8f381ed1b9d0d4ad2a0ec021421d847820d6fa0ba66eaf58175f1b235e851c7e2124069fbc20 2888ddb3ac4d56bcbd1b9b7eab59e78f2e2d400905050f4a92dec1c4bdf797b3fc9b2f8e84a482f3 d800386186712dae00d5c386ec9387a5e9c9a1aca5a573ca91082c7d68421f388e79127a5177d4f8 590237364fd348c9611fa39f78dcdceee3f390f07991b7b47e1daa3ebcb6ccc9607811cb17ce51f1 c8c2c5098dbdd28fca547b3f58c01a424ac05f869f49c6a34672ea2cbbc558428aa1fe48bbfd6115 8b1b735a65d99f21e70dbc020bfdface9f724a0d1fb5895db971cc81aa7608baa0920abb0a565c9c 436e2fd13323428296c86385f2384e408a31e104670df0791d93e743a3a5194ee6b076fb6323ca59 3011b7348c16cf58f66b9633906ba54a2ee803187344b394f75dd2e663a57b956cb830dd7a908d4f 39a2336a61ef9fda549180d4ccde21514d117b6c6fd07a9102b5efe710a32af4eeacae2cb3b1dec0 35b9593b48b9d3ca4c13d245d5f04169b0b1 ``` Node B derives the connection secrets for (Auth₂, Ack₂) as follows: ```text aes-secret = 80e8632c05fed6fc2a13b0f8d31a3cf645366239170ea067065aba8e28bac487 mac-secret = 2ea74ec5dae199227dff1af715362700e989d889d7a493cb0639691efb8e5f98 ``` Running B's `ingress-mac` keccak state on the string "foo" yields the hash ```text ingress-mac("foo") = 0c7ec6340062cc46f5e9f1e3cf86f8c8c403c5a0964f5df0ebd34a75ddc86db5 ``` ### Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 18 Dec 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-8 https://eips.ethereum.org/EIPS/eip-8 Token Standard Standards Track/ERC ## Simple Summary A standard interface for tokens. ## Abstract The following standard allows for the implementation of a standard API for tokens within smart contracts. This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party. ## Motivation A standard interface allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges. ## Specification ## Token ### Methods **NOTES**: - The following specifications use syntax from Solidity `0.4.17` (or above) - Callers MUST handle `false` from `returns (bool success)`. Callers MUST NOT assume that `false` is never returned! #### name Returns the name of the token - e.g. `"MyToken"`. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. ``` js function name() public view returns (string) ``` #### symbol Returns the symbol of the token. E.g. "HIX". OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. ``` js function symbol() public view returns (string) ``` #### decimals Returns the number of decimals the token uses - e.g. `8`, means to divide the token amount by `100000000` to get its user representation. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. ``` js function decimals() public view returns (uint8) ``` #### totalSupply Returns the total token supply. ``` js function totalSupply() public view returns (uint256) ``` #### balanceOf Returns the account balance of another account with address `_owner`. ``` js function balanceOf(address _owner) public view returns (uint256 balance) ``` #### transfer Transfers `_value` amount of tokens to address `_to`, and MUST fire the `Transfer` event. The function SHOULD `throw` if the message caller's account balance does not have enough tokens to spend. *Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event. ``` js function transfer(address _to, uint256 _value) public returns (bool success) ``` #### transferFrom Transfers `_value` amount of tokens from address `_from` to address `_to`, and MUST fire the `Transfer` event. The `transferFrom` method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function SHOULD `throw` unless the `_from` account has deliberately authorized the sender of the message via some mechanism. *Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event. ``` js function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) ``` #### approve Allows `_spender` to withdraw from your account multiple times, up to the `_value` amount. If this function is called again it overwrites the current allowance with `_value`. **NOTE**: To prevent attack vectors like the one [described here](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/) and discussed [here](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to `0` before setting it to another value for the same spender. THOUGH The contract itself shouldn't enforce it, to allow backwards compatibility with contracts deployed before ``` js function approve(address _spender, uint256 _value) public returns (bool success) ``` #### allowance Returns the amount which `_spender` is still allowed to withdraw from `_owner`. ``` js function allowance(address _owner, address _spender) public view returns (uint256 remaining) ``` ### Events #### Transfer MUST trigger when tokens are transferred, including zero value transfers. A token contract which creates new tokens SHOULD trigger a Transfer event with the `_from` address set to `0x0` when tokens are created. ``` js event Transfer(address indexed _from, address indexed _to, uint256 _value) ``` #### Approval MUST trigger on any successful call to `approve(address _spender, uint256 _value)`. ``` js event Approval(address indexed _owner, address indexed _spender, uint256 _value) ``` ## Implementation There are already plenty of ERC20-compliant tokens deployed on the Ethereum network. Different implementations have been written by various teams that have different trade-offs: from gas saving to improved security. #### Example implementations are available at - [OpenZeppelin implementation](/assets/eip-20/OpenZeppelin-ERC20.sol) - [ConsenSys implementation](/assets/eip-20/Consensys-EIP20.sol) ## History Historical links related to this standard: - Original proposal from Vitalik Buterin: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs/499c882f3ec123537fc2fccd57eaa29e6032fe4a - Reddit discussion: https://www.reddit.com/r/ethereum/comments/3n8fkn/lets_talk_about_the_coin_standard/ - Original Issue #20: https://github.com/ethereum/EIPs/issues/20 ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 19 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-20 https://eips.ethereum.org/EIPS/eip-20 Mixed-case checksum address encoding Standards Track/ERC https://github.com/ethereum/eips/issues/55 # Specification Code: ``` python import eth_utils def checksum_encode(addr): # Takes a 20-byte binary address as input hex_addr = addr.hex() checksummed_buffer = "" # Treat the hex address as ascii/utf-8 for keccak256 hashing hashed_address = eth_utils.keccak(text=hex_addr).hex() # Iterate over each character in the hex address for nibble_index, character in enumerate(hex_addr): if character in "0123456789": # We can't upper-case the decimal digits checksummed_buffer += character elif character in "abcdef": # Check if the corresponding hex digit (nibble) in the hash is 8 or higher hashed_address_nibble = int(hashed_address[nibble_index], 16) if hashed_address_nibble > 7: checksummed_buffer += character.upper() else: checksummed_buffer += character else: raise eth_utils.ValidationError( f"Unrecognized hex character {character!r} at position {nibble_index}" ) return "0x" + checksummed_buffer def test(addr_str): addr_bytes = eth_utils.to_bytes(hexstr=addr_str) checksum_encoded = checksum_encode(addr_bytes) assert checksum_encoded == addr_str, f"{checksum_encoded} != expected {addr_str}" test("0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed") test("0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359") test("0xdbF03B407c01E7cD3CBea99509d93f8DDDC8C6FB") test("0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb") ``` In English, convert the address to hex, but if the `i`th digit is a letter (ie. it's one of `abcdef`) print it in uppercase if the `4*i`th bit of the hash of the lowercase hexadecimal address is 1 otherwise print it in lowercase. # Rationale Benefits: - Backwards compatible with many hex parsers that accept mixed case, allowing it to be easily introduced over time - Keeps the length at 40 characters - On average there will be 15 check bits per address, and the net probability that a randomly generated address if mistyped will accidentally pass a check is 0.0247%. This is a ~50x improvement over ICAP, but not as good as a 4-byte check code. # Implementation In javascript: ```js const createKeccakHash = require('keccak') function toChecksumAddress (address) { address = address.toLowerCase().replace('0x', '') var hash = createKeccakHash('keccak256').update(address).digest('hex') var ret = '0x' for (var i = 0; i < address.length; i++) { if (parseInt(hash[i], 16) >= 8) { ret += address[i].toUpperCase() } else { ret += address[i] } } return ret } ``` ``` > toChecksumAddress('0xfb6916095ca1df60bb79ce92ce3ea74c37c5d359') '0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359' ``` Note that the input to the Keccak256 hash is the lowercase hexadecimal string (i.e. the hex address encoded as ASCII): ``` var hash = createKeccakHash('keccak256').update(Buffer.from(address.toLowerCase(), 'ascii')).digest() ``` # Test Cases ``` # All caps 0x52908400098527886E0F7030069857D2E4169EE7 0x8617E340B3D01FA5F11F306F4090FD50E238070D # All Lower 0xde709f2102306220921060314715629080e2fb77 0x27b1fdb04752bbc536007a920d24acb045561c26 # Normal 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed 0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359 0xdbF03B407c01E7cD3CBea99509d93f8DDDC8C6FB 0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb ``` Thu, 14 Jan 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-55 https://eips.ethereum.org/EIPS/eip-55 URI Scheme with Metadata, Value and Bytecode Standards Track/ERC https://github.com/ethereum/EIPs/issues/67 ## Abstract This proposal (inspired by BIP 21) defines a format for encoding a transaction into a URI, including a recipient, number of ethers (possibly zero), and optional bytecode. ## Motivation Imagine these scenarios: * An exchange or a instant converter like ShapeShift wants to create a single Ethereum address for payments that will be converted into credit in their internal system or output bitcoin to an address. * A store wants to show a QR code to a client that will pop up a payment for exactly 12.34 ethers, which contains metadata on the product being bought. * A betting site wants to provide a link that the user can click on his site and it will open a default Ethereum wallet and execute a specific contract with given parameters. * A dapp in Mist wants to simply ask the user to sign a transaction with a specific ABI in a single call. In all these scenarios, the provider wants to internally set up a transaction, with a recipient, an associated number of ethers (or none) and optional bytecode, all without requiring any fuss from the end user that is expected simply to choose a sender and authorise the transaction. Currently implementations for this are wonky: ShapeShift creates tons of temporary addresses and uses an internal system to check which one correspond to which metadata, there isn't any standard way for stores that want payment in ether to put specific metadata about price on the call and any app implementing contracts will have to use different solutions depending on the client they are targeting. The proposal goes beyond address, and also includes optional bytecode and value. Of course this would make the link longer, but it should not be something visible to the user. Instead it should be shown as a visual code (QR or otherwise), a link, or some other way to pass the information. If properly implemented in all wallets, this should make execution of contracts directly from wallets much simpler as the wallet client only needs to put the bytecode obtained by reading the QR code. ## Specification If we follow the bitcoin standard, the result would be: ``` ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?data=<bytecode>] ``` Other data could be added, but ideally the client should take them from elsewhere in the blockchain, so instead of having a `label` or a `message` to be displayed to the users, these should be read from an identity system or metadata on the transaction itself. ### Example 1 Clicking this link would open a transaction that would try to send _5 unicorns_ to address _deadbeef_. The user would then simply approve, based on each wallet UI. ``` ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&data=0xa9059cbb00000000000000000000000000000000000000000000000000000000deadbeef0000000000000000000000000000000000000000000000000000000000000005 ``` #### Without Bytecode Alternatively, the bytecode could be generated by the client and the request would be in plain text: ``` ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?function=nameOfFunction(param)] ``` ### Example 2 This is the same function as above, to send 5 unicorns from he sender to _deadbeef_, but now with a more readable function, which the client converts to bytecode. ``` ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&function=transfer(address 0xdeadbeef, uint 5) ``` ## Rationale TODO ## Security Considerations TODO ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 17 Feb 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-67 https://eips.ethereum.org/EIPS/eip-67 Abstraction of transaction origin and signature Standards Track/Core # Summary Implements a set of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing. # Parameters * METROPOLIS_FORK_BLKNUM: TBD * CHAIN_ID: same as used for EIP 155 (ie. 1 for mainnet, 3 for testnet) * NULL_SENDER: 2**160 - 1 # Specification If `block.number >= METROPOLIS_FORK_BLKNUM`, then: 1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER` 2. Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account NULL_SENDER. 3. Create a new opcode at `0xfb`, `CREATE2`, with 4 stack arguments (value, salt, mem_start, mem_size) which sets the creation address to `sha3(sender + salt + sha3(init code)) % 2**160`, where `salt` is always represented as a 32-byte value. 4. Add to _all_ contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code OR non-empty nonce, the operation fails and returns 0 as if the init code had run out of gas. If an account has empty code and nonce but nonempty balance, the creation operation may still succeed. # Rationale The goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model. Under EIP 86, we can expect users to store their ether in contracts, whose code might look like the following (example in Serpent): ```python # Get signature from tx data sig_v = ~calldataload(0) sig_r = ~calldataload(32) sig_s = ~calldataload(64) # Get tx arguments tx_nonce = ~calldataload(96) tx_to = ~calldataload(128) tx_value = ~calldataload(160) tx_gasprice = ~calldataload(192) tx_data = string(~calldatasize() - 224) ~calldataload(tx_data, 224, ~calldatasize()) # Get signing hash signing_data = string(~calldatasize() - 64) ~mstore(signing_data, tx.startgas) ~calldataload(signing_data + 32, 96, ~calldatasize() - 96) signing_hash = sha3(signing_data:str) # Perform usual checks prev_nonce = ~sload(-1) assert tx_nonce == prev_nonce + 1 assert self.balance >= tx_value + tx_gasprice * tx.startgas assert ~ecrecover(signing_hash, sig_v, sig_r, sig_s) == <pubkey hash here> # Update nonce ~sstore(-1, prev_nonce + 1) # Pay for gas ~send(MINER_CONTRACT, tx_gasprice * tx.startgas) # Make the main call ~call(msg.gas - 50000, tx_to, tx_value, tx_data, len(tx_data), 0, 0) # Get remaining gas payments back ~call(20000, MINER_CONTRACT, 0, [msg.gas], 32, 0, 0) ``` This can be thought of as a "forwarding contract". It accepts data from the "entry point" address 2**160 - 1 (an account that anyone can send transactions from), expecting that data to be in the format `[sig, nonce, to, value, gasprice, data]`. The forwarding contract verifies the signature, and if the signature is correct it sets up a payment to the miner and then sends a call to the desired address with the provided value and data. The benefits that this provides lie in the most interesting cases: - **Multisig wallets**: currently, sending from a multisig wallet requires each operation to be ratified by the participants, and each ratification is a transaction. This could be simplified by having one ratification transaction include signatures from the other participants, but even still it introduces complexity because the participants' accounts all need to be stocked up with ETH. With this EIP, it will be possible to just have the contract store the ETH, send a transaction containing all signatures to the contract directly, and the contract can pay the fees. - **Ring signature mixers**: the way that ring signature mixers work is that N individuals send 1 coin into a contract, and then use a linkable ring signature to withdraw 1 coin later on. The linkable ring signature ensures that the withdrawal transaction cannot be linked to the deposit, but if someone attempts to withdraw twice then those two signatures can be linked and the second one prevented. However, currently there is a privacy risk: to withdraw, you need to have coins to pay for gas, and if these coins are not properly mixed then you risk compromising your privacy. With this EIP, you can pay for gas straight our of your withdrawn coins. - **Custom cryptography**: users can upgrade to ed25519 signatures, Lamport hash ladder signatures or whatever other scheme they want on their own terms; they do not need to stick with ECDSA. - **Non-cryptographic modifications**: users can require transactions to have expiry times (this being standard would allow old empty/dust accounts to be flushed from the state securely), use k-parallelizable nonces (a scheme that allows transactions to be confirmed slightly out-of-order, reducing inter-transaction dependence), or make other modifications. (2) and (3) introduce a feature similar to bitcoin's P2SH, allowing users to send funds to addresses that provably map to only one particular piece of code. Something like this is crucial in the long term because, in a world where all accounts are contracts, we need to preserve the ability to send to an account before that account exists on-chain, as that's a basic functionality that exists in all blockchain protocols today. # Miner and transaction replaying strategy Note that miners would need to have a strategy for accepting these transactions. This strategy would need to be very discriminating, because otherwise they run the risk of accepting transactions that do not pay them any fees, and possibly even transactions that have no effect (eg. because the transaction was already included and so the nonce is no longer current). One simple strategy is to have a set of regexps that the to address of an account would be checked against, each regexp corresponding to a "standard account type" which is known to be "safe" (in the sense that if an account has that code, and a particular check involving the account balances, account storage and transaction data passes, then if the transaction is included in a block the miner will get paid), and mine and relay transactions that pass these checks. One example would be to check as follows: 1. Check that the to address has code which is the compiled version of the Serpent code above, with `<pubkey hash here>` replaced with any public key hash. 2. Check that the signature in the transaction data verifies with that key hash. 3. Check that the gasprice in the transaction data is sufficiently high 4. Check that the nonce in the state matches the nonce in the transaction data 5. Check that there is enough ether in the account to pay for the fee If all five checks pass, relay and/or mine the transaction. A looser but still effective strategy would be to accept any code that fits the same general format as the above, consuming only a limited amount of gas to perform nonce and signature checks and having a guarantee that transaction fees will be paid to the miner. Another strategy is to, alongside other approaches, try to process any transaction that asks for less than 250,000 gas, and include it only if the miner's balance is appropriately higher after executing the transaction than before it. # Copyright Copyright and related rights waived via CC0. Fri, 10 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-86 https://eips.ethereum.org/EIPS/eip-86 Change difficulty adjustment to target mean block time including uncles Standards Track/Core ### Specification Currently, the formula to compute the difficulty of a block includes the following logic: ``` python adj_factor = max(1 - ((timestamp - parent.timestamp) // 10), -99) child_diff = int(max(parent.difficulty + (parent.difficulty // BLOCK_DIFF_FACTOR) * adj_factor, min(parent.difficulty, MIN_DIFF))) ... ``` If `block.number >= BYZANTIUM_FORK_BLKNUM`, we change the first line to the following: ``` python adj_factor = max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99) ``` ### Rationale This new formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. A formula that accounts for the exact number of included uncles: ``` python adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99) ``` can be fairly easily seen to be (to within a tolerance of ~3/4194304) mathematically equivalent to assuming that a block with `k` uncles is equivalent to a sequence of `k+1` blocks that all appear with the exact same timestamp, and this is likely the simplest possible way to accomplish the desired effect. But since the exact formula depends on the full block and not just the header, we are instead using an approximate formula that accomplishes almost the same effect but has the benefit that it depends only on the block header (as you can check the uncle hash against the blank hash). Changing the denominator from 10 to 9 ensures that the block time remains roughly the same (in fact, it should decrease by ~3% given the current uncle rate of 7%). ### References 1. EIP 100 issue and discussion: https://github.com/ethereum/EIPs/issues/100 2. https://bitslog.wordpress.com/2016/04/28/uncle-mining-an-ethereum-consensus-protocol-flaw/ Thu, 28 Apr 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-100 https://eips.ethereum.org/EIPS/eip-100 Serenity Currency and Crypto Abstraction Standards Track/Core ### Specification 1. Accounts now have only two fields in their RLP encoding: **code** and **storage**. 2. Ether is no longer stored in account objects directly; instead, at address `0`, we premine a contract which contains all ether holdings. The `eth.getBalance` command in web3 is remapped appropriately. 3. `msg.value` no longer exists as an opcode. 4. A transaction now only has four fields: **to**, **startgas**, **data** and **code**. 5. Aside from an RLP validity check, and checking that the **to** field is twenty bytes long, the **startgas** is an integer, and **code** is either empty or hashes to the **to** address, there are no other validity constraints; anything goes. However, the block gas limit remains, so miners are disincentivized from including junk. 6. Gas is charged for bytes in **code** at the same rate as **data**. 7. When a transaction is sent, if the receiving account does not yet exist, the account is created, and its code is set to the code provided in the transaction; otherwise the code is ignored. 8. A `tx.gas` opcode is added alongside the existing `msg.gas` at index `0x5c`; this new opcode allows the transaction to access the original amount of gas allotted for the transaction Note that `ECRECOVER`, sequence number/nonce incrementing and ether are now nowhere in the bottom-level spec (NOTE: ether is going to continue to have a privileged role in Casper PoS). To replicate existing functionality under the new model, we do the following. Simple user accounts can have the following default standardized code: ```python # We assume that data takes the following schema: # bytes 0-31: v (ECDSA sig) # bytes 32-63: r (ECDSA sig) # bytes 64-95: s (ECDSA sig) # bytes 96-127: sequence number (formerly called "nonce") # bytes 128-159: gasprice # bytes 172-191: to # bytes 192+: data # Get the hash for transaction signing ~mstore(0, msg.gas) ~calldatacopy(32, 96, ~calldatasize() - 96) h = sha3(96, ~calldatasize() - 96) # Call ECRECOVER contract to get the sender ~call(5000, 3, [h, ~calldataload(0), ~calldataload(32), ~calldataload(64)], 128, ref(addr), 32) # Check sender correctness assert addr == 0x82a978b3f5962a5b0957d9ee9eef472ee55b42f1 # Check sequence number correctness assert ~calldataload(96) == self.storage[-1] # Increment sequence number self.storage[-1] += 1 # Make the sub-call and discard output ~call(msg.gas - 50000, ~calldataload(160), 192, ~calldatasize() - 192, 0, 0) # Pay for gas ~call(40000, 0, [SEND, block.coinbase, ~calldataload(128) * (tx.gas - msg.gas + 50000)], 96, 0, 0) ``` This essentially implements signature and nonce checking, and if both checks pass then it uses all remaining gas minus 50000 to send the actual desired call, and then finally pays for gas. Miners can follow the following algorithm upon receiving transactions: 1. Run the code for a maximum of 50000 gas, stopping if they see an operation or call that threatens to go over this limit 2. Upon seeing that operation, make sure that it leaves at least 50000 gas to spare (either by checking that the static gas consumption is small enough or by checking that it is a call with `msg.gas - 50000` as its gas limit parameter) 3. Pattern-match to make sure that gas payment code at the end is *exactly* the same as in the code above. This process ensures that miners *waste* at most 50000 gas before knowing whether or not it will be worth their while to include the transaction, and is also highly general so users can experiment with new cryptography (eg. ed25519, Lamport), ring signatures, quasi-native multisig, etc. Theoretically, one can even create an account for which the *valid signature* type is a valid Merkle branch of a receipt, creating a quasi-native alarm clock. If someone wants to send a transaction with nonzero value, instead of the current `msg.sender` approach, we compile into a three step process: 1. In the outer scope just before calling, call the ether contract to create a cheque for the desired amount 2. In the inner scope, if a contract uses the `msg.value` opcode anywhere in the function that is being called, then we have the contract cash out the cheque at the start of the function call and store the amount cashed out in a standardized address in memory 3. In the outer scope just after calling, send a message to the ether contract to disable the cheque if it has not yet been cashed ### Rationale This allows for a large increase in generality, particularly in a few areas: 1. Cryptographic algorithms used to secure accounts (we could reasonably say that Ethereum is quantum-safe, as one is perfectly free to secure one's account with Lamport signatures). The nonce-incrementing approach is now also open to revision on the part of account holders, allowing for experimentation in k-parallelizable nonce techniques, UTXO schemes, etc. 2. Moving ether up a level of abstraction, with the particular benefit of allowing ether and sub-tokens to be treated similarly by contracts 3. Reducing the level of indirection required for custom-policy accounts such as multisigs It also substantially simplifies and *purifies* the underlying Ethereum protocol, reducing the minimal consensus implementation complexity. ### Implementation Coming soon. Sun, 15 Nov 2015 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-101 https://eips.ethereum.org/EIPS/eip-101 safe "eth_sendTransaction" authorization via html popup Standards Track/Interface ## Abstract This draft EIP describes the details of an authorization method that if provided by rpc enabled ethereum nodes would allow regular websites to send transactions (via ```eth_sendTransaction```) without the need to enable CORS. Instead, user would be asked to confirm the transaction via an html popup. Every read only rpc call the dapp wants to perform is redirected to an invisible iframe from the node's domain and for every transaction that the dapp wish to execute, an html popup is presented to the user to allow him/her to cancel or confirm the transaction. This allows the dapp to connect to the node's rpc api without being granted any kind of privileges. This allows users to safely interact with dapps running in their everyday web browser while their accounts are unlocked. In case the account is not unlocked, and the node has allowed the "personal" api via rpc,the html page also allow the user to enter their password to unlock the account for the scope of the transaction. ## Motivation Currently, if a user navigates to a dapp running on a website using her/his everyday browser, the dapp will by default have no access to the rpc api for security reasons. The user will have to enable CORS for the website's domain in order for the dapp to work. Unfortunately if the user does so, the dapp will be able to send transactions from any unlocked account without the need for any user consent. In other words, not only does the user need to change the node's default setting, but the user is also forced to trust the dapp in order to use it. This is of course not acceptable and forces existing dapps to rely on the use of workarounds like: - if the transaction is a plain ether transfer, the user is asked to enter it in a dedicated trusted wallet like "Mist" - For more complex case, the user is asked to enter the transaction manually via the node command line interface. This proposal aims to provide a safe and user friendly alternative. Here are some screenshots of the provided implementation of that html popup: ### Account unlocked When the account is already unlocked, the user is presented with the following popup for every transaction that the dapp attempts to make: ![](/assets/eip-107/authorization.png) ### Account locked and no "personal" api exposed via rpc: When the account is locked, and the node does not provide access to account unlocking via its rpc interface, the following popup will be presented. This is not ideal since this requires the user to know how to unlock an account: ![](/assets/eip-107/authorization-locked.png) ### Account locked but node exposing the "personal" api via rpc : A better option is to ask the user for their password, but this is only possible if the node allows access to the "personal" api via rpc. In such case, the following dialog will be presented to the user so he/she can accept the transaction by providing the password required to unlock the account: ![](/assets/eip-107/authorization-password.png) ## Specification In order for the mechanism to work, the node needs to serve an html file via http at the url \<node url\>/authorization.html This file will then be used by the dapp in 2 different modes (invisible iframe and popup window). The invisible iframe will be embedded in the dapp to allow the dapp to send its read-only rpc call without having to enable CORS for the dapp's website domain. This is done by sending message to the iframe (via javascript ```window.postMessage```) which in turn execute the rpc call. This works since the iframe and the node share the same domain/port. In the iframe mode, the html file's javascript code will ensure that no call requiring an unlocked key can be made. This is to prevent dapps from embedding the invisible iframe and tricking the user into clicking the confirm button. If the dapp requires an ```eth_sendTransaction``` call, the dapp will instead open a new window using the same url. In this popup window mode, the html file's javascript code will allow ```eth_sendTransaction``` (but not ```eth_sign```, as there is no way to display to the user the meaningful content of the transaction to sign in a safe way) to be called. But instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses, as well as the amount being transferred along with the potential gas cost. Upon the user approving, the request will be sent and the result returned to the dapp. An error will be returned in case the user cancel the request. The html page also checks for the availability of the "personal" api and if so, will ask the user to unlock the account if necessary. The unlocking is temporary (3s) so the password will be asked again if a transaction is attempted before the end of this short time. In both iframe mode and window mode, the communication with the dapp is achieved using ```window.postMessage```. The first message the iframe/window sends is a message containing the string "ready" to let the dapp know that it now accepts messages. Then the dapp can start performing rpc call by sending message using the following object : ``` { id:<an id>, //so responses can be match as there is no guarantee of the order of the response payload:<json rpc object> //this is the exact object that usually send to the node } ``` For ```eth_sendTransaction``` the "gas", "gasPrice" and "from" field need to be set in the rpc parameter so that the window can display the correct value. If not all of these are passed in, the window will return an error. Upon receiving such message, the iframe will perform the actual rpc call to the node but only if such a call is a read only call (not requiring an unlocked key). If it is not it will return a error. The window on the other will only accept ```eth_sendTransaction``` calls but will display a dialog so the user can accept or cancel the request. In all the cases, the iframe/window will send a message back to the dapp using the following object: ``` { id:<id matching the request>, result:<rpc result as is>, error:<error object> } ``` the error object cannot be a javascript Error object due to postMessage limitation. Instead it is ``` { message:<a string describing the error>, type:<a string defining the type of error> //type="cancel" means the user cancel the transaction } ``` ## Rationale The design for that proposal was chosen for its simplicity and security. A previous idea was to use an oauth-like protocol in order for the user to accept or deny a transaction request. It would have required deeper code change in the node and some geth contributors argues that such change did not fit into geth code base as it would have required dapp aware code. The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guaranteed by browsers' cross domain policies. The use of iframe/ window was required to have both security and user friendliness. The invisible iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653). ## Implementations In order to implement this design, the following html file or an equivalent one needs to be served at the url \<node url\>/authorization.html That's it. ```html <!DOCTYPE html> <html> <head> <title>Ethereum Authorization</title> </head> <script> //https://github.com/alexvandesande/blockies !function(){function r(r){for(var t=0;t<l.length;t++)l[t]=0;for(var t=0;t<r.length;t++)l[t%4]=(l[t%4]<<5)-l[t%4]+r.charCodeAt(t)}function t(){var r=l[0]^l[0]<<11;return l[0]=l[1],l[1]=l[2],l[2]=l[3],l[3]=l[3]^l[3]>>19^r^r>>8,(l[3]>>>0)/(1<<31>>>0)}function e(){var r=Math.floor(360*t()),e=60*t()+40+"%",o=25*(t()+t()+t()+t())+"%",n="hsl("+r+","+e+","+o+")";return n}function o(r){for(var e=r,o=r,n=Math.ceil(e/2),a=e-n,l=[],c=0;o>c;c++){for(var f=[],h=0;n>h;h++)f[h]=Math.floor(2.3*t());var i=f.slice(0,a);i.reverse(),f=f.concat(i);for(var v=0;v<f.length;v++)l.push(f[v])}return l}function n(r,t,e,o,n){var a=document.createElement("canvas"),l=Math.sqrt(r.length);a.width=a.height=l*e;var c=a.getContext("2d");c.fillStyle=o,c.fillRect(0,0,a.width,a.height),c.fillStyle=t;for(var f=0;f<r.length;f++){var h=Math.floor(f/l),i=f%l;c.fillStyle=1==r[f]?t:n,r[f]&&c.fillRect(i*e,h*e,e,e)}return a}function a(t){t=t||{};var a=t.size||8,l=t.scale||4,c=t.seed||Math.floor(Math.random()*Math.pow(10,16)).toString(16);r(c);var f=t.color||e(),h=t.bgcolor||e(),i=t.spotcolor||e(),v=o(a),u=n(v,f,l,h,i);return u}var l=new Array(4);window.blockies={create:a}}(); /* bignumber.js v2.3.0 https://github.com/MikeMcl/bignumber.js/LICENCE */ !function(e){"use strict";function n(e){function E(e,n){var t,r,i,o,u,s,f=this;if(!(f instanceof E))return j&&L(26,"constructor call without new",e),new E(e,n);if(null!=n&&H(n,2,64,M,"base")){if(n=0|n,s=e+"",10==n)return f=new E(e instanceof E?e:s),U(f,P+f.e+1,k);if((o="number"==typeof e)&&0*e!=0||!new RegExp("^-?"+(t="["+N.slice(0,n)+"]+")+"(?:\\."+t+")?$",37>n?"i":"").test(s))return h(f,s,o,n);o?(f.s=0>1/e?(s=s.slice(1),-1):1,j&&s.replace(/^0\.0*|\./,"").length>15&&L(M,v,e),o=!1):f.s=45===s.charCodeAt(0)?(s=s.slice(1),-1):1,s=D(s,10,n,f.s)}else{if(e instanceof E)return f.s=e.s,f.e=e.e,f.c=(e=e.c)?e.slice():e,void(M=0);if((o="number"==typeof e)&&0*e==0){if(f.s=0>1/e?(e=-e,-1):1,e===~~e){for(r=0,i=e;i>=10;i/=10,r++);return f.e=r,f.c=[e],void(M=0)}s=e+""}else{if(!g.test(s=e+""))return h(f,s,o);f.s=45===s.charCodeAt(0)?(s=s.slice(1),-1):1}}for((r=s.indexOf("."))>-1&&(s=s.replace(".","")),(i=s.search(/e/i))>0?(0>r&&(r=i),r+=+s.slice(i+1),s=s.substring(0,i)):0>r&&(r=s.length),i=0;48===s.charCodeAt(i);i++);for(u=s.length;48===s.charCodeAt(--u););if(s=s.slice(i,u+1))if(u=s.length,o&&j&&u>15&&(e>y||e!==d(e))&&L(M,v,f.s*e),r=r-i-1,r>z)f.c=f.e=null;else if(G>r)f.c=[f.e=0];else{if(f.e=r,f.c=[],i=(r+1)%O,0>r&&(i+=O),u>i){for(i&&f.c.push(+s.slice(0,i)),u-=O;u>i;)f.c.push(+s.slice(i,i+=O));s=s.slice(i),i=O-s.length}else i-=u;for(;i--;s+="0");f.c.push(+s)}else f.c=[f.e=0];M=0}function D(e,n,t,i){var o,u,f,c,a,h,g,p=e.indexOf("."),d=P,m=k;for(37>t&&(e=e.toLowerCase()),p>=0&&(f=J,J=0,e=e.replace(".",""),g=new E(t),a=g.pow(e.length-p),J=f,g.c=s(l(r(a.c),a.e),10,n),g.e=g.c.length),h=s(e,t,n),u=f=h.length;0==h[--f];h.pop());if(!h[0])return"0";if(0>p?--u:(a.c=h,a.e=u,a.s=i,a=C(a,g,d,m,n),h=a.c,c=a.r,u=a.e),o=u+d+1,p=h[o],f=n/2,c=c||0>o||null!=h[o+1],c=4>m?(null!=p||c)&&(0==m||m==(a.s<0?3:2)):p>f||p==f&&(4==m||c||6==m&&1&h[o-1]||m==(a.s<0?8:7)),1>o||!h[0])e=c?l("1",-d):"0";else{if(h.length=o,c)for(--n;++h[--o]>n;)h[o]=0,o||(++u,h.unshift(1));for(f=h.length;!h[--f];);for(p=0,e="";f>=p;e+=N.charAt(h[p++]));e=l(e,u)}return e}function F(e,n,t,i){var o,u,s,c,a;if(t=null!=t&&H(t,0,8,i,w)?0|t:k,!e.c)return e.toString();if(o=e.c[0],s=e.e,null==n)a=r(e.c),a=19==i||24==i&&B>=s?f(a,s):l(a,s);else if(e=U(new E(e),n,t),u=e.e,a=r(e.c),c=a.length,19==i||24==i&&(u>=n||B>=u)){for(;n>c;a+="0",c++);a=f(a,u)}else if(n-=s,a=l(a,u),u+1>c){if(--n>0)for(a+=".";n--;a+="0");}else if(n+=u-c,n>0)for(u+1==c&&(a+=".");n--;a+="0");return e.s<0&&o?"-"+a:a}function _(e,n){var t,r,i=0;for(u(e[0])&&(e=e[0]),t=new E(e[0]);++i<e.length;){if(r=new E(e[i]),!r.s){t=r;break}n.call(t,r)&&(t=r)}return t}function x(e,n,t,r,i){return(n>e||e>t||e!=c(e))&&L(r,(i||"decimal places")+(n>e||e>t?" out of range":" not an integer"),e),!0}function I(e,n,t){for(var r=1,i=n.length;!n[--i];n.pop());for(i=n[0];i>=10;i/=10,r++);return(t=r+t*O-1)>z?e.c=e.e=null:G>t?e.c=[e.e=0]:(e.e=t,e.c=n),e}function L(e,n,t){var r=new Error(["new BigNumber","cmp","config","div","divToInt","eq","gt","gte","lt","lte","minus","mod","plus","precision","random","round","shift","times","toDigits","toExponential","toFixed","toFormat","toFraction","pow","toPrecision","toString","BigNumber"][e]+"() "+n+": "+t);throw r.name="BigNumber Error",M=0,r}function U(e,n,t,r){var i,o,u,s,f,l,c,a=e.c,h=S;if(a){e:{for(i=1,s=a[0];s>=10;s/=10,i++);if(o=n-i,0>o)o+=O,u=n,f=a[l=0],c=f/h[i-u-1]%10|0;else if(l=p((o+1)/O),l>=a.length){if(!r)break e;for(;a.length<=l;a.push(0));f=c=0,i=1,o%=O,u=o-O+1}else{for(f=s=a[l],i=1;s>=10;s/=10,i++);o%=O,u=o-O+i,c=0>u?0:f/h[i-u-1]%10|0}if(r=r||0>n||null!=a[l+1]||(0>u?f:f%h[i-u-1]),r=4>t?(c||r)&&(0==t||t==(e.s<0?3:2)):c>5||5==c&&(4==t||r||6==t&&(o>0?u>0?f/h[i-u]:0:a[l-1])%10&1||t==(e.s<0?8:7)),1>n||!a[0])return a.length=0,r?(n-=e.e+1,a[0]=h[(O-n%O)%O],e.e=-n||0):a[0]=e.e=0,e;if(0==o?(a.length=l,s=1,l--):(a.length=l+1,s=h[O-o],a[l]=u>0?d(f/h[i-u]%h[u])*s:0),r)for(;;){if(0==l){for(o=1,u=a[0];u>=10;u/=10,o++);for(u=a[0]+=s,s=1;u>=10;u/=10,s++);o!=s&&(e.e++,a[0]==b&&(a[0]=1));break}if(a[l]+=s,a[l]!=b)break;a[l--]=0,s=1}for(o=a.length;0===a[--o];a.pop());}e.e>z?e.c=e.e=null:e.e<G&&(e.c=[e.e=0])}return e}var C,M=0,T=E.prototype,q=new E(1),P=20,k=4,B=-7,$=21,G=-1e7,z=1e7,j=!0,H=x,V=!1,W=1,J=100,X={decimalSeparator:".",groupSeparator:",",groupSize:3,secondaryGroupSize:0,fractionGroupSeparator:" ",fractionGroupSize:0};return E.another=n,E.ROUND_UP=0,E.ROUND_DOWN=1,E.ROUND_CEIL=2,E.ROUND_FLOOR=3,E.ROUND_HALF_UP=4,E.ROUND_HALF_DOWN=5,E.ROUND_HALF_EVEN=6,E.ROUND_HALF_CEIL=7,E.ROUND_HALF_FLOOR=8,E.EUCLID=9,E.config=function(){var e,n,t=0,r={},i=arguments,s=i[0],f=s&&"object"==typeof s?function(){return s.hasOwnProperty(n)?null!=(e=s[n]):void 0}:function(){return i.length>t?null!=(e=i[t++]):void 0};return f(n="DECIMAL_PLACES")&&H(e,0,A,2,n)&&(P=0|e),r[n]=P,f(n="ROUNDING_MODE")&&H(e,0,8,2,n)&&(k=0|e),r[n]=k,f(n="EXPONENTIAL_AT")&&(u(e)?H(e[0],-A,0,2,n)&&H(e[1],0,A,2,n)&&(B=0|e[0],$=0|e[1]):H(e,-A,A,2,n)&&(B=-($=0|(0>e?-e:e)))),r[n]=[B,$],f(n="RANGE")&&(u(e)?H(e[0],-A,-1,2,n)&&H(e[1],1,A,2,n)&&(G=0|e[0],z=0|e[1]):H(e,-A,A,2,n)&&(0|e?G=-(z=0|(0>e?-e:e)):j&&L(2,n+" cannot be zero",e))),r[n]=[G,z],f(n="ERRORS")&&(e===!!e||1===e||0===e?(M=0,H=(j=!!e)?x:o):j&&L(2,n+m,e)),r[n]=j,f(n="CRYPTO")&&(e===!!e||1===e||0===e?(V=!(!e||!a),e&&!V&&j&&L(2,"crypto unavailable",a)):j&&L(2,n+m,e)),r[n]=V,f(n="MODULO_MODE")&&H(e,0,9,2,n)&&(W=0|e),r[n]=W,f(n="POW_PRECISION")&&H(e,0,A,2,n)&&(J=0|e),r[n]=J,f(n="FORMAT")&&("object"==typeof e?X=e:j&&L(2,n+" not an object",e)),r[n]=X,r},E.max=function(){return _(arguments,T.lt)},E.min=function(){return _(arguments,T.gt)},E.random=function(){var e=9007199254740992,n=Math.random()*e&2097151?function(){return d(Math.random()*e)}:function(){return 8388608*(1073741824*Math.random()|0)+(8388608*Math.random()|0)};return function(e){var t,r,i,o,u,s=0,f=[],l=new E(q);if(e=null!=e&&H(e,0,A,14)?0|e:P,o=p(e/O),V)if(a&&a.getRandomValues){for(t=a.getRandomValues(new Uint32Array(o*=2));o>s;)u=131072*t[s]+(t[s+1]>>>11),u>=9e15?(r=a.getRandomValues(new Uint32Array(2)),t[s]=r[0],t[s+1]=r[1]):(f.push(u%1e14),s+=2);s=o/2}else if(a&&a.randomBytes){for(t=a.randomBytes(o*=7);o>s;)u=281474976710656*(31&t[s])+1099511627776*t[s+1]+4294967296*t[s+2]+16777216*t[s+3]+(t[s+4]<<16)+(t[s+5]<<8)+t[s+6],u>=9e15?a.randomBytes(7).copy(t,s):(f.push(u%1e14),s+=7);s=o/7}else j&&L(14,"crypto unavailable",a);if(!s)for(;o>s;)u=n(),9e15>u&&(f[s++]=u%1e14);for(o=f[--s],e%=O,o&&e&&(u=S[O-e],f[s]=d(o/u)*u);0===f[s];f.pop(),s--);if(0>s)f=[i=0];else{for(i=-1;0===f[0];f.shift(),i-=O);for(s=1,u=f[0];u>=10;u/=10,s++);O>s&&(i-=O-s)}return l.e=i,l.c=f,l}}(),C=function(){function e(e,n,t){var r,i,o,u,s=0,f=e.length,l=n%R,c=n/R|0;for(e=e.slice();f--;)o=e[f]%R,u=e[f]/R|0,r=c*o+u*l,i=l*o+r%R*R+s,s=(i/t|0)+(r/R|0)+c*u,e[f]=i%t;return s&&e.unshift(s),e}function n(e,n,t,r){var i,o;if(t!=r)o=t>r?1:-1;else for(i=o=0;t>i;i++)if(e[i]!=n[i]){o=e[i]>n[i]?1:-1;break}return o}function r(e,n,t,r){for(var i=0;t--;)e[t]-=i,i=e[t]<n[t]?1:0,e[t]=i*r+e[t]-n[t];for(;!e[0]&&e.length>1;e.shift());}return function(i,o,u,s,f){var l,c,a,h,g,p,m,w,v,N,y,S,R,A,D,F,_,x=i.s==o.s?1:-1,I=i.c,L=o.c;if(!(I&&I[0]&&L&&L[0]))return new E(i.s&&o.s&&(I?!L||I[0]!=L[0]:L)?I&&0==I[0]||!L?0*x:x/0:NaN);for(w=new E(x),v=w.c=[],c=i.e-o.e,x=u+c+1,f||(f=b,c=t(i.e/O)-t(o.e/O),x=x/O|0),a=0;L[a]==(I[a]||0);a++);if(L[a]>(I[a]||0)&&c--,0>x)v.push(1),h=!0;else{for(A=I.length,F=L.length,a=0,x+=2,g=d(f/(L[0]+1)),g>1&&(L=e(L,g,f),I=e(I,g,f),F=L.length,A=I.length),R=F,N=I.slice(0,F),y=N.length;F>y;N[y++]=0);_=L.slice(),_.unshift(0),D=L[0],L[1]>=f/2&&D++;do{if(g=0,l=n(L,N,F,y),0>l){if(S=N[0],F!=y&&(S=S*f+(N[1]||0)),g=d(S/D),g>1)for(g>=f&&(g=f-1),p=e(L,g,f),m=p.length,y=N.length;1==n(p,N,m,y);)g--,r(p,m>F?_:L,m,f),m=p.length,l=1;else 0==g&&(l=g=1),p=L.slice(),m=p.length;if(y>m&&p.unshift(0),r(N,p,y,f),y=N.length,-1==l)for(;n(L,N,F,y)<1;)g++,r(N,y>F?_:L,y,f),y=N.length}else 0===l&&(g++,N=[0]);v[a++]=g,N[0]?N[y++]=I[R]||0:(N=[I[R]],y=1)}while((R++<A||null!=N[0])&&x--);h=null!=N[0],v[0]||v.shift()}if(f==b){for(a=1,x=v[0];x>=10;x/=10,a++);U(w,u+(w.e=a+c*O-1)+1,s,h)}else w.e=c,w.r=+h;return w}}(),h=function(){var e=/^(-?)0([xbo])(?=\w[\w.]*$)/i,n=/^([^.]+)\.$/,t=/^\.([^.]+)$/,r=/^-?(Infinity|NaN)$/,i=/^\s*\+(?=[\w.])|^\s+|\s+$/g;return function(o,u,s,f){var l,c=s?u:u.replace(i,"");if(r.test(c))o.s=isNaN(c)?null:0>c?-1:1;else{if(!s&&(c=c.replace(e,function(e,n,t){return l="x"==(t=t.toLowerCase())?16:"b"==t?2:8,f&&f!=l?e:n}),f&&(l=f,c=c.replace(n,"$1").replace(t,"0.$1")),u!=c))return new E(c,l);j&&L(M,"not a"+(f?" base "+f:"")+" number",u),o.s=null}o.c=o.e=null,M=0}}(),T.absoluteValue=T.abs=function(){var e=new E(this);return e.s<0&&(e.s=1),e},T.ceil=function(){return U(new E(this),this.e+1,2)},T.comparedTo=T.cmp=function(e,n){return M=1,i(this,new E(e,n))},T.decimalPlaces=T.dp=function(){var e,n,r=this.c;if(!r)return null;if(e=((n=r.length-1)-t(this.e/O))*O,n=r[n])for(;n%10==0;n/=10,e--);return 0>e&&(e=0),e},T.dividedBy=T.div=function(e,n){return M=3,C(this,new E(e,n),P,k)},T.dividedToIntegerBy=T.divToInt=function(e,n){return M=4,C(this,new E(e,n),0,1)},T.equals=T.eq=function(e,n){return M=5,0===i(this,new E(e,n))},T.floor=function(){return U(new E(this),this.e+1,3)},T.greaterThan=T.gt=function(e,n){return M=6,i(this,new E(e,n))>0},T.greaterThanOrEqualTo=T.gte=function(e,n){return M=7,1===(n=i(this,new E(e,n)))||0===n},T.isFinite=function(){return!!this.c},T.isInteger=T.isInt=function(){return!!this.c&&t(this.e/O)>this.c.length-2},T.isNaN=function(){return!this.s},T.isNegative=T.isNeg=function(){return this.s<0},T.isZero=function(){return!!this.c&&0==this.c[0]},T.lessThan=T.lt=function(e,n){return M=8,i(this,new E(e,n))<0},T.lessThanOrEqualTo=T.lte=function(e,n){return M=9,-1===(n=i(this,new E(e,n)))||0===n},T.minus=T.sub=function(e,n){var r,i,o,u,s=this,f=s.s;if(M=10,e=new E(e,n),n=e.s,!f||!n)return new E(NaN);if(f!=n)return e.s=-n,s.plus(e);var l=s.e/O,c=e.e/O,a=s.c,h=e.c;if(!l||!c){if(!a||!h)return a?(e.s=-n,e):new E(h?s:NaN);if(!a[0]||!h[0])return h[0]?(e.s=-n,e):new E(a[0]?s:3==k?-0:0)}if(l=t(l),c=t(c),a=a.slice(),f=l-c){for((u=0>f)?(f=-f,o=a):(c=l,o=h),o.reverse(),n=f;n--;o.push(0));o.reverse()}else for(i=(u=(f=a.length)<(n=h.length))?f:n,f=n=0;i>n;n++)if(a[n]!=h[n]){u=a[n]<h[n];break}if(u&&(o=a,a=h,h=o,e.s=-e.s),n=(i=h.length)-(r=a.length),n>0)for(;n--;a[r++]=0);for(n=b-1;i>f;){if(a[--i]<h[i]){for(r=i;r&&!a[--r];a[r]=n);--a[r],a[i]+=b}a[i]-=h[i]}for(;0==a[0];a.shift(),--c);return a[0]?I(e,a,c):(e.s=3==k?-1:1,e.c=[e.e=0],e)},T.modulo=T.mod=function(e,n){var t,r,i=this;return M=11,e=new E(e,n),!i.c||!e.s||e.c&&!e.c[0]?new E(NaN):!e.c||i.c&&!i.c[0]?new E(i):(9==W?(r=e.s,e.s=1,t=C(i,e,0,3),e.s=r,t.s*=r):t=C(i,e,0,W),i.minus(t.times(e)))},T.negated=T.neg=function(){var e=new E(this);return e.s=-e.s||null,e},T.plus=T.add=function(e,n){var r,i=this,o=i.s;if(M=12,e=new E(e,n),n=e.s,!o||!n)return new E(NaN);if(o!=n)return e.s=-n,i.minus(e);var u=i.e/O,s=e.e/O,f=i.c,l=e.c;if(!u||!s){if(!f||!l)return new E(o/0);if(!f[0]||!l[0])return l[0]?e:new E(f[0]?i:0*o)}if(u=t(u),s=t(s),f=f.slice(),o=u-s){for(o>0?(s=u,r=l):(o=-o,r=f),r.reverse();o--;r.push(0));r.reverse()}for(o=f.length,n=l.length,0>o-n&&(r=l,l=f,f=r,n=o),o=0;n;)o=(f[--n]=f[n]+l[n]+o)/b|0,f[n]%=b;return o&&(f.unshift(o),++s),I(e,f,s)},T.precision=T.sd=function(e){var n,t,r=this,i=r.c;if(null!=e&&e!==!!e&&1!==e&&0!==e&&(j&&L(13,"argument"+m,e),e!=!!e&&(e=null)),!i)return null;if(t=i.length-1,n=t*O+1,t=i[t]){for(;t%10==0;t/=10,n--);for(t=i[0];t>=10;t/=10,n++);}return e&&r.e+1>n&&(n=r.e+1),n},T.round=function(e,n){var t=new E(this);return(null==e||H(e,0,A,15))&&U(t,~~e+this.e+1,null!=n&&H(n,0,8,15,w)?0|n:k),t},T.shift=function(e){var n=this;return H(e,-y,y,16,"argument")?n.times("1e"+c(e)):new E(n.c&&n.c[0]&&(-y>e||e>y)?n.s*(0>e?0:1/0):n)},T.squareRoot=T.sqrt=function(){var e,n,i,o,u,s=this,f=s.c,l=s.s,c=s.e,a=P+4,h=new E("0.5");if(1!==l||!f||!f[0])return new E(!l||0>l&&(!f||f[0])?NaN:f?s:1/0);if(l=Math.sqrt(+s),0==l||l==1/0?(n=r(f),(n.length+c)%2==0&&(n+="0"),l=Math.sqrt(n),c=t((c+1)/2)-(0>c||c%2),l==1/0?n="1e"+c:(n=l.toExponential(),n=n.slice(0,n.indexOf("e")+1)+c),i=new E(n)):i=new E(l+""),i.c[0])for(c=i.e,l=c+a,3>l&&(l=0);;)if(u=i,i=h.times(u.plus(C(s,u,a,1))),r(u.c).slice(0,l)===(n=r(i.c)).slice(0,l)){if(i.e<c&&--l,n=n.slice(l-3,l+1),"9999"!=n&&(o||"4999"!=n)){(!+n||!+n.slice(1)&&"5"==n.charAt(0))&&(U(i,i.e+P+2,1),e=!i.times(i).eq(s));break}if(!o&&(U(u,u.e+P+2,0),u.times(u).eq(s))){i=u;break}a+=4,l+=4,o=1}return U(i,i.e+P+1,k,e)},T.times=T.mul=function(e,n){var r,i,o,u,s,f,l,c,a,h,g,p,d,m,w,v=this,N=v.c,y=(M=17,e=new E(e,n)).c;if(!(N&&y&&N[0]&&y[0]))return!v.s||!e.s||N&&!N[0]&&!y||y&&!y[0]&&!N?e.c=e.e=e.s=null:(e.s*=v.s,N&&y?(e.c=[0],e.e=0):e.c=e.e=null),e;for(i=t(v.e/O)+t(e.e/O),e.s*=v.s,l=N.length,h=y.length,h>l&&(d=N,N=y,y=d,o=l,l=h,h=o),o=l+h,d=[];o--;d.push(0));for(m=b,w=R,o=h;--o>=0;){for(r=0,g=y[o]%w,p=y[o]/w|0,s=l,u=o+s;u>o;)c=N[--s]%w,a=N[s]/w|0,f=p*c+a*g,c=g*c+f%w*w+d[u]+r,r=(c/m|0)+(f/w|0)+p*a,d[u--]=c%m;d[u]=r}return r?++i:d.shift(),I(e,d,i)},T.toDigits=function(e,n){var t=new E(this);return e=null!=e&&H(e,1,A,18,"precision")?0|e:null,n=null!=n&&H(n,0,8,18,w)?0|n:k,e?U(t,e,n):t},T.toExponential=function(e,n){return F(this,null!=e&&H(e,0,A,19)?~~e+1:null,n,19)},T.toFixed=function(e,n){return F(this,null!=e&&H(e,0,A,20)?~~e+this.e+1:null,n,20)},T.toFormat=function(e,n){var t=F(this,null!=e&&H(e,0,A,21)?~~e+this.e+1:null,n,21);if(this.c){var r,i=t.split("."),o=+X.groupSize,u=+X.secondaryGroupSize,s=X.groupSeparator,f=i[0],l=i[1],c=this.s<0,a=c?f.slice(1):f,h=a.length;if(u&&(r=o,o=u,u=r,h-=r),o>0&&h>0){for(r=h%o||o,f=a.substr(0,r);h>r;r+=o)f+=s+a.substr(r,o);u>0&&(f+=s+a.slice(r)),c&&(f="-"+f)}t=l?f+X.decimalSeparator+((u=+X.fractionGroupSize)?l.replace(new RegExp("\\d{"+u+"}\\B","g"),"$&"+X.fractionGroupSeparator):l):f}return t},T.toFraction=function(e){var n,t,i,o,u,s,f,l,c,a=j,h=this,g=h.c,p=new E(q),d=t=new E(q),m=f=new E(q);if(null!=e&&(j=!1,s=new E(e),j=a,(!(a=s.isInt())||s.lt(q))&&(j&&L(22,"max denominator "+(a?"out of range":"not an integer"),e),e=!a&&s.c&&U(s,s.e+1,1).gte(q)?s:null)),!g)return h.toString();for(c=r(g),o=p.e=c.length-h.e-1,p.c[0]=S[(u=o%O)<0?O+u:u],e=!e||s.cmp(p)>0?o>0?p:d:s,u=z,z=1/0,s=new E(c),f.c[0]=0;l=C(s,p,0,1),i=t.plus(l.times(m)),1!=i.cmp(e);)t=m,m=i,d=f.plus(l.times(i=d)),f=i,p=s.minus(l.times(i=p)),s=i;return i=C(e.minus(t),m,0,1),f=f.plus(i.times(d)),t=t.plus(i.times(m)),f.s=d.s=h.s,o*=2,n=C(d,m,o,k).minus(h).abs().cmp(C(f,t,o,k).minus(h).abs())<1?[d.toString(),m.toString()]:[f.toString(),t.toString()],z=u,n},T.toNumber=function(){return+this},T.toPower=T.pow=function(e,n){var t,r,i,o=d(0>e?-e:+e),u=this;if(null!=n&&(M=23,n=new E(n)),!H(e,-y,y,23,"exponent")&&(!isFinite(e)||o>y&&(e/=0)||parseFloat(e)!=e&&!(e=NaN))||0==e)return t=Math.pow(+u,e),new E(n?t%n:t);for(n?e>1&&u.gt(q)&&u.isInt()&&n.gt(q)&&n.isInt()?u=u.mod(n):(i=n,n=null):J&&(t=p(J/O+2)),r=new E(q);;){if(o%2){if(r=r.times(u),!r.c)break;t?r.c.length>t&&(r.c.length=t):n&&(r=r.mod(n))}if(o=d(o/2),!o)break;u=u.times(u),t?u.c&&u.c.length>t&&(u.c.length=t):n&&(u=u.mod(n))}return n?r:(0>e&&(r=q.div(r)),i?r.mod(i):t?U(r,J,k):r)},T.toPrecision=function(e,n){return F(this,null!=e&&H(e,1,A,24,"precision")?0|e:null,n,24)},T.toString=function(e){var n,t=this,i=t.s,o=t.e;return null===o?i?(n="Infinity",0>i&&(n="-"+n)):n="NaN":(n=r(t.c),n=null!=e&&H(e,2,64,25,"base")?D(l(n,o),0|e,10,i):B>=o||o>=$?f(n,o):l(n,o),0>i&&t.c[0]&&(n="-"+n)),n},T.truncated=T.trunc=function(){return U(new E(this),this.e+1,1)},T.valueOf=T.toJSON=function(){var e,n=this,t=n.e;return null===t?n.toString():(e=r(n.c),e=B>=t||t>=$?f(e,t):l(e,t),n.s<0?"-"+e:e)},null!=e&&E.config(e),E}function t(e){var n=0|e;return e>0||e===n?n:n-1}function r(e){for(var n,t,r=1,i=e.length,o=e[0]+"";i>r;){for(n=e[r++]+"",t=O-n.length;t--;n="0"+n);o+=n}for(i=o.length;48===o.charCodeAt(--i););return o.slice(0,i+1||1)}function i(e,n){var t,r,i=e.c,o=n.c,u=e.s,s=n.s,f=e.e,l=n.e;if(!u||!s)return null;if(t=i&&!i[0],r=o&&!o[0],t||r)return t?r?0:-s:u;if(u!=s)return u;if(t=0>u,r=f==l,!i||!o)return r?0:!i^t?1:-1;if(!r)return f>l^t?1:-1;for(s=(f=i.length)<(l=o.length)?f:l,u=0;s>u;u++)if(i[u]!=o[u])return i[u]>o[u]^t?1:-1;return f==l?0:f>l^t?1:-1}function o(e,n,t){return(e=c(e))>=n&&t>=e}function u(e){return"[object Array]"==Object.prototype.toString.call(e)}function s(e,n,t){for(var r,i,o=[0],u=0,s=e.length;s>u;){for(i=o.length;i--;o[i]*=n);for(o[r=0]+=N.indexOf(e.charAt(u++));r<o.length;r++)o[r]>t-1&&(null==o[r+1]&&(o[r+1]=0),o[r+1]+=o[r]/t|0,o[r]%=t)}return o.reverse()}function f(e,n){return(e.length>1?e.charAt(0)+"."+e.slice(1):e)+(0>n?"e":"e+")+n}function l(e,n){var t,r;if(0>n){for(r="0.";++n;r+="0");e=r+e}else if(t=e.length,++n>t){for(r="0",n-=t;--n;r+="0");e+=r}else t>n&&(e=e.slice(0,n)+"."+e.slice(n));return e}function c(e){return e=parseFloat(e),0>e?p(e):d(e)}var a,h,g=/^-?(\d+(\.\d*)?|\.\d+)(e[+-]?\d+)?$/i,p=Math.ceil,d=Math.floor,m=" not a boolean or binary digit",w="rounding mode",v="number type has more than 15 significant digits",N="0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ$_",b=1e14,O=14,y=9007199254740991,S=[1,10,100,1e3,1e4,1e5,1e6,1e7,1e8,1e9,1e10,1e11,1e12,1e13],R=1e7,A=1e9;if("undefined"!=typeof crypto&&(a=crypto),"function"==typeof define&&define.amd)define(function(){return n()});else if("undefined"!=typeof module&&module.exports){if(module.exports=n(),!a)try{a=require("crypto")}catch(E){}}else e||(e="undefined"!=typeof self?self:Function("return this")()),e.BigNumber=n()}(this); </script> <style> body{ font-family: 'HelveticaNeue-Light', 'Helvetica Neue Light', 'Helvetica Neue', 'Helvetica', 'Arial', 'Lucida Grande', sans-serif; background: #E2E2E2; } *, *:after, *:before { box-sizing: border-box; margin: 0; padding: 0; } #pleasewait{ position: absolute; top: 0; left: 0; width: 100%; height: 100%; padding: 0; margin: 0; } #infomessage { text-align: center; font-size: 1rem; margin: 0 2rem 4.5rem; } .wrapper{ background: #E2E2E2; position: absolute; top: 0; left: 0; width: 100%; height: 100%; padding: 0; margin: 0; display:none; text-align: center; } .title { text-align: center; font-size: 1.2rem; margin: 1rem 0rem; } .message { text-align: center; font-size: 1rem; /*margin: 0 2rem 4.5rem;*/ } #passwordField { text-align: center; font-size: 1rem; margin: 1rem 0rem; /*margin: 0 2rem 4.5rem;*/ } .wrapper button { background: transparent; border: none; color: #1678E5; height: 3rem; font-size: 1rem; width: 50%; position: absolute; bottom: 0; cursor: pointer; } #cancel-button { border-top: 1px solid #B4B4B4; border-right: 1px solid #B4B4B4; left: 0; border-radius: 0 0 0 10px; } #confirm-button { border-top: 1px solid #B4B4B4; right: 0; border-radius: 0 0 10px 0; } .wrapper button:focus, .wrapper button:hover { font-weight: bold; background: #EFEFEF; } .wrapper button:active { background: #D6D6D6; } .button { margin: 1rem 0rem; display: inline-block; padding: 9px 15px; background-color: #3898EC; color: white; border: 0; line-height: inherit; text-decoration: none; cursor: pointer; border-radius: 0; } input.button { -webkit-appearance: button; } </style> <body> <div id="pleasewait"> <br/> <p id="infomessage">Please wait...</p> </div> <form id="form" class="wrapper"> <br/> <p id="message" class="message"></p> <p id="passwordField"><label>Password Required:</label><input id="password" type="password" /></p> <button id="cancel-button" type="button" autofocus>Cancel</button> <button id="confirm-button" type="button" >Confirm</button> </form> <div id="modal-dialog" class="wrapper"> <h3 id="modal-dialog-title" class="title">Title</h3> <p id="modal-dialog-message" class="message">Message</p> <span id="modal-dialog-button" class="button">Ok</span> </div> <script> var noMessageReceivedYet = true; var closedByCode = false; var pleaseWait = document.getElementById("pleasewait"); var form = document.getElementById("form"); var cancelButton = document.getElementById("cancel-button"); var confirmButton = document.getElementById("confirm-button"); var message = document.getElementById("message"); var infoMessage = document.getElementById("infomessage"); var password = document.getElementById("password"); var passwordField = document.getElementById("passwordField"); var modalDialog = document.getElementById("modal-dialog"); var modalDialogButton = document.getElementById("modal-dialog-button"); var modalDialogTitle = document.getElementById("modal-dialog-title"); var modalDialogMessage = document.getElementById("modal-dialog-message"); var firstUrl = null; var inIframe = true; var source = null; if(window.opener){ inIframe = false; source = window.opener; }else if(window.parent != window){ source = window.parent; }else{ console.log("closing"); window.close(); } function closeWindow(){ closedByCode = true; window.close(); } function showWaiting(text){ if(!text){ text = "Please wait..." } infoMessage.innerHTML = text; pleaseWait.style.display = "block"; form.style.display = "none"; } function hideWaiting(){ pleaseWait.style.display = "none"; form.style.display = "block"; window.onbeforeunload = null; } function showMessage(title, message, callback, buttonText){ modalDialog.style.display = "block"; modalDialogTitle.innerHTML = title; modalDialogMessage.innerHTML = ""; if((typeof message) == "string"){ modalDialogMessage.innerHTML += message; }else{ modalDialogMessage.appendChild(message); } modalDialogMessage.appendChild(document.createElement('br')); if(!buttonText){ buttonText = "Ok"; } modalDialogButton.innerHTML = buttonText; modalDialogButton.onclick = function(){ modalDialogButton.onclick = null; modalDialog.style.display = "none"; if(callback){ callback(); } } } function hideMessage(){ modalDialog.style.display = "none"; modalDialogButton.onclick = null; } function sendAsync(url,payload, callback) { var request = new XMLHttpRequest(); request.open('POST', url, true); request.setRequestHeader('Content-Type','application/json'); request.onreadystatechange = function() { if (request.readyState === 4) { var result = request.responseText; var error = null; try { result = JSON.parse(result); } catch(e) { var message = !!result && !!result.error && !!result.error.message ? result.error.message : 'Invalid JSON RPC response: ' + JSON.stringify(result); error = {message:message,type:"JsonParse"}; } callback(error, result); } }; try { request.send(JSON.stringify(payload)); } catch(e) { callback({message:'CONNECTION ERROR: Couldn\'t connect to node '+ url +'.',type:"noConnection"}); } } function addBlocky(message, address){ var icon = blockies.create({ seed: address, size: 8, scale: 6 }); message.appendChild(icon); } function askAuthorization(transactionInfo, data, requireUnlock, sourceWindow){ var value = transactionInfo["value"] ? transactionInfo.value : "0"; var gasProvided = transactionInfo.gas; var gasPriceProvided = transactionInfo.gasPrice; var gasPrice = new BigNumber(gasPriceProvided,16); var gas = new BigNumber(gasProvided,16); var weiValue = new BigNumber(value,16); var gasWeiValue = gas.times(gasPrice); var etherValue = weiValue.dividedBy(new BigNumber("1000000000000000000")); var gasEtherValue = gasWeiValue.dividedBy(new BigNumber("1000000000000000000")); hideWaiting(); message.innerHTML = ""; addBlocky(message,transactionInfo.from); var span = document.createElement('span'); span.style="font-size:3em;"; span.innerHTML = "&nbsp;&nbsp;&nbsp;" + "&#x2192;" + "&nbsp;&nbsp;&nbsp;"; message.appendChild(span); addBlocky(message,transactionInfo.to); message.appendChild(document.createElement('br')); var textSpan = document.createElement("span"); message.appendChild(textSpan); textSpan.innerHTML = etherValue.toFormat() + " ether <br/> + gas cost (" + gasEtherValue.toFormat() + " ether )" if(requireUnlock){ passwordField.style.display = "block"; }else{ passwordField.style.display = "none"; } cancelButton.onclick = function(){ sourceWindow.postMessage({id:data.id,result:null,error:{message:"Not Authorized"},type:"cancel"},firstUrl); closeWindow(); } var submitFunc = function(){ window.onbeforeunload = function (event) { if(!closedByCode){ return "do not close now as a transaction is progress, this cannot be canceled and we wait for an answer"; } }; if(requireUnlock){ if(password.value == ""){ password.style.border = "2px solid red"; return false; } password.style.border = "none"; var params = [transactionInfo.from,password.value,3]; showWaiting("Please wait...<br/>Do not close the window."); sendAsync(data.url,{id:999992,method:"personal_unlockAccount",params:params},function(error,result){ if(error || result.error){ showMessage("Error unlocking account", "Please retry.", hideWaiting); }else{ sendAsync(data.url,data.payload,function(error,result){ sourceWindow.postMessage({id:data.id,result:result,error:error},firstUrl); closeWindow(); }); } }); }else{ sendAsync(data.url,data.payload,function(error,result){ if(result && result.error){ processMessage(data,sourceWindow); }else{ sourceWindow.postMessage({id:data.id,result:result,error:error},firstUrl); closeWindow(); } }); showWaiting(); } return false; } form.onsubmit = submitFunc; confirmButton.onclick = submitFunc; } function needToAndCanUnlockAccount(address,url,callback){ sendAsync(url,{id:9999990,method:"eth_sign",params:[address,"0xc6888fa8d57087278718986382264244252f8d57087278718986382264244252f"]},function(error,result){ if(error || result.error){ sendAsync(url,{id:9999991,method:"personal_listAccounts",params:[]},function(error,result){ if(error || result.error){ callback(true,false); }else{ callback(true,true); } }); }else{ callback(false); } }); } function receiveMessage(event){ if(event.source != source){ return; } if(firstUrl){ if(firstUrl != event.origin){ return; } }else{ firstUrl = event.origin; } hideMessage(); noMessageReceivedYet = false; var data = event.data; try{ processMessage(data,event.source); }catch(e){ event.source.postMessage({id:data.id,result:null,error:{message:"Could not process message data"},type:"notValid"},firstUrl); showMessage("Error","The application has sent invalid data", function(){ closeWindow(); }); } } var allowedMethods = [ "web3_clientVersion" ,"web3_sha3" ,"net_version" ,"net_peerCount" ,"net_listening" ,"eth_protocolVersion" ,"eth_syncing" ,"eth_coinbase" ,"eth_mining" ,"eth_hashrate" ,"eth_gasPrice" ,"eth_accounts" ,"eth_blockNumber" ,"eth_getBalance" ,"eth_getStorageAt" ,"eth_getTransactionCount" ,"eth_getBlockTransactionCountByHash" ,"eth_getBlockTransactionCountByNumber" ,"eth_getUncleCountByBlockHash" ,"eth_getUncleCountByBlockNumber" ,"eth_getCode" ,"eth_sendRawTransaction" ,"eth_call" ,"eth_estimateGas" ,"eth_getBlockByHash" ,"eth_getBlockByNumber" ,"eth_getTransactionByHash" ,"eth_getTransactionByBlockHashAndIndex" ,"eth_getTransactionByBlockNumberAndIndex" ,"eth_getTransactionReceipt" ,"eth_getUncleByBlockHashAndIndex" ,"eth_getUncleByBlockNumberAndIndex" ,"eth_getCompilers" ,"eth_compileLLL" ,"eth_compileSolidity" ,"eth_compileSerpent" ,"eth_newFilter" ,"eth_newBlockFilter" ,"eth_newPendingTransactionFilter" ,"eth_uninstallFilter" ,"eth_getFilterChanges" ,"eth_getFilterLogs" ,"eth_getLogs" ,"eth_getWork" ,"eth_submitWork" ,"eth_submitHashrate" // ,"shh_post" // ,"shh_version" // ,"shh_newIdentity" // ,"shh_hasIdentity" // ,"shh_newGroup" // ,"shh_addToGroup" // ,"shh_newFilter" // ,"shh_uninstallFilter" // ,"shh_getFilterChanges" // ,"shh_getMessages" ]; function isMethodAllowed(method){ return allowedMethods.indexOf(method) != -1; } function processMessage(data, sourceWindow){ if(inIframe){ if(isMethodAllowed(data.payload.method)){ sendAsync(data.url,data.payload,function(error,result){ sourceWindow.postMessage({id:data.id,result:result,error:error},firstUrl); }); }else{ sourceWindow.postMessage({id:data.id,result:null,error:{message:"method (" + data.payload.method + ") not allowed in iframe"},type:"notAllowed"},firstUrl); } }else if(data.payload.method == "eth_sendTransaction"){ var transactionInfo = null; if(data.payload.params.length > 0){ if(data.payload.params[0]["gas"] && data.payload.params[0]["gasPrice"] && data.payload.params[0]["to"] && data.payload.params[0]["from"]){ transactionInfo = data.payload.params[0]; } } if(transactionInfo != null){ needToAndCanUnlockAccount(transactionInfo.from,data.url,function(requireUnlock,canUnlock){ if(requireUnlock && canUnlock){ askAuthorization(transactionInfo,data,true, sourceWindow); }else if(!requireUnlock){ askAuthorization(transactionInfo,data,false,sourceWindow); }else if(requireUnlock && !canUnlock){ var messageHtml = document.createElement('span'); addBlocky(messageHtml,transactionInfo.from); messageHtml.appendChild(document.createElement('br')); var span = document.createElement('span'); span.innerHTML = "You need to unlock your account first : <br/>" + transactionInfo.from; messageHtml.appendChild(span); showMessage("Account Locked",messageHtml,function(){ processMessage(data,sourceWindow); }, "Done"); } }); }else{ sourceWindow.postMessage({id:data.id,result:null,error:{message:"Need to specify from , to, gas and gasPrice"},type:"notValid"},firstUrl); closeWindow(); } }else{ sourceWindow.postMessage({id:data.id,result:null,error:{message:"method (" + data.payload.method + ") not allowed in popup"},type:"notAllowed"},firstUrl); } } function checkMessageNotReceived(){ if(noMessageReceivedYet){ showMessage("Error","No transaction received. Please make sure popup are not blocked.", function(){ closeWindow(); }); } } setTimeout(checkMessageNotReceived,1000); window.addEventListener("message", receiveMessage); if(source){ source.postMessage("ready","*"); } </script> </body> </html> ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 05 Jun 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-107 https://eips.ethereum.org/EIPS/eip-107 Ethereum Domain Name Service - Specification Standards Track/ERC # Abstract This draft EIP describes the details of the Ethereum Name Service, a proposed protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes. The goal of domain names is to provide stable, human-readable identifiers that can be used to specify network resources. In this way, users can enter a memorable string, such as 'vitalik.wallet' or 'www.mysite.swarm', and be directed to the appropriate resource. The mapping between names and resources may change over time, so a user may change wallets, a website may change hosts, or a swarm document may be updated to a new version, without the domain name changing. Further, a domain need not specify a single resource; different record types allow the same domain to reference different resources. For instance, a browser may resolve 'mysite.swarm' to the IP address of its server by fetching its A (address) record, while a mail client may resolve the same address to a mail server by fetching its MX (mail exchanger) record. # Motivation Existing [specifications](https://github.com/ethereum/wiki/wiki/Registrar-ABI) and [implementations](https://ethereum.gitbooks.io/frontier-guide/content/registrar_services.html) for name resolution in Ethereum provide basic functionality, but suffer several shortcomings that will significantly limit their long-term usefulness: - A single global namespace for all names with a single 'centralised' resolver. - Limited or no support for delegation and sub-names/sub-domains. - Only one record type, and no support for associating multiple copies of a record with a domain. - Due to a single global implementation, no support for multiple different name allocation systems. - Conflation of responsibilities: Name resolution, registration, and whois information. Use-cases that these features would permit include: - Support for subnames/sub-domains - eg, live.mysite.tld and forum.mysite.tld. - Multiple services under a single name, such as a DApp hosted in Swarm, a Whisper address, and a mail server. - Support for DNS record types, allowing blockchain hosting of 'legacy' names. This would permit an Ethereum client such as Mist to resolve the address of a traditional website, or the mail server for an email address, from a blockchain name. - DNS gateways, exposing ENS domains via the Domain Name Service, providing easier means for legacy clients to resolve and connect to blockchain services. The first two use-cases, in particular, can be observed everywhere on the present-day internet under DNS, and we believe them to be fundamental features of a name service that will continue to be useful as the Ethereum platform develops and matures. The normative parts of this document does not specify an implementation of the proposed system; its purpose is to document a protocol that different resolver implementations can adhere to in order to facilitate consistent name resolution. An appendix provides sample implementations of resolver contracts and libraries, which should be treated as illustrative examples only. Likewise, this document does not attempt to specify how domains should be registered or updated, or how systems can find the owner responsible for a given domain. Registration is the responsibility of registrars, and is a governance matter that will necessarily vary between top-level domains. Updating of domain records can also be handled separately from resolution. Some systems, such as swarm, may require a well defined interface for updating domains, in which event we anticipate the development of a standard for this. # Specification ## Overview The ENS system comprises three main parts: - The ENS registry - Resolvers - Registrars The registry is a single contract that provides a mapping from any registered name to the resolver responsible for it, and permits the owner of a name to set the resolver address, and to create subdomains, potentially with different owners to the parent domain. Resolvers are responsible for performing resource lookups for a name - for instance, returning a contract address, a content hash, or IP address(es) as appropriate. The resolver specification, defined here and extended in other EIPs, defines what methods a resolver may implement to support resolving different types of records. Registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts. Resolving a name in ENS is a two-step process. First, the ENS registry is called with the name to resolve, after hashing it using the procedure described below. If the record exists, the registry returns the address of its resolver. Then, the resolver is called, using the method appropriate to the resource being requested. The resolver then returns the desired result. For example, suppose you wish to find the address of the token contract associated with 'beercoin.eth'. First, get the resolver: ```javascript var node = namehash("beercoin.eth"); var resolver = ens.resolver(node); ``` Then, ask the resolver for the address for the contract: ```javascript var address = resolver.addr(node); ``` Because the `namehash` procedure depends only on the name itself, this can be precomputed and inserted into a contract, removing the need for string manipulation, and permitting O(1) lookup of ENS records regardless of the number of components in the raw name. ## Name Syntax ENS names must conform to the following syntax: <pre>&lt;domain> ::= &lt;label> | &lt;domain> "." &lt;label> &lt;label> ::= any valid string label per [UTS46](https://unicode.org/reports/tr46/) </pre> In short, names consist of a series of dot-separated labels. Each label must be a valid normalised label as described in [UTS46](https://unicode.org/reports/tr46/) with the options `transitional=false` and `useSTD3AsciiRules=true`. For Javascript implementations, a [library](https://www.npmjs.com/package/idna-uts46) is available that normalises and checks names. Note that while upper and lower case letters are allowed in names, the UTS46 normalisation process case-folds labels before hashing them, so two names with different case but identical spelling will produce the same namehash. Labels and domains may be of any length, but for compatibility with legacy DNS, it is recommended that labels be restricted to no more than 64 characters each, and complete ENS names to no more than 255 characters. For the same reason, it is recommended that labels do not start or end with hyphens, or start with digits. ## namehash algorithm Before being used in ENS, names are hashed using the 'namehash' algorithm. This algorithm recursively hashes components of the name, producing a unique, fixed-length string for any valid input domain. The output of namehash is referred to as a 'node'. Pseudocode for the namehash algorithm is as follows: ``` def namehash(name): if name == '': return '\0' * 32 else: label, _, remainder = name.partition('.') return sha3(namehash(remainder) + sha3(label)) ``` Informally, the name is split into labels, each label is hashed. Then, starting with the last component, the previous output is concatenated with the label hash and hashed again. The first component is concatenated with 32 '0' bytes. Thus, 'mysite.swarm' is processed as follows: ``` node = '\0' * 32 node = sha3(node + sha3('swarm')) node = sha3(node + sha3('mysite')) ``` Implementations should conform to the following test vectors for namehash: namehash('') = 0x0000000000000000000000000000000000000000000000000000000000000000 namehash('eth') = 0x93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4ae namehash('foo.eth') = 0xde9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f ## Registry specification The ENS registry contract exposes the following functions: ```solidity function owner(bytes32 node) constant returns (address); ``` Returns the owner (registrar) of the specified node. ```solidity function resolver(bytes32 node) constant returns (address); ``` Returns the resolver for the specified node. ```solidity function ttl(bytes32 node) constant returns (uint64); ``` Returns the time-to-live (TTL) of the node; that is, the maximum duration for which a node's information may be cached. ```solidity function setOwner(bytes32 node, address owner); ``` Transfers ownership of a node to another registrar. This function may only be called by the current owner of `node`. A successful call to this function logs the event `Transfer(bytes32 indexed, address)`. ```solidity function setSubnodeOwner(bytes32 node, bytes32 label, address owner); ``` Creates a new node, `sha3(node, label)` and sets its owner to `owner`, or updates the node with a new owner if it already exists. This function may only be called by the current owner of `node`. A successful call to this function logs the event `NewOwner(bytes32 indexed, bytes32 indexed, address)`. ```solidity function setResolver(bytes32 node, address resolver); ``` Sets the resolver address for `node`. This function may only be called by the owner of `node`. A successful call to this function logs the event `NewResolver(bytes32 indexed, address)`. ```solidity function setTTL(bytes32 node, uint64 ttl); ``` Sets the TTL for a node. A node's TTL applies to the 'owner' and 'resolver' records in the registry, as well as to any information returned by the associated resolver. ## Resolver specification Resolvers may implement any subset of the record types specified here. Where a record types specification requires a resolver to provide multiple functions, the resolver MUST implement either all or none of them. Resolvers MUST specify a fallback function that throws. Resolvers have one mandatory function: ```solidity function supportsInterface(bytes4 interfaceID) constant returns (bool) ``` The `supportsInterface` function is documented in [EIP-165](/EIPS/eip-165), and returns true if the resolver implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a resolver returns `true` for `supportsInterface()`, it must implement the functions specified in that interface. `supportsInterface` must always return true for `0x01ffc9a7`, which is the interface ID of `supportsInterface` itself. Currently standardised resolver interfaces are specified in the table below. The following interfaces are defined: | Interface name | Interface hash | Specification | | --- | --- | --- | | `addr` | 0x3b3b57de | [Contract address](#addr) | | `name` | 0x691f3431 | #181 | | `ABI` | 0x2203ab56 | #205 | | `pubkey` | 0xc8690233 | #619 | EIPs may define new interfaces to be added to this registry. ### <a name="addr"></a>Contract Address Interface Resolvers wishing to support contract address resources must provide the following function: ```solidity function addr(bytes32 node) constant returns (address); ``` If the resolver supports `addr` lookups but the requested node does not have an addr record, the resolver MUST return the zero address. Clients resolving the `addr` record MUST check for a zero return value, and treat this in the same manner as a name that does not have a resolver specified - that is, refuse to send funds to or interact with the address. Failure to do this can result in users accidentally sending funds to the 0 address. Changes to an address MUST trigger the following event: ```solidity event AddrChanged(bytes32 indexed node, address a); ``` # Appendix A: Registry Implementation ```solidity contract ENS { struct Record { address owner; address resolver; uint64 ttl; } mapping(bytes32=>Record) records; event NewOwner(bytes32 indexed node, bytes32 indexed label, address owner); event Transfer(bytes32 indexed node, address owner); event NewResolver(bytes32 indexed node, address resolver); modifier only_owner(bytes32 node) { if(records[node].owner != msg.sender) throw; _ } function ENS(address owner) { records[0].owner = owner; } function owner(bytes32 node) constant returns (address) { return records[node].owner; } function resolver(bytes32 node) constant returns (address) { return records[node].resolver; } function ttl(bytes32 node) constant returns (uint64) { return records[node].ttl; } function setOwner(bytes32 node, address owner) only_owner(node) { Transfer(node, owner); records[node].owner = owner; } function setSubnodeOwner(bytes32 node, bytes32 label, address owner) only_owner(node) { var subnode = sha3(node, label); NewOwner(node, label, owner); records[subnode].owner = owner; } function setResolver(bytes32 node, address resolver) only_owner(node) { NewResolver(node, resolver); records[node].resolver = resolver; } function setTTL(bytes32 node, uint64 ttl) only_owner(node) { NewTTL(node, ttl); records[node].ttl = ttl; } } ``` # Appendix B: Sample Resolver Implementations ### Built-in resolver The simplest possible resolver is a contract that acts as its own name resolver by implementing the contract address resource profile: ```solidity contract DoSomethingUseful { // Other code function addr(bytes32 node) constant returns (address) { return this; } function supportsInterface(bytes4 interfaceID) constant returns (bool) { return interfaceID == 0x3b3b57de || interfaceID == 0x01ffc9a7; } function() { throw; } } ``` Such a contract can be inserted directly into the ENS registry, eliminating the need for a separate resolver contract in simple use-cases. However, the requirement to 'throw' on unknown function calls may interfere with normal operation of some types of contract. ### Standalone resolver A basic resolver that implements the contract address profile, and allows only its owner to update records: ```solidity contract Resolver { event AddrChanged(bytes32 indexed node, address a); address owner; mapping(bytes32=>address) addresses; modifier only_owner() { if(msg.sender != owner) throw; _ } function Resolver() { owner = msg.sender; } function addr(bytes32 node) constant returns(address) { return addresses[node]; } function setAddr(bytes32 node, address addr) only_owner { addresses[node] = addr; AddrChanged(node, addr); } function supportsInterface(bytes4 interfaceID) constant returns (bool) { return interfaceID == 0x3b3b57de || interfaceID == 0x01ffc9a7; } function() { throw; } } ``` After deploying this contract, use it by updating the ENS registry to reference this contract for a name, then calling `setAddr()` with the same node to set the contract address it will resolve to. ### Public resolver Similar to the resolver above, this contract only supports the contract address profile, but uses the ENS registry to determine who should be allowed to update entries: ```solidity contract PublicResolver { event AddrChanged(bytes32 indexed node, address a); event ContentChanged(bytes32 indexed node, bytes32 hash); ENS ens; mapping(bytes32=>address) addresses; modifier only_owner(bytes32 node) { if(ens.owner(node) != msg.sender) throw; _ } function PublicResolver(address ensAddr) { ens = ENS(ensAddr); } function addr(bytes32 node) constant returns (address ret) { ret = addresses[node]; } function setAddr(bytes32 node, address addr) only_owner(node) { addresses[node] = addr; AddrChanged(node, addr); } function supportsInterface(bytes4 interfaceID) constant returns (bool) { return interfaceID == 0x3b3b57de || interfaceID == 0x01ffc9a7; } function() { throw; } } ``` # Appendix C: Sample Registrar Implementation This registrar allows users to register names at no cost if they are the first to request them. ```solidity contract FIFSRegistrar { ENS ens; bytes32 rootNode; function FIFSRegistrar(address ensAddr, bytes32 node) { ens = ENS(ensAddr); rootNode = node; } function register(bytes32 subnode, address owner) { var node = sha3(rootNode, subnode); var currentOwner = ens.owner(node); if(currentOwner != 0 && currentOwner != msg.sender) throw; ens.setSubnodeOwner(rootNode, subnode, owner); } } ``` Mon, 04 Apr 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-137 https://eips.ethereum.org/EIPS/eip-137 REVERT instruction Standards Track/Core ## Simple Summary The `REVERT` instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason. ## Abstract The `REVERT` instruction will stop execution, roll back all state changes done so far and provide a pointer to a memory section, which can be interpreted as an error code or message. While doing so, it will not consume all the remaining gas. ## Motivation Currently this is not possible. There are two practical ways to revert a transaction from within a contract: running out of gas or executing an invalid instruction. Both of these options will consume all remaining gas. Additionally, reverting an EVM execution means that all changes, including LOGs, are lost and there is no way to convey a reason for aborting an EVM execution. ## Specification On blocks with `block.number >= BYZANTIUM_FORK_BLKNUM`, the `REVERT` instruction is introduced at `0xfd`. It expects two stack items, the top item is the `memory_offset` followed by `memory_length`. It does not produce any stack elements because it stops execution. The semantics of `REVERT` with respect to memory and memory cost are identical to those of `RETURN`. The sequence of bytes given by `memory_offset` and `memory_length` is called "error message" in the following. The effect of `REVERT` is that execution is aborted, considered as failed, and state changes are rolled back. The error message will be available to the caller in the returndata buffer and will also be copied to the output area, i.e. it is handled in the same way as the regular return data is handled. The cost of the `REVERT` instruction equals to that of the `RETURN` instruction, i.e. the rollback itself does not consume all gas, the contract only has to pay for memory. In case there is not enough gas left to cover the cost of `REVERT` or there is a stack underflow, the effect of the `REVERT` instruction will equal to that of a regular out of gas exception, i.e. it will consume all gas. In the same way as all other failures, the calling opcode returns `0` on the stack following a `REVERT` opcode in the callee. In case `REVERT` is used in the context of a `CREATE` or `CREATE2` call, no code is deployed, `0` is put on the stack and the error message is available in the returndata buffer. The content of the optionally provided memory section is not defined by this EIP, but is a candidate for another Informational EIP. ## Backwards Compatibility This change has no effect on contracts created in the past unless they contain `0xfd` as an instruction. ## Test Cases ``` 6c726576657274656420646174616000557f726576657274206d657373616765000000000000000000000000000000000000600052600e6000fd ``` should: - return `0x726576657274206d657373616765` as `REVERT` data, - the storage at key `0x0` should be left as unset and - use 20024 gas in total. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 06 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-140 https://eips.ethereum.org/EIPS/eip-140 Designated invalid EVM instruction Standards Track/Core ## Abstract An instruction is designated to remain as an invalid instruction. ## Motivation The invalid instruction can be used as a distinct reason to abort execution. ## Specification The opcode `0xfe` is the `INVALID` instruction. It can be used to abort the execution (i.e. duplicates as an `ABORT` instruction). ## Backwards Compatibility This instruction was never used and therefore has no effect on past contracts. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 09 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-141 https://eips.ethereum.org/EIPS/eip-141 Bitwise shifting instructions in EVM Standards Track/Core ## Abstract Native bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to use by a contract. ## Motivation EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing `SHL` and `SHR` using arithmetic cost each 35 gas, while the proposed instructions take 3 gas. ## Specification The following instructions are introduced: ### `0x1b`: `SHL` (shift left) The `SHL` instruction (shift left) pops 2 values from the stack, first `arg1` and then `arg2`, and pushes on the stack `arg2` shifted to the left by `arg1` number of bits. The result is equal to ``` (arg2 * 2^arg1) mod 2^256 ``` Notes: - The value (`arg2`) is interpreted as an unsigned number. - The shift amount (`arg1`) is interpreted as an unsigned number. - If the shift amount (`arg1`) is greater or equal 256 the result is 0. - This is equivalent to `PUSH1 2 EXP MUL`. ### `0x1c`: `SHR` (logical shift right) The `SHR` instruction (logical shift right) pops 2 values from the stack, first `arg1` and then `arg2`, and pushes on the stack `arg2` shifted to the right by `arg1` number of bits with zero fill. The result is equal to ``` floor(arg2 / 2^arg1) ``` Notes: - The value (`arg2`) is interpreted as an unsigned number. - The shift amount (`arg1`) is interpreted as an unsigned number. - If the shift amount (`arg1`) is greater or equal 256 the result is 0. - This is equivalent to `PUSH1 2 EXP DIV`. ### `0x1d`: `SAR` (arithmetic shift right) The `SAR` instruction (arithmetic shift right) pops 2 values from the stack, first `arg1` and then `arg2`, and pushes on the stack `arg2` shifted to the right by `arg1` number of bits with sign extension. The result is equal to ``` floor(arg2 / 2^arg1) ``` Notes: - The value (`arg2`) is interpreted as a signed number. - The shift amount (`arg1`) is interpreted as an unsigned number. - If the shift amount (`arg1`) is greater or equal 256 the result is 0 if `arg2` is non-negative or -1 if `arg2` is negative. - This is **not** equivalent to `PUSH1 2 EXP SDIV`, since it rounds differently. See `SDIV(-1, 2) == 0`, while `SAR(-1, 1) == -1`. The cost of the shift instructions is set at `verylow` tier (3 gas). ## Rationale Instruction operands were chosen to fit the more natural use case of shifting a value already on the stack. This means the operand order is swapped compared to most arithmetic instructions. ## Backwards Compatibility The newly introduced instructions have no effect on bytecode created in the past. ## Test Cases ### `SHL` (shift left) 1. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x00 SHL --- 0x0000000000000000000000000000000000000000000000000000000000000001 ``` 2. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x01 SHL --- 0x0000000000000000000000000000000000000000000000000000000000000002 ``` 3. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0xff SHL --- 0x8000000000000000000000000000000000000000000000000000000000000000 ``` 4. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x0100 SHL --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 5. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x0101 SHL --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 6. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x00 SHL --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 7. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x01 SHL --- 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe ``` 8. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0xff SHL --- 0x8000000000000000000000000000000000000000000000000000000000000000 ``` 9. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x0100 SHL --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 10. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000000 PUSH 0x01 SHL --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 11. ``` PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x01 SHL --- 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe ``` ### `SHR` (logical shift right) 1. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x00 SHR --- 0x0000000000000000000000000000000000000000000000000000000000000001 ``` 2. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x01 SHR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 3. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0x01 SHR --- 0x4000000000000000000000000000000000000000000000000000000000000000 ``` 4. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0xff SHR --- 0x0000000000000000000000000000000000000000000000000000000000000001 ``` 5. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0x0100 SHR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 6. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0x0101 SHR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 7. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x00 SHR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 8. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x01 SHR --- 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 9. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0xff SHR --- 0x0000000000000000000000000000000000000000000000000000000000000001 ``` 10. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x0100 SHR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 11. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000000 PUSH 0x01 SHR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` ### `SAR` (arithmetic shift right) 1. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x00 SAR --- 0x0000000000000000000000000000000000000000000000000000000000000001 ``` 2. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x01 SAR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 3. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0x01 SAR --- 0xc000000000000000000000000000000000000000000000000000000000000000 ``` 4. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0xff SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 5. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0x0100 SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 6. ``` PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0x0101 SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 7. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x00 SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 8. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x01 SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 9. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0xff SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 10. ``` PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x0100 SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 11. ``` PUSH 0x0000000000000000000000000000000000000000000000000000000000000000 PUSH 0x01 SAR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 12. ``` PUSH 0x4000000000000000000000000000000000000000000000000000000000000000 PUSH 0xfe SAR --- 0x0000000000000000000000000000000000000000000000000000000000000001 ``` 13. ``` PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0xf8 SAR --- 0x000000000000000000000000000000000000000000000000000000000000007f ``` 14. ``` PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0xfe SAR --- 0x0000000000000000000000000000000000000000000000000000000000000001 ``` 15. ``` PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0xff SAR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` 16. ``` PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x0100 SAR --- 0x0000000000000000000000000000000000000000000000000000000000000000 ``` ### Implementation Client support: - cpp-ethereum: https://github.com/ethereum/cpp-ethereum/pull/4054 Compiler support: - Solidity/LLL: https://github.com/ethereum/solidity/pull/2541 ### Tests Sources: - https://github.com/ethereum/tests/tree/develop/src/GeneralStateTestsFiller/stShift Filled Tests: - https://github.com/ethereum/tests/tree/develop/GeneralStateTests/stShift - https://github.com/ethereum/tests/tree/develop/BlockchainTests/GeneralStateTests/stShift ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 13 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-145 https://eips.ethereum.org/EIPS/eip-145 Gas cost changes for IO-heavy operations Standards Track/Core ### Meta reference [Tangerine Whistle](/EIPS/eip-608). ### Parameters | FORK_BLKNUM | CHAIN_ID | CHAIN_NAME | |-----------------|------------|-------------| | 2,463,000 | 1 | Main net | ### Specification If `block.number >= FORK_BLKNUM`, then: - Increase the gas cost of EXTCODESIZE to 700 (from 20). - Increase the base gas cost of EXTCODECOPY to 700 (from 20). - Increase the gas cost of BALANCE to 400 (from 20). - Increase the gas cost of SLOAD to 200 (from 50). - Increase the gas cost of CALL, DELEGATECALL, CALLCODE to 700 (from 40). - Increase the gas cost of SELFDESTRUCT to 5000 (from 0). - If SELFDESTRUCT hits a newly created account, it triggers an additional gas cost of 25000 (similar to CALLs). - Increase the recommended gas limit target to 5.5 million. - Define "all but one 64th" of `N` as `N - floor(N / 64)`. - If a call asks for more gas than the maximum allowed amount (i.e. the total amount of gas remaining in the parent after subtracting the gas cost of the call and memory expansion), do not return an OOG error; instead, if a call asks for more gas than all but one 64th of the maximum allowed amount, call with all but one 64th of the maximum allowed amount of gas (this is equivalent to a version of EIP-90<sup>[1](https://github.com/ethereum/EIPs/issues/90)</sup> plus EIP-114<sup>[2](https://github.com/ethereum/EIPs/issues/114)</sup>). CREATE only provides all but one 64th of the parent gas to the child call. That is, substitute: ``` extra_gas = (not ext.account_exists(to)) * opcodes.GCALLNEWACCOUNT + \ (value > 0) * opcodes.GCALLVALUETRANSFER if compustate.gas < gas + extra_gas: return vm_exception('OUT OF GAS', needed=gas+extra_gas) submsg_gas = gas + opcodes.GSTIPEND * (value > 0) ``` With: ``` def max_call_gas(gas): return gas - (gas // 64) extra_gas = (not ext.account_exists(to)) * opcodes.GCALLNEWACCOUNT + \ (value > 0) * opcodes.GCALLVALUETRANSFER if compustate.gas < extra_gas: return vm_exception('OUT OF GAS', needed=extra_gas) if compustate.gas < gas + extra_gas: gas = min(gas, max_call_gas(compustate.gas - extra_gas)) submsg_gas = gas + opcodes.GSTIPEND * (value > 0) ``` ### Rationale Recent denial-of-service attacks have shown that opcodes that read the state tree are under-priced relative to other opcodes. There are software changes that have been made, are being made and can be made in order to mitigate the situation; however, the fact will remain that such opcodes will be by a substantial margin the easiest known mechanism to degrade network performance via transaction spam. The concern arises because it takes a long time to read from disk, and is additionally a risk to future sharding proposals as the "attack transactions" that have so far been most successful in degrading network performance would also require tens of megabytes to provide Merkle proofs for. This EIP increases the cost of storage reading opcodes to address this concern. The costs have been derived from an updated version of the calculation table used to generate the 1.0 gas costs: https://docs.google.com/spreadsheets/d/15wghZr-Z6sRSMdmRmhls9dVXTOpxKy8Y64oy9MvDZEQ/edit#gid=0; the rules attempt to target a limit of 8 MB of data that needs to be read in order to process a block, and include an estimate of 500 bytes for a Merkle proof for SLOAD and 1000 for an account. This EIP aims to be simple, and adds a flat penalty of 300 gas on top of the costs calculated in this table to account for the cost of loading the code (~17–21 kb in the worst case). The EIP 90 gas mechanic is introduced because without it, all current contracts that make calls would stop working as they use an expression like `msg.gas - 40` to determine how much gas to make a call with, relying on the gas cost of calls being 40. Additionally, EIP 114 is introduced because, given that we are making the cost of a call higher and less predictable, we have an opportunity to do it at no extra cost to currently available guarantees, and so we also achieve the benefit of replacing the call stack depth limit with a "softer" gas-based restriction, thereby eliminating call stack depth attacks as a class of attack that contract developers have to worry about and hence increasing contract programming safety. Note that with the given parameters, the de-facto maximum call stack depth is limited to ~340 (down from ~1024), mitigating the harm caused by any further potential quadratic-complexity DoS attacks that rely on calls. The gas limit increase is recommended so as to preserve the de-facto transactions-per-second processing capability of the system for average contracts. ## References 1. EIP-90, https://github.com/ethereum/EIPs/issues/90 2. EIP-114, https://github.com/ethereum/EIPs/issues/114 Sat, 24 Sep 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-150 https://eips.ethereum.org/EIPS/eip-150 Add BLAKE2 compression function `F` precompile Standards Track/Core https://github.com/ethereum/EIPs/issues/152 ## Simple Summary This EIP will enable the BLAKE2b hash function and other higher-round 64-bit BLAKE2 variants to run cheaply on the EVM, allowing easier interoperability between Ethereum and Zcash as well as other Equihash-based PoW coins. ## Abstract This EIP introduces a new precompiled contract which implements the compression function `F` used in the BLAKE2 cryptographic hashing algorithm, for the purpose of allowing interoperability between the EVM and Zcash, as well as introducing more flexible cryptographic hash primitives to the EVM. ## Motivation Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2 allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. A single verification of an Equihash PoW verification requires 512 iterations of the hash function, making verification of Zcash block headers prohibitively expensive if a Solidity implementation of BLAKE2 is used. BLAKE2b, the common 64-bit BLAKE2 variant, is highly optimized and faster than MD5 on modern processors. Interoperability with Zcash could enable contracts like trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. ## Specification We propose adding a precompiled contract at address `0x09` wrapping the [BLAKE2 `F` compression function](https://tools.ietf.org/html/rfc7693#section-3.2). The precompile requires 6 inputs tightly encoded, taking exactly 213 bytes, as explained below. The encoded inputs are corresponding to the ones specified in the [BLAKE2 RFC Section 3.2](https://tools.ietf.org/html/rfc7693#section-3.2): - `rounds` - the number of rounds - 32-bit unsigned big-endian word - `h` - the state vector - 8 unsigned 64-bit little-endian words - `m` - the message block vector - 16 unsigned 64-bit little-endian words - `t_0, t_1` - offset counters - 2 unsigned 64-bit little-endian words - `f` - the final block indicator flag - 8-bit word ``` [4 bytes for rounds][64 bytes for h][128 bytes for m][8 bytes for t_0][8 bytes for t_1][1 byte for f] ``` The boolean `f` parameter is considered as `true` if set to `1`. The boolean `f` parameter is considered as `false` if set to `0`. All other values yield an invalid encoding of `f` error. The precompile should compute the `F` function as [specified in the RFC](https://tools.ietf.org/html/rfc7693#section-3.2) and return the updated state vector `h` with unchanged encoding (little-endian). ### Example Usage in Solidity The precompile can be wrapped easily in Solidity to provide a more development-friendly interface to `F`. ```solidity function F(uint32 rounds, bytes32[2] memory h, bytes32[4] memory m, bytes8[2] memory t, bool f) public view returns (bytes32[2] memory) { bytes32[2] memory output; bytes memory args = abi.encodePacked(rounds, h[0], h[1], m[0], m[1], m[2], m[3], t[0], t[1], f); assembly { if iszero(staticcall(not(0), 0x09, add(args, 32), 0xd5, output, 0x40)) { revert(0, 0) } } return output; } function callF() public view returns (bytes32[2] memory) { uint32 rounds = 12; bytes32[2] memory h; h[0] = hex"48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5"; h[1] = hex"d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b"; bytes32[4] memory m; m[0] = hex"6162630000000000000000000000000000000000000000000000000000000000"; m[1] = hex"0000000000000000000000000000000000000000000000000000000000000000"; m[2] = hex"0000000000000000000000000000000000000000000000000000000000000000"; m[3] = hex"0000000000000000000000000000000000000000000000000000000000000000"; bytes8[2] memory t; t[0] = hex"0300000000000000"; t[1] = hex"0000000000000000"; bool f = true; // Expected output: // ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d1 // 7d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923 return F(rounds, h, m, t, f); } ``` ### Gas costs and benchmarks Each operation will cost `GFROUND * rounds` gas, where `GFROUND = 1`. Detailed benchmarks are presented in the benchmarks appendix section. ## Rationale BLAKE2 is an excellent candidate for precompilation. BLAKE2 is heavily optimized for modern 64-bit CPUs, specifically utilizing 24 and 63-bit rotations to allow parallelism through SIMD instructions and little-endian arithmetic. These characteristics provide exceptional speed on native CPUs: 3.08 cycles per byte, or 1 gibibyte per second on an Intel i5. In contrast, the big-endian 32 byte semantics of the EVM are not conducive to efficient implementation of BLAKE2, and thus the gas cost associated with computing the hash on the EVM is disproportionate to the true cost of computing the function natively. An obvious implementation would be a direct BLAKE2b hash function precompile. At first glance, a BLAKE2b precompile satisfies most hashing and interoperability requirements on the EVM. Once we started digging in, however, it became clear that any BLAKE2b implementation would need specific features and internal modifications based on different projects' requirements and libraries. A [thread with the Zcash team](https://github.com/ethereum/EIPs/issues/152#issuecomment-499240310) makes the issue clear. > The minimal thing that is necessary for a working ZEC-ETH relay is an implementation of BLAKE2b Compression F in a precompile. > A BLAKE2b Compression Function F precompile would also suffice for the Filecoin and Handshake interop goals. > A full BLAKE2b precompile would suffice for a ZEC-ETH relay, provided that the implementation provided the parts of the BLAKE2 API that we need (personalization, maybe something else—I'm not sure). > I'm not 100% certain if a full BLAKE2b precompile would also suffice for the Filecoin and Handshake goals. It almost certainly could, provided that it supports all the API that they need. > BLAKE2s — whether the Compression Function F or the full hash — is only a nice-to-have for the purposes of a ZEC-ETH relay. From this and other conversations with teams in the space, we believe we should focus first on the `F` precompile as a strictly necessary piece for interoperability projects. A BLAKE2b precompile is a nice-to-have, and we support any efforts to add one-- but it's unclear whether complete requirements and a flexible API can be found in time for Istanbul. Implementation of only the core F compression function also allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. This will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the EVM. ## Backwards Compatibility There is very little risk of breaking backwards-compatibility with this EIP, the sole issue being if someone were to build a contract relying on the address at `0x09` being empty. The likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value with negligible risk of collision. ## Test Cases #### Test vector 0 * input: (empty) * output: error "input length for BLAKE2 F precompile should be exactly 213 bytes" #### Test vector 1 * input: `00000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001` * output: error "input length for BLAKE2 F precompile should be exactly 213 bytes" #### Test vector 2 * input: `000000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001` * output: error "input length for BLAKE2 F precompile should be exactly 213 bytes" #### Test vector 3 * input: `0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000002` * output: error "incorrect final block indicator flag" #### Test vector 4 * input: `0000000048c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001` * output: `08c9bcf367e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d282e6ad7f520e511f6c3e2b8c68059b9442be0454267ce079217e1319cde05b` #### Test vector 5 * input: `0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001` * output: `ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d17d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923` #### Test vector 6 * input: `0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000` * output: `75ab69d3190a562c51aef8d88f1c2775876944407270c42c9844252c26d2875298743e7f6d5ea2f2d3e8d226039cd31b4e426ac4f2d3d666a610c2116fde4735` #### Test vector 7 * input: `0000000148c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001` * output: `b63a380cb2897d521994a85234ee2c181b5f844d2c624c002677e9703449d2fba551b3a8333bcdf5f2f7e08993d53923de3d64fcc68c034e717b9293fed7a421` #### Test vector 8 * input: `ffffffff48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001` * output: `fc59093aafa9ab43daae0e914c57635c5402d8e3d2130eb9b3cc181de7f0ecf9b22bf99a7815ce16419e200e01846e6b5df8cc7703041bbceb571de6631d2615` ## Implementation An initial implementation of the `F` function in Go, adapted from the standard library, can be found in our [Golang BLAKE2 library fork](https://github.com/keep-network/blake2-f). There's also an implementation of the precompile in our fork of [go-ethereum](https://github.com/keep-network/go-ethereum/pull/4). ## References For reference, further discussion on this EIP also occurred in the following PRs and issues * [Original Issue](https://github.com/ethereum/EIPs/issues/152) * [Ethereum Magicians](https://ethereum-magicians.org/t/blake2b-f-precompile/3157) * [PR 2129](https://github.com/ethereum/EIPs/pull/2129) ## Appendix - benchmarks Assuming ecRecover precompile is perfectly priced, we executed a set of benchmarks comparing Blake2b F compression function precompile with ecRecover precompile. For benchmarks, we used 3.1 GHz Intel Core i7 64-bit machine. ```sh $ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz ``` ### 12 rounds An average gas price of F precompile call with 12 rounds compared to ecRecover should have been `6.74153` and it gives `0.5618` gas per round. ``` Name Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq ----------------------------------------- --------- ---------------- --------- ----------------------- ----------------------- PrecompiledEcrecover/ 3000 152636 19.6546 1526.36 3000 PrecompiledBlake2F/testVectors2bX_0 12 338 35.503 3.38 6.64326 PrecompiledBlake2F/testVectors2bX_3 12 336 35.7143 3.36 6.60395 PrecompiledBlake2F/testVectors2bX_70 12 362 33.1492 3.62 7.11497 PrecompiledBlake2F/testVectors2bX_140 12 339 35.3982 3.39 6.66291 PrecompiledBlake2F/testVectors2bX_230 12 339 35.3982 3.39 6.66291 PrecompiledBlake2F/testVectors2bX_300 12 343 34.9854 3.43 6.74153 PrecompiledBlake2F/testVectors2bX_370 12 336 35.7143 3.36 6.60395 PrecompiledBlake2F/testVectors2bX_440 12 337 35.6083 3.37 6.6236 PrecompiledBlake2F/testVectors2bX_510 12 345 34.7826 3.45 6.78084 PrecompiledBlake2F/testVectors2bX_580 12 355 33.8028 3.55 6.97738 ``` Columns * `MGas/S` - Shows what MGas per second was measured on that machine at that time * `Gasprice for 10MGas/S` shows what the gasprice should have been, in order to reach 10 MGas/second * `Gasprice for ECDSA eq` shows what the gasprice should have been, in order to have the same cost/cycle as ecRecover ### 1200 rounds An average gas price of F precompile call with 1200 rounds compared to ecRecover should have been `436.1288` and it gives `0.3634` gas per round. ``` Name Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq ----------------------------------------- --------- ---------------- --------- ----------------------- ----------------------- PrecompiledEcrecover/ 3000 156152 19.212 1561.52 3000 PrecompiledBlake2F/testVectors2bX_0 1200 22642 52.9989 226.42 434.999 PrecompiledBlake2F/testVectors2bX_3 1200 22885 52.4361 228.85 439.668 PrecompiledBlake2F/testVectors2bX_70 1200 22737 52.7774 227.37 436.824 PrecompiledBlake2F/testVectors2bX_140 1200 22602 53.0926 226.02 434.231 PrecompiledBlake2F/testVectors2bX_230 1200 22501 53.331 225.01 432.29 PrecompiledBlake2F/testVectors2bX_300 1200 22435 53.4879 224.35 431.022 PrecompiledBlake2F/testVectors2bX_370 1200 22901 52.3995 229.01 439.975 PrecompiledBlake2F/testVectors2bX_440 1200 23134 51.8717 231.34 444.452 PrecompiledBlake2F/testVectors2bX_510 1200 22608 53.0786 226.08 434.346 PrecompiledBlake2F/testVectors2bX_580 1200 22563 53.1844 225.63 433.481 ``` ### 1 round An average gas price of F precompile call with 1 round compared to ecRecover should have been `2.431701`. However, in this scenario the call cost would totally overshadow the dynamic cost anyway. ``` Name Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq ----------------------------------------- --------- ---------------- ---------- ----------------------- ----------------------- PrecompiledEcrecover/ 3000 157544 19.0423 1575.44 3000 PrecompiledBlake2F/testVectors2bX_0 1 126 7.93651 1.26 2.39933 PrecompiledBlake2F/testVectors2bX_3 1 127 7.87402 1.27 2.41837 PrecompiledBlake2F/testVectors2bX_70 1 128 7.8125 1.28 2.43741 PrecompiledBlake2F/testVectors2bX_140 1 125 8 1.25 2.38029 PrecompiledBlake2F/testVectors2bX_230 1 128 7.8125 1.28 2.43741 PrecompiledBlake2F/testVectors2bX_300 1 127 7.87402 1.27 2.41837 PrecompiledBlake2F/testVectors2bX_370 1 131 7.63359 1.31 2.49454 PrecompiledBlake2F/testVectors2bX_440 1 129 7.75194 1.29 2.45646 PrecompiledBlake2F/testVectors2bX_510 1 125 8 1.25 2.38029 PrecompiledBlake2F/testVectors2bX_580 1 131 7.63359 1.31 2.49454 ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 04 Oct 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-152 https://eips.ethereum.org/EIPS/eip-152 Simple replay attack protection Standards Track/Core ### Hard fork [Spurious Dragon](/EIPS/eip-607) ### Parameters - `FORK_BLKNUM`: 2,675,000 - `CHAIN_ID`: 1 (main net) ### Specification If `block.number >= FORK_BLKNUM` and `CHAIN_ID` is available, then when computing the hash of a transaction for the purposes of signing, instead of hashing only six rlp encoded elements `(nonce, gasprice, startgas, to, value, data)`, you **SHOULD** hash nine rlp encoded elements `(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)`. If you do, then the `v` of the signature **MUST** be set to `{0,1} + CHAIN_ID * 2 + 35` where `{0,1}` is the parity of the `y` value of the curve point for which `r` is the x-value in the secp256k1 signing process. If you choose to only hash 6 values, then `v` continues to be set to `{0,1} + 27` as previously. If `block.number >= FORK_BLKNUM` and `v = CHAIN_ID * 2 + 35` or `v = CHAIN_ID * 2 + 36`, then when computing the hash of a transaction for purposes of recovering, instead of hashing six rlp encoded elements `(nonce, gasprice, startgas, to, value, data)`, hash nine rlp encoded elements `(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)`. The currently existing signature scheme using `v = 27` and `v = 28` remains valid and continues to operate under the same rules as it did previously. ### Example Consider a transaction with `nonce = 9`, `gasprice = 20 * 10**9`, `startgas = 21000`, `to = 0x3535353535353535353535353535353535353535`, `value = 10**18`, `data=''` (empty). The "signing data" becomes: ``` 0xec098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a764000080018080 ``` The "signing hash" becomes: ``` 0xdaf5a779ae972f972197303d7b574746c7ef83eadac0f2791ad23db92e4c8e53 ``` If the transaction is signed with the private key `0x4646464646464646464646464646464646464646464646464646464646464646`, then the v,r,s values become: ``` (37, 18515461264373351373200002665853028612451056578545711640558177340181847433846, 46948507304638947509940763649030358759909902576025900602547168820602576006531) ``` Notice the use of 37 instead of 27. The signed tx would become: ``` 0xf86c098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a76400008025a028ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276a067cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83 ``` ### Rationale This would provide a way to send transactions that work on Ethereum without working on ETC or the Morden testnet. ETC is encouraged to adopt this EIP but replacing `CHAIN_ID` with a different value, and all future testnets, consortium chains and alt-etherea are encouraged to adopt this EIP replacing `CHAIN_ID` with a unique value. ### List of Chain ID's: | `CHAIN_ID` | Chain(s) | | ---------------| -------------------------------------------| | 1 | Ethereum mainnet | | 2 | Morden (disused), Expanse mainnet | | 3 | Ropsten | | 4 | Rinkeby | | 5 | Goerli | | 42 | Kovan | | 1337 | Geth private chains (default) | Find more chain ID's on [chainid.network](https://chainid.network) and contribute to [ethereum-lists/chains](https://github.com/ethereum-lists/chains). Fri, 14 Oct 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-155 https://eips.ethereum.org/EIPS/eip-155 State clearing Standards Track/Core # Specification For all blocks where `block.number >= FORK_BLKNUM` (TBA): 1. In all cases where a state change is made to an account, and this state change results in the account state being saved with nonce = 0, balance = 0, code empty, storage empty (hereinafter "empty account"), the account is instead deleted. 2. If an address is "touched" and that address contains an empty account, then it is deleted. A "touch" is defined as any situation where if the account at the given address were nonexistent it would be created. 3. Whenever the EVM checks if an account exists, emptiness is treated as equivalent to nonexistence. Particularly, note that this implies that, once this change is enabled, there is no longer a meaningful difference between emptiness and nonexistence from the point of view of EVM execution. 4. Zero-value calls and zero-value suicides no longer consume the 25000 account creation gas cost in any circumstance The cases where a "touch" takes place can be enumerated as follows: - Zero-value-bearing CALLs - CREATEs (if the code that is ultimately saved is empty and there is no ether remaining in the account when it is saved) - Zero-value-bearing SUICIDEs - Transaction recipients - Contracts created in contract creation transactions - Miners receiving transaction fees (note the case where the gasprice is zero, and the account does not yet exist because it only receives the block/uncle/nephew rewards _after_ processing every transaction) ### Specification (1b) When the EVM checks for emptiness (for the purpose of possibly applying the 25000 gas cost), emptiness is defined by `is_empty(acct): return get_balance(acct) == 0 and get_code(acct) == "" and get_nonce(acct) == 0`; emptiness of storage does not matter. This simplifies client implementation because there is no need to add extra complexity to make caches enumerable in the correct way and does not significantly affect the intended result, as the cases where balance/code/nonce are empty but storage is nonempty where this change would lead to an extra 25000 gas being paid are pathological and have no real use value. ### Specification (1c) Do not implement point 2 above (ie. no new empty accounts can be created, but existing ones are not automatically destroyed unless their state is actually _changed_). Instead, during each block starting from (and including) N and ending when there are no null accounts left, select the 1000 null accounts that are left-most in order of sha3(address), and delete them (ordering by hash is necessary so as to allow the accounts to be easily found by iterating the tree). # Rationale This removes a large number of empty accounts that have been put in the state at very low cost due to flaws in earlier versions of the Ethereum protocol, thereby greatly reducing state size and hence both reducing the hard disk load of a full client and reducing the time for a fast sync. Additionally, it simplifies the protocol in the long term, as once all "empty" objects are cleared out there is no longer any meaningful distinction between an account being empty and being nonexistent, and indeed one can simply view nonexistence as a compact representation of emptiness. Note that this proposal does introduce a **temporary** breaking of existing guarantees, in that by repeatedly zero-value-calling already existing empty accounts one can create a state change at a cost of 700 gas per account instead of the usual 5000 per gas minimum (with SUICIDE refunds this goes down further to 350 gas per account). Allowing such a large number of state writes per block will lead to heightened block processing times and increase uncle rates in the short term while the existing empty accounts are being cleared, and eventually once all empty accounts are cleared this issue will no longer exist. # References 1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158 2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161 Sun, 16 Oct 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-158 https://eips.ethereum.org/EIPS/eip-158 EXP cost increase Standards Track/Core ### Hard fork [Spurious Dragon](/EIPS/eip-607) ### Parameters - `FORK_BLKNUM`: 2,675,000 - `CHAIN_ID`: 1 ### Specification If `block.number >= FORK_BLKNUM`, increase the gas cost of EXP from 10 + 10 per byte in the exponent to 10 + 50 per byte in the exponent. ### Rationale Benchmarks suggest that EXP is currently underpriced by a factor of about 4–8. ### References 1. EIP-160 issue and discussion: https://github.com/ethereum/EIPs/issues/160 Thu, 20 Oct 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-160 https://eips.ethereum.org/EIPS/eip-160 State trie clearing (invariant-preserving alternative) Standards Track/Core ### Hard fork [Spurious Dragon](/EIPS/eip-607) ### Parameters - `FORK_BLKNUM`: 2,675,000 - `CHAIN_ID`: 1 (Mainnet) ### Specification a. Account creation transactions and the `CREATE` operation SHALL, prior to the execution of the initialisation code, **increment** the **nonce** over and above its normal starting value by **one** (for normal networks, this will be simply 1, however test-nets with non-zero default starting nonces will be different). b. Whereas `CALL` and `SUICIDE` would charge 25,000 gas when the destination is non-existent, now the charge SHALL **only** be levied if the operation transfers **more than zero value** and the destination account is _dead_. c. No account may _change state_ from non-existent to existent-but-_empty_. If an operation would do this, the account SHALL instead remain non-existent. d. _At the end of the transaction_, any account _touched_ by the execution of that transaction which is now _empty_ SHALL instead become non-existent (i.e. **deleted**). Where: An account is considered to be _touched_ when it is involved in any potentially _state-changing_ operation. This includes, but is not limited to, being the recipient of a **transfer of zero value**. An account is considered _empty_ when it has **no code** and **zero nonce** and **zero balance**. An account is considered _dead_ when either it is non-existent or it is _empty_. _At the end of the transaction_ is immediately following the execution of the suicide list, prior to the determination of the state trie root for receipt population. An account _changes state_ when: - it is the target or refund of a `SUICIDE` operation for **zero or more** value; - it is the source or destination of a `CALL` operation or message-call transaction transferring **zero or more** value; - it is the source or creation of a `CREATE` operation or contract-creation transaction endowing **zero or more** value; - as the block author ("miner") it is the recipient of block-rewards or transaction-fees of **zero or more** value. #### Notes In the present Ethereum protocol, it should be noted that very few state changes can ultimately result in accounts that are empty following the execution of the transaction. In fact there are only four contexts that current implementations need track: - an empty account has zero value transferred to it through `CALL`; - an empty account has zero value transferred to it through `SUICIDE`; - an empty account has zero value transferred to it through a message-call transaction; - an empty account has zero value transferred to it through a zero-gas-price fees transfer. ### Rationale Same as #158 except that several edge cases are avoided since we do not break invariants: - ~~that an account can go from having code and storage to not having code or storage mid-way through the execution of a transaction;~~ [corrected] - that a newly created account cannot be deleted prior to being deployed. `CREATE` avoids zero in the nonce to avoid any suggestion of the oddity of `CREATE`d accounts being reaped half-way through their creation. ### Addendum (2017-08-15) On 2016-11-24, a consensus bug occurred due to two implementations having different behavior in the case of state reverts.[3] The specification was amended to clarify that empty account deletions are reverted when the state is reverted. ### References 1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158 2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161 3. https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/ > Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes. Mon, 24 Oct 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-161 https://eips.ethereum.org/EIPS/eip-161 Initial ENS Hash Registrar Standards Track/ERC ## Contents - Abstract - Motivations - Specification - Initial restrictions - Name format for hash registration - Auctioning names - Deeds - Deployment and Upgrade process - Registrar Interface - Rationale - Not committing to a permanent registrar at the outset - Valid names >= 7 characters - Restricting TLD to `.eth` - Holding ether as collateral - Prior work <!-- /MarkdownTOC --> ## Abstract This ERC describes the implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the Ethereum Name Service (ENS). The corresponding source code is [here](https://github.com/ethereum/ens/blob/mainnet/contracts/HashRegistrarSimplified.sol). For more background, refer to [EIP-137](/EIPS/eip-137). > Registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts. > > \- EIP 137 A well designed and governed registrar is essential to the success of the ENS described in EIP 137, but is described separately in this document as it is external to the core ENS protocol. In order to maximize utility and adoption of a new namespace, the registrar should mitigate speculation and "name squatting", however the best approach for mitigation is unclear. Thus an "initial" registrar is proposed, which implements a simple approach to name allocation. During the initial period, the available namespace will be significantly restricted to the `.eth` top level domain, and subdomain shorter than 7 characters in length disallowed. This specification largely describes @alexvandesande and @arachnid's [hash registrar implementation](https://github.com/ethereum/ens/blob/mainnet/contracts/HashRegistrarSimplified.sol) in order to facilitate discussion. The intent is to replace the Initial Registrar contract with a permanent registrar contract. The Permanent Registrar will increase the available namespace, and incorporate lessons learned from the performance of the Initial Registrar. This upgrade is expected to take place within approximately 2 years of initial deployment. ## Motivations The following factors should be considered in order to optimize for adoption of the ENS, and good governance of the Initial Registrar's namespace. **Upgradability:** The Initial Registrar should be safely upgradeable, so that knowledge gained during its deployment can be used to replace it with an improved and permanent registrar. **Effective allocation:** Newly released namespaces often create a land grab situation, resulting in many potentially valuable names being purchased but unused, with the hope of re-selling at a profit. This reduces the availability of the most useful names, in turn decreasing the utility of the name service to end users. Achieving an effective allocation may or may not require human intervention for dispute resolution and other forms of curation. The Initial Registrar should not aim to create to most effective possible allocation, but instead limit the cost of misallocation in the long term. **Security:** The registrar will hold a balance of ether without an explicit limit. It must be designed securely. **Simplicity:** The ENS specification itself emphasizes a separation of concerns, allowing the most essential element, the registry to be as simple as possible. The interim registrar in turn should be as simple as possible while still meeting its other design goals. **Adoption:** Successful standards become more successful due to network effects. The registrar should consider what strategies will encourage the adoption of the ENS in general, and the namespace it controls in particular. ## Specification ### Initial restrictions The Initial Registrar is expected to be in service for approximately two years, prior to upgrading. This should be sufficient time to learn, observe, and design an updated system. During the initial two year period, the available name space will be restricted to the `.eth` TLD. This restriction is enforced by the owner of the ENS root node who should not assign any nodes other than `.eth` to the Initial Registrar. The ENS's root node should be controlled by multiple parties using a multisig contract. The Initial Registrar will also prohibit registration of names 6 characters or less in length. ### Name format for hash registration Names submitted to the initial registrar must be hashed using Ethereum's sha3 function. Note that the hashes submitted to the registrar are the hash of the subdomain label being registered, not the namehash as defined in EIP 137. For example, in order to register `abcdefg.eth`, one should submit `sha3('abcdefg')`, not `sha3(sha3(0, 'eth'), 'abcdefg')`. ### Auctioning names The registrar will allocate the available names through a Vickrey auction: > A Vickrey auction is a type of sealed-bid auction. Bidders submit written bids without knowing the bid of the other people in the auction. The highest bidder wins but the price paid is the second-highest bid. This type of auction... gives bidders an incentive to bid their true value. > > \- [Vickrey Auction, Wikipedia](https://en.wikipedia.org/wiki/Vickrey_auction) The auction lifecycle of a name has 5 possible states, or Modes. 1. **Not-yet-available:** The majority of names will be initially unavailable for auction, and will become available some time during the 8 weeks after launch. 2. **Open:** The earliest availability for a name is determined by the most significant byte of its sha3 hash. `0x00` would become available immediately, `0xFF` would become available after 8 weeks, and the availability of other names is distributed accordingly. Once a name is available, it is possible to start an auction on it. 3. **Auction:** Once the auction for a name has begun, there is a 72 hour bidding period. Bidders must submit a payment of ether, along with sealed bids as a hash of `sha3(bytes32 hash, address owner, uint value, bytes32 salt)`. The bidder may obfuscate the true bid value by sending a greater amount of ether. 4. **Reveal:** After the bidding period, a 48 hour reveal period commences. During this time, bidders must reveal the true parameters of their sealed bid. As bids are revealed, ether payments are returned according to the schedule of "refund ratios" outlined in the table below. If no bids are revealed, the name will return to the Open state. 5. **Owned:** After the reveal period has finished, the winning bidder must submit a transaction to finalize the auction, which then calls the ENS's `setSubnodeOwner` function, recording the winning bidder's address as the owner of the hash of the name. The following table outlines important parameters which define the Registrar's auction mechanism. #### Registrar Parameters | Name | Description | Value | |--------------------|----------------------------------------------------------------------------------------------------|------------| | totalAuctionLength | The full time period from start of auction to end of the reveal period. | 5 days | | revealPeriod | The length of the time period during which bidding is no longer allowed, and bids must be revealed. | 48 hours | | launchLength | The time period during which all names will become available for auction. | 8 weeks | | minPrice | The minimum amount of ether which must be locked up in exchange for ownership of a name. | 0.01 ether | ### Deeds The Initial Registrar contract does not hold a balance itself. All ether sent to the Registrar will be held in a separate `Deed` contracts. A deed contract is first created and funded when a sealed bid is submitted. After an auction is completed and a hash is registered, the deed for the winning bid is held in exchange for ownership of the hash. Non-winning bids are refunded. A deed for an owned name may be transferred to another account by its owner, thus transferring ownership and control of the name. After 1 year of registration, the owner of a hash may choose to relinquish ownership and have the value of the deed returned to them. Deeds for non-winning bids can be closed by various methods, at which time any ether held will either be returned to the bidder, burnt, or sent to someone else as a reward for actions which help the registrar. The following table outlines what portion of the balance held in a deed contract will be returned upon closure, and to whom. The remaining balance will be burnt. #### Refund schedule | Reason for Deed closure | Refund Recipient | Refund Percentage | | --- | --- | --- | | A valid non-winning bid is revealed. | Bidder | 99.5% | | A bid submitted after the auction period is revealed. | Bidder | 99.5% | | An otherwise valid bid is revealed on an owned name. <sup>1</sup> | Bidder | 0.5% | | An expired sealed bid is cancelled. <sup>2</sup> | Canceler | 0.5% | | A registered hash is reported as invalid. <sup>3</sup> | Reporter | 50% | | A registered hash is reported as invalid. <sup>3</sup> | Owner | 50% | ##### Notes: 1. This incentivizes all bids to be revealed in time. If bids could be revealed late, an extortion attack on the current highest bidder could be made by threatening to reveal a new second highest bid. 2. A bid which remains sealed after more than 2 weeks and 5 days may be cancelled by anyone to collect a small reward. 2. Since names are hashed before auctioning and registration, the Initial Registrar is unable to enforce character length restrictions independently. A reward is therefore provided for reporting invalid names. ### Deployment and Upgrade process The Initial Registrar requires the ENS's address as a constructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar's address as owner of the `eth` node. The Initial Registrar is expected to be replaced by a Permanent Registrar approximately 2 years after deployment. The following process should be used for the upgrade: 1. The Permanent Registrar contract will be deployed. 2. The multisig account owning the root node in the ENS will assign ownership of the `.eth` node to the Permanent Registrar. 3. Owners of hashes in the Initial Registrar will be responsible for registering their deeds to the Permanent Registrar. A couple options are considered here: 1. Require owners to transfer their ownership prior to a cutoff date in order to maintain ownership and/or continue name resolution services. 2. Have the Permanent Registrar query the Initial Registrar for ownership if it is lacking an entry. ### Planned deactivation In order to limit dependence on the Initial Registrar, new auctions will stop after 4 years, and all ether held in deeds after 8 years will become unreachable. ### Registrar Interface `function state(bytes32 _hash) constant returns (Mode)` - Implements a state machine returning the current state of a name `function entries(bytes32 _hash) constant returns (Mode, address, uint, uint, uint)` - Returns the following information regarding a registered name: * state * deed address * registration date * balance of the deed * highest value bid at auction `function getAllowedTime(bytes32 _hash) constant returns (uint timestamp)` - Returns the time at which the hash will no longer be in the initial `not-yet-available` state. `function isAllowed(bytes32 _hash, uint _timestamp) constant returns (bool allowed)` - Takes a hash and a time, returns true if and only if it has passed the initial `not-yet-available` state. `function startAuction(bytes32 _hash);` - Moves the state of a hash from Open to Auction. Throws if state is not Open. `function startAuctions(bytes32[] _hashes);` - Starts multiple auctions on an array of hashes. This enables someone to open up an auction for a number of dummy hashes when they are only really interested in bidding for one. This will increase the cost for an attacker to simply bid blindly on all new auctions. Dummy auctions that are open but not bid on are closed after a week. `function shaBid(bytes32 hash, address owner, uint value, bytes32 salt) constant returns (bytes32 sealedBid);` - Takes the parameters of a bid, and returns the sealedBid hash value required to participate in the bidding for an auction. This obfuscates the parameters in order to mimic the mechanics of placing a bid in an envelope. `function newBid(bytes32 sealedBid);` - Bids are sent by sending a message to the main contract with a sealedBid hash and an amount of ether. The hash contains information about the bid, including the bidded name hash, the bid value, and a random salt. Bids are not tied to any one auction until they are revealed. The value of the bid itself can be masqueraded by sending more than the value of your actual bid. This is followed by a 48h reveal period. Bids revealed after this period will be burned and the ether unrecoverable. Since this is an auction, it is expected that most public hashes, like known domains and common dictionary words, will have multiple bidders pushing the price up. `function startAuctionsAndBid(bytes32[] hashes, bytes32 sealedBid)` - A utility function allowing a call to `startAuctions` followed by `newBid` in a single transaction. `function unsealBid(bytes32 _hash, address _owner, uint _value, bytes32 _salt);` - Once the bidding period is completed, there is a reveal period during with the properties of a bid are submitted to reveal them. The registrar hashes these properties using the `shaBid()` function above to verify that they match a pre-existing sealed bid. If the unsealedBid is the new best bid, the old best bid is returned to its bidder. `function cancelBid(bytes32 seal);` - Cancels an unrevealed bid according to the rules described in the notes on the refund schedule above. `function finalizeAuction(bytes32 _hash);` After the registration date has passed, this function can be called to finalize the auction, which then calls the ENS function `setSubnodeOwner()` updating the ENS record to set the winning bidder as owner of the node. `function transfer(bytes32 _hash, address newOwner);` - Update the owner of the ENS node corresponding to the submitted hash to a new owner. This function must be callable only by the current owner. `function releaseDeed(bytes32 _hash);` - After some time, the owner can release the property and get their ether back. `function invalidateName(string unhashedName);` - Since registration is done on the hash of a name, the registrar itself cannot validate names. This function can be used to report a name which is 6 characters long or less. If it has been registered, the submitter will earn 10% of the deed value. We are purposefully handicapping the simplified registrar as a way to force it into being restructured in a few years. `function eraseNode(bytes32[] labels)` - Allows anyone to delete the owner and resolver records for a subdomain of a name that is not currently owned in the registrar. For instance, to zero `foo.bar.eth` on a registrar that owns `.eth`, pass an array containing `[sha3('foo'), sha3('bar')]`. `function transferRegistrars(bytes32 _hash) onlyOwner(_hash);` - Used during the upgrade process to a permanent registrar. If this registrar is no longer the owner of the its root node in the ENS, this function will transfers the deed to the current owner, which should be a new registrar. This function throws if this registrar still owns its root node. ## Rationale ### Starting with a temporary registrar Anticipating and designing for all the potential issues of name allocation names is unlikely to succeed. This approach chooses not to be concerned with getting it perfect, but allows us to observe and learn with training wheels on, and implement improvements before expanding the available namespace to shorter names or another TLD. ### Valid names >= 7 characters Preserving the shortest, and often most valuable, domain names for the upgraded registrar provides the opportunity to implement processes for dispute resolution (assuming they are found to be necessary). ### Delayed release of names A slower release allows for extra time to identify, and address any issues which may arise after launch. ### Restricting TLD to `.eth` Choosing a single TLD helps to maximize network effects by focusing on one namespace. A three letter TLD is a pattern made familiar by it's common usage in internet domain names. This familiarity significantly increases the potential of the ENS to be integrated into pre-existing DNS systems, and reserved as a [special-use domain name](https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain). A recent precedent for this is the [reservation of the `.onion` domain](https://tools.ietf.org/html/rfc7686). ### Holding ether as collateral This approach is simpler than the familiar model of requiring owners to make recurring payments to retain ownership of a domain name. It also makes the initial registrar a revenue neutral service. ## Prior work This document borrows heavily from several sources: - [EIP-137](/EIPS/eip-137) outlines the initial implementation of the Registry Contract (ENS.sol) and associated Resolver contracts. - [ERC-26](https://github.com/ethereum/EIPs/issues/26) was the first ERC to propose a name service at the contract layer - @alexvandesande's current implementation of the [HashRegistrar](https://github.com/ethereum/ens/blob/mainnet/contracts/HashRegistrarSimplified.sol) ### Edits: - 2016-10-26 Added link Alex's design in abstract - 2016-11-01 change 'Planned deactivation' to h3' - 2017-03-13 Update timelines for bidding and reveal periods ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 25 Oct 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-162 https://eips.ethereum.org/EIPS/eip-162 Standard Interface Detection Standards Track/ERC ## Simple Summary Creates a standard method to publish and detect what interfaces a smart contract implements. ## Abstract Herein, we standardize the following: 1. How interfaces are identified 2. How a contract will publish the interfaces it implements 3. How to detect if a contract implements ERC-165 4. How to detect if a contract implements any given interface ## Motivation For some "standard interfaces" like [the ERC-20 token interface](/EIPS/eip-20), it is sometimes useful to query whether a contract supports the interface and if yes, which version of the interface, in order to adapt the way in which the contract is to be interacted with. Specifically for ERC-20, a version identifier has already been proposed. This proposal standardizes the concept of interfaces and standardizes the identification (naming) of interfaces. ## Specification ### How Interfaces are Identified For this standard, an *interface* is a set of [function selectors as defined by the Ethereum ABI](https://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector). This a subset of [Solidity's concept of interfaces](https://solidity.readthedocs.io/en/develop/abi-spec.html) and the `interface` keyword definition which also defines return types, mutability and events. We define the interface identifier as the XOR of all function selectors in the interface. This code example shows how to calculate an interface identifier: ```solidity pragma solidity ^0.4.20; interface Solidity101 { function hello() external pure; function world(int) external pure; } contract Selector { function calculateSelector() public pure returns (bytes4) { Solidity101 i; return i.hello.selector ^ i.world.selector; } } ``` Note: interfaces do not permit optional functions, therefore, the interface identity will not include them. ### How a Contract will Publish the Interfaces it Implements A contract that is compliant with ERC-165 shall implement the following interface (referred as `ERC165.sol`): ```solidity pragma solidity ^0.4.20; interface ERC165 { /// @notice Query if a contract implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 /// @dev Interface identification is specified in ERC-165. This function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceID` and /// `interfaceID` is not 0xffffffff, `false` otherwise function supportsInterface(bytes4 interfaceID) external view returns (bool); } ``` The interface identifier for this interface is `0x01ffc9a7`. You can calculate this by running `bytes4(keccak256('supportsInterface(bytes4)'));` or using the `Selector` contract above. Therefore the implementing contract will have a `supportsInterface` function that returns: - `true` when `interfaceID` is `0x01ffc9a7` (EIP165 interface) - `false` when `interfaceID` is `0xffffffff` - `true` for any other `interfaceID` this contract implements - `false` for any other `interfaceID` This function must return a bool and use at most 30,000 gas. Implementation note, there are several logical ways to implement this function. Please see the example implementations and the discussion on gas usage. ### How to Detect if a Contract Implements ERC-165 1. The source contract makes a `STATICCALL` to the destination address with input data: `0x01ffc9a701ffc9a700000000000000000000000000000000000000000000000000000000` and gas 30,000. This corresponds to `contract.supportsInterface(0x01ffc9a7)`. 2. If the call fails or return false, the destination contract does not implement ERC-165. 3. If the call returns true, a second call is made with input data `0x01ffc9a7ffffffff00000000000000000000000000000000000000000000000000000000`. 4. If the second call fails or returns true, the destination contract does not implement ERC-165. 5. Otherwise it implements ERC-165. ### How to Detect if a Contract Implements any Given Interface 1. If you are not sure if the contract implements ERC-165, use the above procedure to confirm. 2. If it does not implement ERC-165, then you will have to see what methods it uses the old-fashioned way. 3. If it implements ERC-165 then just call `supportsInterface(interfaceID)` to determine if it implements an interface you can use. ## Rationale We tried to keep this specification as simple as possible. This implementation is also compatible with the current Solidity version. ## Backwards Compatibility The mechanism described above (with `0xffffffff`) should work with most of the contracts previous to this standard to determine that they do not implement ERC-165. Also [the ENS](/EIPS/eip-137) already implements this EIP. ## Test Cases Following is a contract that detects which interfaces other contracts implement. From @fulldecent and @jbaylina. ```solidity pragma solidity ^0.4.20; contract ERC165Query { bytes4 constant InvalidID = 0xffffffff; bytes4 constant ERC165ID = 0x01ffc9a7; function doesContractImplementInterface(address _contract, bytes4 _interfaceId) external view returns (bool) { uint256 success; uint256 result; (success, result) = noThrowCall(_contract, ERC165ID); if ((success==0)||(result==0)) { return false; } (success, result) = noThrowCall(_contract, InvalidID); if ((success==0)||(result!=0)) { return false; } (success, result) = noThrowCall(_contract, _interfaceId); if ((success==1)&&(result==1)) { return true; } return false; } function noThrowCall(address _contract, bytes4 _interfaceId) constant internal returns (uint256 success, uint256 result) { bytes4 erc165ID = ERC165ID; assembly { let x := mload(0x40) // Find empty storage location using "free memory pointer" mstore(x, erc165ID) // Place signature at beginning of empty storage mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature success := staticcall( 30000, // 30k gas _contract, // To addr x, // Inputs are stored at location x 0x24, // Inputs are 36 bytes long x, // Store output over input (saves space) 0x20) // Outputs are 32 bytes long result := mload(x) // Load the result } } } ``` ## Implementation This approach uses a `view` function implementation of `supportsInterface`. The execution cost is 586 gas for any input. But contract initialization requires storing each interface (`SSTORE` is 20,000 gas). The `ERC165MappingImplementation` contract is generic and reusable. ```solidity pragma solidity ^0.4.20; import "./ERC165.sol"; contract ERC165MappingImplementation is ERC165 { /// @dev You must not set element 0xffffffff to true mapping(bytes4 => bool) internal supportedInterfaces; function ERC165MappingImplementation() internal { supportedInterfaces[this.supportsInterface.selector] = true; } function supportsInterface(bytes4 interfaceID) external view returns (bool) { return supportedInterfaces[interfaceID]; } } interface Simpson { function is2D() external returns (bool); function skinColor() external returns (string); } contract Lisa is ERC165MappingImplementation, Simpson { function Lisa() public { supportedInterfaces[this.is2D.selector ^ this.skinColor.selector] = true; } function is2D() external returns (bool){} function skinColor() external returns (string){} } ``` Following is a `pure` function implementation of `supportsInterface`. The worst-case execution cost is 236 gas, but increases linearly with a higher number of supported interfaces. ```solidity pragma solidity ^0.4.20; import "./ERC165.sol"; interface Simpson { function is2D() external returns (bool); function skinColor() external returns (string); } contract Homer is ERC165, Simpson { function supportsInterface(bytes4 interfaceID) external view returns (bool) { return interfaceID == this.supportsInterface.selector || // ERC165 interfaceID == this.is2D.selector ^ this.skinColor.selector; // Simpson } function is2D() external returns (bool){} function skinColor() external returns (string){} } ``` With three or more supported interfaces (including ERC165 itself as a required supported interface), the mapping approach (in every case) costs less gas than the pure approach (at worst case). ## Version history * PR 1640, finalized 2019-01-23 -- This corrects the noThrowCall test case to use 36 bytes rather than the previous 32 bytes. The previous code was an error that still silently worked in Solidity 0.4.x but which was broken by new behavior introduced in Solidity 0.5.0. This change was discussed at [#1640](https://github.com/ethereum/EIPs/pull/1640). * EIP 165, finalized 2018-04-20 -- Original published version. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 23 Jan 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-165 https://eips.ethereum.org/EIPS/eip-165 Contract code size limit Standards Track/Core ### Hard fork [Spurious Dragon](/EIPS/eip-607) ### Parameters - `MAX_CODE_SIZE`: `0x6000` (`2**14 + 2**13`) - `FORK_BLKNUM`: 2,675,000 - `CHAIN_ID`: 1 (Mainnet) ### Specification If `block.number >= FORK_BLKNUM`, then if contract creation initialization returns data with length of **more than** `MAX_CODE_SIZE` bytes, contract creation fails with an out of gas error. ### Rationale Currently, there remains one slight quadratic vulnerability in Ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern—not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits. ### References 1. EIP-170 issue and discussion: https://github.com/ethereum/EIPs/issues/170 2. pyethereum implementation: https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397 Fri, 04 Nov 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-170 https://eips.ethereum.org/EIPS/eip-170 Contract Ownership Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/173 ## Abstract This specification defines standard functions for owning or controlling a contract. An implementation allows reading the current owner (`owner() returns (address)`) and transferring ownership (`transferOwnership(address newOwner)`) along with a standardized event for when ownership is changed (`OwnershipTransferred(address indexed previousOwner, address indexed newOwner)`). ## Motivation Many smart contracts require that they be owned or controlled in some way. For example to withdraw funds or perform administrative actions. It is so common that the contract interface used to handle contract ownership should be standardized to allow compatibility with user interfaces and contracts that manage contracts. Here are some examples of kinds of contracts and applications that can benefit from this standard: 1. Exchanges that buy/sell/auction ethereum contracts. This is only widely possible if there is a standard for getting the owner of a contract and transferring ownership. 2. Contract wallets that hold the ownership of contracts and that can transfer the ownership of contracts. 3. Contract registries. It makes sense for some registries to only allow the owners of contracts to add/remove their contracts. A standard must exist for these contract registries to verify that a contract is being submitted by the owner of it before accepting it. 4. User interfaces that show and transfer ownership of contracts. ## Specification Every ERC-173 compliant contract must implement the `ERC173` interface. Contracts should also implement `ERC165` for the ERC-173 interface. ```solidity /// @title ERC-173 Contract Ownership Standard /// Note: the ERC-165 identifier for this interface is 0x7f5828d0 interface ERC173 /* is ERC165 */ { /// @dev This emits when ownership of a contract changes. event OwnershipTransferred(address indexed previousOwner, address indexed newOwner); /// @notice Get the address of the owner /// @return The address of the owner. function owner() view external returns(address); /// @notice Set the address of the new owner of the contract /// @dev Set _newOwner to address(0) to renounce any ownership. /// @param _newOwner The address of the new owner of the contract function transferOwnership(address _newOwner) external; } interface ERC165 { /// @notice Query if a contract implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 /// @dev Interface identification is specified in ERC-165. /// @return `true` if the contract implements `interfaceID` and /// `interfaceID` is not 0xffffffff, `false` otherwise function supportsInterface(bytes4 interfaceID) external view returns (bool); } ``` The `owner()` function may be implemented as `pure` or `view`. The `transferOwnership(address _newOwner)` function may be implemented as `public` or `external`. To renounce any ownership of a contract set `_newOwner` to the zero address: `transferOwnership(address(0))`. If this is done then a contract is no longer owned by anybody. The OwnershipTransferred event should be emitted when a contract is created. ## Rationale Key factors influencing the standard: - Keeping the number of functions in the interface to a minimum to prevent contract bloat. - Backwards compatibility with existing contracts. - Simplicity - Gas efficient Several ownership schemes were considered. The scheme chosen in this standard was chosen because of its simplicity, low gas cost and backwards compatibility with existing contracts. Here are other schemes that were considered: 1. **Associating an Ethereum Name Service (ENS) domain name with a contract.** A contract's `owner()` function could look up the owner address of a particular ENS name and use that as the owning address of the contract. Using this scheme a contract could be transferred by transferring the ownership of the ENS domain name to a different address. Short comings to this approach are that it is not backwards compatible with existing contracts and requires gas to make external calls to ENS related contracts to get the owner address. 2. **Associating an ERC721-based non-fungible token (NFT) with a contract.** Ownership of a contract could be tied to the ownership of an NFT. The benefit of this approach is that the existing ERC721-based infrastructure could be used to sell/buy/auction contracts. Short comings to this approach are additional complexity and infrastructure required. A contract could be associated with a particular NFT but the NFT would not track that it had ownership of a contract unless it was programmed to track contracts. In addition handling ownership of contracts this way is not backwards compatible. This standard does not exclude the above ownership schemes or other schemes from also being implemented in the same contract. For example a contract could implement this standard and also implement the other schemes so that ownership could be managed and transferred in multiple ways. This standard does provide a simple ownership scheme that is backwards compatible, is light-weight and simple to implement, and can be widely adopted and depended on. This standard can be (and has been) extended by other standards to add additional ownership functionality. ## Security Considerations If the address returned by `owner()` is an externally owned account then its private key must not be lost or compromised. ## Backwards Compatibility Many existing contracts already implement this standard. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 07 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-173 https://eips.ethereum.org/EIPS/eip-173 ENS support for reverse resolution of Ethereum addresses Standards Track/ERC # Abstract This EIP specifies a TLD, registrar, and resolver interface for reverse resolution of Ethereum addresses using ENS. This permits associating a human-readable name with any Ethereum blockchain address. Resolvers can be certain that the reverse record was published by the owner of the Ethereum address in question. # Motivation While name services are mostly used for forward resolution - going from human-readable identifiers to machine-readable ones - there are many use-cases in which reverse resolution is useful as well: - Applications that allow users to monitor accounts benefit from showing the name of an account instead of its address, even if it was originally added by address. - Attaching metadata such as descriptive information to an address allows retrieving this information regardless of how the address was originally discovered. - Anyone can configure a name to resolve to an address, regardless of ownership of that address. Reverse records allow the owner of an address to claim a name as authoritative for that address. # Specification Reverse ENS records are stored in the ENS hierarchy in the same fashion as regular records, under a reserved domain, `addr.reverse`. To generate the ENS name for a given account's reverse records, convert the account to hexadecimal representation in lower-case, and append `addr.reverse`. For instance, the ENS registry's address at `0x112234455c3a32fd11230c42e7bccd4a84e02010` has any reverse records stored at `112234455c3a32fd11230c42e7bccd4a84e02010.addr.reverse`. Note that this means that contracts wanting to do dynamic reverse resolution of addresses will need to perform hex encoding in the contract. ## Registrar The owner of the `addr.reverse` domain will be a registrar that permits the caller to take ownership of the reverse record for their own address. It provides the following methods: ### function claim(address owner) returns (bytes32 node) When called by account `x`, instructs the ENS registry to transfer ownership of the name `hex(x) + '.addr.reverse'` to the provided address, and return the namehash of the ENS record thus transferred. Allowing the caller to specify an owner other than themselves for the relevant node facilitates contracts that need accurate reverse ENS entries delegating this to their creators with a minimum of code inside their constructor: reverseRegistrar.claim(msg.sender) ### function claimWithResolver(address owner, address resolver) returns (bytes32 node) When called by account `x`, instructs the ENS registry to set the resolver of the name `hex(x) + '.addr.reverse'` to the specified resolver, then transfer ownership of the name to the provided address, and return the namehash of the ENS record thus transferred. This method facilitates setting up a custom resolver and owner in fewer transactions than would be required if calling `claim`. ### function setName(string name) returns (bytes32 node) When called by account `x`, sets the resolver for the name `hex(x) + '.addr.reverse'` to a default resolver, and sets the name record on that name to the specified name. This method facilitates setting up simple reverse records for users in a single transaction. ## Resolver interface A new resolver interface is defined, consisting of the following method: function name(bytes32 node) constant returns (string); Resolvers that implement this interface must return a valid ENS name for the requested node, or the empty string if no name is defined for the requested node. The interface ID of this interface is 0x691f3431. Future EIPs may specify more record types appropriate to reverse ENS records. # Appendix 1: Registrar implementation This registrar, written in Solidity, implements the specifications outlined above. pragma solidity ^0.4.10; import "./AbstractENS.sol"; contract Resolver { function setName(bytes32 node, string name) public; } /** * @dev Provides a default implementation of a resolver for reverse records, * which permits only the owner to update it. */ contract DefaultReverseResolver is Resolver { AbstractENS public ens; mapping(bytes32=>string) public name; /** * @dev Constructor * @param ensAddr The address of the ENS registry. */ function DefaultReverseResolver(AbstractENS ensAddr) { ens = ensAddr; } /** * @dev Only permits calls by the reverse registrar. * @param node The node permission is required for. */ modifier owner_only(bytes32 node) { require(msg.sender == ens.owner(node)); _; } /** * @dev Sets the name for a node. * @param node The node to update. * @param _name The name to set. */ function setName(bytes32 node, string _name) public owner_only(node) { name[node] = _name; } } contract ReverseRegistrar { // namehash('addr.reverse') bytes32 constant ADDR_REVERSE_NODE = 0x91d1777781884d03a6757a803996e38de2a42967fb37eeaca72729271025a9e2; AbstractENS public ens; Resolver public defaultResolver; /** * @dev Constructor * @param ensAddr The address of the ENS registry. * @param resolverAddr The address of the default reverse resolver. */ function ReverseRegistrar(AbstractENS ensAddr, Resolver resolverAddr) { ens = ensAddr; defaultResolver = resolverAddr; } /** * @dev Transfers ownership of the reverse ENS record associated with the * calling account. * @param owner The address to set as the owner of the reverse record in ENS. * @return The ENS node hash of the reverse record. */ function claim(address owner) returns (bytes32 node) { return claimWithResolver(owner, 0); } /** * @dev Transfers ownership of the reverse ENS record associated with the * calling account. * @param owner The address to set as the owner of the reverse record in ENS. * @param resolver The address of the resolver to set; 0 to leave unchanged. * @return The ENS node hash of the reverse record. */ function claimWithResolver(address owner, address resolver) returns (bytes32 node) { var label = sha3HexAddress(msg.sender); node = sha3(ADDR_REVERSE_NODE, label); var currentOwner = ens.owner(node); // Update the resolver if required if(resolver != 0 && resolver != ens.resolver(node)) { // Transfer the name to us first if it's not already if(currentOwner != address(this)) { ens.setSubnodeOwner(ADDR_REVERSE_NODE, label, this); currentOwner = address(this); } ens.setResolver(node, resolver); } // Update the owner if required if(currentOwner != owner) { ens.setSubnodeOwner(ADDR_REVERSE_NODE, label, owner); } return node; } /** * @dev Sets the `name()` record for the reverse ENS record associated with * the calling account. First updates the resolver to the default reverse * resolver if necessary. * @param name The name to set for this address. * @return The ENS node hash of the reverse record. */ function setName(string name) returns (bytes32 node) { node = claimWithResolver(this, defaultResolver); defaultResolver.setName(node, name); return node; } /** * @dev Returns the node hash for a given account's reverse records. * @param addr The address to hash * @return The ENS node hash. */ function node(address addr) constant returns (bytes32 ret) { return sha3(ADDR_REVERSE_NODE, sha3HexAddress(addr)); } /** * @dev An optimised function to compute the sha3 of the lower-case * hexadecimal representation of an Ethereum address. * @param addr The address to hash * @return The SHA3 hash of the lower-case hexadecimal encoding of the * input address. */ function sha3HexAddress(address addr) private returns (bytes32 ret) { addr; ret; // Stop warning us about unused variables assembly { let lookup := 0x3031323334353637383961626364656600000000000000000000000000000000 let i := 40 loop: i := sub(i, 1) mstore8(i, byte(and(addr, 0xf), lookup)) addr := div(addr, 0x10) i := sub(i, 1) mstore8(i, byte(and(addr, 0xf), lookup)) addr := div(addr, 0x10) jumpi(loop, i) ret := sha3(0, 40) } } } ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 01 Dec 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-181 https://eips.ethereum.org/EIPS/eip-181 Ethereum Smart Contract Packaging Standard Standards Track/ERC # Abstract This ERC proposes a specification for Ethereum smart contract packages. The specification was collaboratively developed by the following Ethereum development framework maintainers. * Tim Coulter (Truffle) * Denis Erfurt (Dapple) * Piper Merriam (Populus) * RJ Catalano (Eris PM) * Iuri Matias (Embark) # Motivation Packaging is a core piece of modern software development which is missing from the Ethereum ecosystem. The lack of packaging limits the ability for developers to reuse code which negatively affects productivity and security. A key example of this is the ERC20 standard. There are a few well audited reusable token contracts available but most developers end up writing their own because of the difficulty in finding and reusing existing code. A packaging standard should have the following positive effects on the ecosystem: * Greater overall productivity caused by the ability to reuse existing code. * Increased security caused by the ability to reuse existing well audited implementations of common patterns (ERC20, crowdfunding, etc). Smart contract packaging should also have a direct positive effect on the end user. Wallet software will be able to consume a released package and generate an interface for interacting with any deployed contracts included within that package. With the advent of [ENS](/EIPS/eip-137) all of the pieces will be in place for a wallet to take a human readable name and present the user with an interface for interacting with the underlying application. # Specification The full specification for this standard is maintained separately in the repository [epm/epm-spec](https://github.com/ethpm/epm-spec). This EIP refers to the `1.0.0` version of the specification: [https://github.com/ethpm/epm-spec/tree/v1.0.0](https://github.com/ethpm/epm-spec/tree/v1.0.0) The specification contains details for a single document referred to as a *"Release Lockfile"*. * Release Lockfile Specification: [https://github.com/ethpm/epm-spec/blob/v1.0.0/release-lockfile.spec.md](https://github.com/ethpm/epm-spec/blob/v1.0.0/release-lockfile.spec.md). * JSON Schema for Release Lockfile: [https://github.com/ethpm/epm-spec/blob/v1.0.0/spec/release-lockfile.spec.json](https://github.com/ethpm/epm-spec/blob/v1.0.0/spec/release-lockfile.spec.json) > These documents have not been inlined into this ERC to ensure that there is a single source of truth for the specification. # Use Cases This specification covers the following types of smart contract packages. 1. Packages with contracts intended to be used as base contract such as the common `owned` pattern. 2. Packages with contracts that are ready to use as-is such as an ERC20 token contract. 3. Packages with deployed contracts such as libraries or services. Full explanations and examples of these use cases can be found in the [`README.md`](https://github.com/ethpm/epm-spec/blob/v1.0.0/README.md#use-cases) from the `epm/epm-spec` repository. # Package Managers The *Release Lockfile* is intended for consumption by package management software. Specific care was made to ensure that all of the following functionality can be implemented by package managers. ## Deterministic builds Ensures that a package will always resolve to the same set of dependencies and source files. Both source files and dependencies are content addressed to ensure that the referenced resources cannot change. ## Bytecode verification Contains the appropriate information for a package manager to inspect a deployed contract and verify that its bytecode matches the bytecode that results from compilation and linking of the package source code. ## Multi-chain deploys Supports deployments across multiple chains, allowing a package to define addresses on both the public mainnet and testnet. ## Trusted packages Allows for packages which exclude source code or other elements which would be needed for verification of the contract bytecode. This allows for minimalistic packages to be created for special situations where the package manager will not be performing verification. # Framework support and integration Support for ERC190 is either implemented or in progress for the following: * [Truffle](https://truffleframework.com/) * [Populus](https://populus.readthedocs.io/en/latest/) * [Dapple](https://dapple.readthedocs.io/en/master/) * [Eris PM](https://github.com/eris-ltd/eris-cli) * [Embark](https://github.com/iurimatias/embark-framework) * [Browser Solidity](https://github.com/ethereum/remix-ide/issues/386) Tue, 10 Jan 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-190 https://eips.ethereum.org/EIPS/eip-190 Signed Data Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/191 # Abstract This ERC proposes a specification about how to handle signed data in Ethereum contracts. # Motivation Several multisignature wallet implementations have been created which accepts `presigned` transactions. A `presigned` transaction is a chunk of binary `signed_data`, along with signature (`r`, `s` and `v`). The interpretation of the `signed_data` has not been specified, leading to several problems: * Standard Ethereum transactions can be submitted as `signed_data`. An Ethereum transaction can be unpacked, into the following components: `RLP<nonce, gasPrice, startGas, to, value, data>` (hereby called `RLPdata`), `r`, `s` and `v`. If there are no syntactical constraints on `signed_data`, this means that `RLPdata` can be used as a syntactically valid `presigned` transaction. * Multisignature wallets have also had the problem that a `presigned` transaction has not been tied to a particular `validator`, i.e a specific wallet. Example: 1. Users `A`, `B` and `C` have the `2/3`-wallet `X` 2. Users `A`, `B` and `D` have the `2/3`-wallet `Y` 3. User `A` and `B` submit `presigned` transactions to `X`. 4. Attacker can now reuse their presigned transactions to `X`, and submit to `Y`. ## Specification We propose the following format for `signed_data` ``` 0x19 <1 byte version> <version specific data> <data to sign>. ``` The initial `0x19` byte is intended to ensure that the `signed_data` is not valid RLP. > For a single byte whose value is in the [0x00, 0x7f] range, that byte is its own RLP encoding. That means that any `signed_data` cannot be one RLP-structure, but a 1-byte `RLP` payload followed by something else. Thus, any EIP-191 `signed_data` can never be an Ethereum transaction. Additionally, `0x19` has been chosen because since ethereum/go-ethereum#2940 , the following is prepended before hashing in personal_sign: ``` "\x19Ethereum Signed Message:\n" + len(message). ``` Using `0x19` thus makes it possible to extend the scheme by defining a version `0x45` (`E`) to handle these kinds of signatures. ### Registry of version bytes | Version byte | EIP | Description | ------------ | -------------- | ----------- | `0x00` | [191][eip-191] | Data with intended validator | `0x01` | [712][eip-712] | Structured data | `0x45` | [191][eip-191] | `personal_sign` messages #### Version `0x00` ``` 0x19 <0x00> <intended validator address> <data to sign> ``` The version `0x00` has `<intended validator address>` for the version specific data. In the case of a Multisig wallet that perform an execution based on a passed signature, the validator address is the address of the Multisig itself. The data to sign could be any arbitrary data. #### Version `0x01` The version `0x01` is for structured data as defined in [EIP-712] #### Version `0x45` (E) ``` 0x19 <0x45 (E)> <thereum Signed Message:\n" + len(message)> <data to sign> ``` The version `0x45` (E) has `<thereum Signed Message:\n" + len(message)>` for the version-specific data. The data to sign can be any arbitrary data. > NB: The `E` in `Ethereum Signed Message` refers to the version byte 0x45. The character `E` is `0x45` in hexadecimal which makes the remainder, `thereum Signed Message:\n + len(message)`, the version-specific data. [EIP-191]: /EIPS/eip-191 [EIP-712]: /EIPS/eip-712 ### Example The following snippets has been written in Solidity 0.8.0. #### Version `0x00` ```solidity function signatureBasedExecution(address target, uint256 nonce, bytes memory payload, uint8 v, bytes32 r, bytes32 s) public payable { // Arguments when calculating hash to validate // 1: byte(0x19) - the initial 0x19 byte // 2: byte(0) - the version byte // 3: address(this) - the validator address // 4-6 : Application specific data bytes32 hash = keccak256(abi.encodePacked(byte(0x19), byte(0), address(this), msg.value, nonce, payload)); // recovering the signer from the hash and the signature addressRecovered = ecrecover(hash, v, r, s); // logic of the wallet // if (addressRecovered == owner) executeOnTarget(target, payload); } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 20 Jan 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-191 https://eips.ethereum.org/EIPS/eip-191 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 Standards Track/Core ## Simple Summary Precompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit. ## Abstract This EIP suggests to add precompiled contracts for addition and scalar multiplication on a specific pairing-friendly elliptic curve. This can in turn be combined with [EIP-197](/EIPS/eip-197) to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property). ## Motivation Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced. Note that while fixing these parameters might look like limiting the use-cases for zkSNARKs, the primitives are so basic that they can be combined in ways that are flexible enough so that it should even be possible to allow future advances in zkSNARK research without the need for a further hard fork. ## Specification If `block.number >= BYZANTIUM_FORK_BLKNUM`, add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "alt_bn128". Address of ADD: 0x6 Address for MUL: 0x7 The curve is defined by: ``` Y^2 = X^3 + 3 over the field F_p with p = 21888242871839275222246405745257275088696311157297823662689037894645226208583 ``` ### Encoding Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`. Tuples of objects are encoded as their concatenation. For both precompiled contracts, if the input is shorter than expected, it is assumed to be virtually padded with zeros at the end (i.e. compatible with the semantics of the `CALLDATALOAD` opcode). If the input is longer than expected, surplus bytes at the end are ignored. The length of the returned data is always as specified (i.e. it is not "unpadded"). ### Exact semantics Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates) is equal or larger than the field modulus p, the contract fails. The scalar can be any number between `0` and `2**256-1`. #### ADD Input: two curve points `(x, y)`. Output: curve point `x + y`, where `+` is point addition on the elliptic curve `alt_bn128` specified above. Fails on invalid input and consumes all gas provided. #### MUL Input: curve point and scalar `(x, s)`. Output: curve point `s * x`, where `*` is the scalar multiplication on the elliptic curve `alt_bn128` specified above. Fails on invalid input and consumes all gas. ### Gas costs - Gas cost for ``ECADD``: 500 - Gas cost for ``ECMUL``: 40000 ## Rationale The specific curve `alt_bn128` was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts. The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification: The gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve. A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate). ## Backwards Compatibility As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256. ## Test Cases Inputs to test: - Curve points which would be valid if the numbers were taken mod p (should fail). - Both contracts should succeed on empty input. - Truncated input that results in a valid curve point. - Points not on curve (but valid otherwise). - Multiply point with scalar that lies between the order of the group and the field (should succeed). - Multiply point with scalar that is larger than the field order (should succeed). ## Implementation Implementation of these primitives are available here: - [libff](https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.cpp) (C++) - [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust) In both codebases, a specific group on the curve alt_bn128 is used and is called G1. - [Python](https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_curve.py) - probably most self-contained and best readable. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 02 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-196 https://eips.ethereum.org/EIPS/eip-196 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128 Standards Track/Core ## Simple Summary Precompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit. ## Abstract This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with [EIP-196](/EIPS/eip-196) to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property). ## Motivation Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced. Note that fixing these parameters will in no way limit the use-cases for zkSNARKs, it will even allow for incorporating some advances in zkSNARK research without the need for a further hard fork. Pairing functions can be used to perform a limited form of multiplicatively homomorphic operations, which are necessary for current zkSNARKs. This precompile can be used to run such computations within the block gas limit. This precompiled contract only specifies a certain check, and not an evaluation of a pairing function. The reason is that the codomain of a pairing function is a rather complex field which could provide encoding problems and all known uses of pairing function in zkSNARKs only require the specified check. ## Specification For blocks where `block.number >= BYZANTIUM_FORK_BLKNUM`, add a precompiled contracts for a bilinear function on groups on the elliptic curve "alt_bn128". We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below. Address: 0x8 For a cyclic group `G` (written additively) of prime order `q` let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the smallest non-negative integer `n` such that `n * P = x`. The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` are defined by their generators `P_1` and `P_2` below. Both generators have the same prime order `q`. ``` Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k Output: If the length of the input is incorrect or any of the inputs are not elements of the respective group or are not encoded correctly, the call fails. Otherwise, return one if log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q) and zero else. ``` Note that `k` is determined from the length of the input. Following the section on the encoding below, `k` is the length of the input divided by `192`. If the input length is not a multiple of `192`, the call fails. Empty input is valid and results in returning one. In order to check that an input is an element of `G_1`, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For `G_2`, in addition to that, the order of the element has to be checked to be equal to the group order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617`. ### Definition of the groups The groups `G_1` and `G_2` are cyclic groups of prime order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617`. The group `G_1` is defined on the curve `Y^2 = X^3 + 3` over the field `F_p` with `p = 21888242871839275222246405745257275088696311157297823662689037894645226208583` with generator `P1 = (1, 2)`. The group `G_2` is defined on the curve `Y^2 = X^3 + 3/(i+9)` over a different field `F_p^2 = F_p[i] / (i^2 + 1)` (p is the same as above) with generator ``` P2 = ( 11559732032986387107991004021392285783925812861821192530917403151452391805634 * i + 10857046999023057135944570762232829481370756359578518086990519993285655852781, 4082367875863433681332203403145435568316851327593401208105741076214120093531 * i + 8495653923123431417604973247489272438418190587263600148770280649306958101930 ) ``` Note that `G_2` is the only group of order `q` of that elliptic curve over the field `F_p^2`. Any other generator of order `q` instead of `P2` would define the same `G_2`. However, the concrete value of `P2` is useful for skeptical readers who doubt the existence of a group of order `q`. They can be instructed to compare the concrete values of `q * P2` and `P2`. ### Encoding Elements of `F_p` are encoded as 32 byte big-endian numbers. An encoding value of `p` or larger is invalid. Elements `a * i + b` of `F_p^2` are encoded as two elements of `F_p`, `(a, b)`. Elliptic curve points are encoded as a Jacobian pair `(X, Y)` where the point at infinity is encoded as `(0, 0)`. Note that the number `k` is derived from the input length. The length of the returned data is always exactly 32 bytes and encoded as a 32 byte big-endian number. ### Gas costs The gas costs of the precompiled contract are `80 000 * k + 100 000`, where `k` is the number of points or, equivalently, the length of the input divided by 192. ## Rationale The specific curve `alt_bn128` was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts. The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification; the gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve or does not admit an efficient pairing implementation. A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate). The encoding of field elements in `F_p^2` was chosen in this order to be in line with the big endian encoding of the elements themselves. ## Backwards Compatibility As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256. ## Test Cases To be written. ## Implementation The precompiled contract can be implemented using elliptic curve pairing functions, more specifically, an optimal ate pairing on the alt_bn128 curve, which can be implemented efficiently. In order to see that, first note that a pairing function `e: G_1 x G_2 -> G_T` fulfills the following properties (`G_1` and `G_2` are written additively, `G_T` is written multiplicatively): (1) `e(m * P1, n * P2) = e(P1, P2)^(m * n)` (2) `e` is non-degenerate Now observe that ``` log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q) ``` if and only if ``` e(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = 1 (in G_T) ``` Furthermore, the left hand side of this equation is equal to ``` e(log_P1(a1) * P1, log_P2(b1) * P2) * ... * e(log_P1(ak) * P1, log_P2(bk) * P2) = e(a1, b1) * ... * e(ak, bk) ``` And thus, the precompiled contract can be implemented by verifying that `e(a1, b1) * ... * e(ak, bk) = 1` Implementations are available here: - [libff](https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.hpp) (C++) - [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust) - [Python](https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_pairing.py) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 06 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-197 https://eips.ethereum.org/EIPS/eip-197 Big integer modular exponentiation Standards Track/Core # Parameters * `GQUADDIVISOR: 20` # Specification At address 0x00......05, add a precompile that expects input in the following format: <length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> <BASE> <EXPONENT> <MODULUS> Where every length is a 32-byte left-padded integer representing the number of bytes to be taken up by the next value. Call data is assumed to be infinitely right-padded with zero bytes, and excess data is ignored. Consumes `floor(mult_complexity(max(length_of_MODULUS, length_of_BASE)) * max(ADJUSTED_EXPONENT_LENGTH, 1) / GQUADDIVISOR)` gas, and if there is enough gas, returns an output `(BASE**EXPONENT) % MODULUS` as a byte array with the same length as the modulus. `ADJUSTED_EXPONENT_LENGTH` is defined as follows. * If `length_of_EXPONENT <= 32`, and all bits in `EXPONENT` are 0, return 0 * If `length_of_EXPONENT <= 32`, then return the index of the highest bit in `EXPONENT` (eg. 1 -> 0, 2 -> 1, 3 -> 1, 255 -> 7, 256 -> 8). * If `length_of_EXPONENT > 32`, then return `8 * (length_of_EXPONENT - 32)` plus the index of the highest bit in the first 32 bytes of `EXPONENT` (eg. if `EXPONENT = \x00\x00\x01\x00.....\x00`, with one hundred bytes, then the result is 8 * (100 - 32) + 253 = 797). If all of the first 32 bytes of `EXPONENT` are zero, return exactly `8 * (length_of_EXPONENT - 32)`. `mult_complexity` is a function intended to approximate the difficulty of Karatsuba multiplication (used in all major bigint libraries) and is defined as follows. ``` def mult_complexity(x): if x <= 64: return x ** 2 elif x <= 1024: return x ** 2 // 4 + 96 * x - 3072 else: return x ** 2 // 16 + 480 * x - 199680 ``` For example, the input data: 0000000000000000000000000000000000000000000000000000000000000001 0000000000000000000000000000000000000000000000000000000000000020 0000000000000000000000000000000000000000000000000000000000000020 03 fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f Represents the exponent `3**(2**256 - 2**32 - 978) % (2**256 - 2**32 - 977)`. By Fermat's little theorem, this equals 1, so the result is: 0000000000000000000000000000000000000000000000000000000000000001 Returned as 32 bytes because the modulus length was 32 bytes. The `ADJUSTED_EXPONENT_LENGTH` would be 255, and the gas cost would be `mult_complexity(32) * 255 / 20 = 13056` gas (note that this is ~8 times the cost of using the EXP opcode to compute a 32-byte exponent). A 4096-bit RSA exponentiation would cost `mult_complexity(512) * 4095 / 100 = 22853376` gas in the worst case, though RSA verification in practice usually uses an exponent of 3 or 65537, which would reduce the gas consumption to 5580 or 89292, respectively. This input data: 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000020 0000000000000000000000000000000000000000000000000000000000000020 fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f Would be parsed as a base of 0, exponent of `2**256 - 2**32 - 978` and modulus of `2**256 - 2**32 - 977`, and so would return 0. Notice how if the length_of_BASE is 0, then it does not interpret _any_ data as the base, instead immediately interpreting the next 32 bytes as EXPONENT. This input data: 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000020 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd Would parse a base length of 0, an exponent length of 32, and a modulus length of `2**256 - 1`, where the base is empty, the exponent is `2**256 - 2` and the modulus is `(2**256 - 3) * 256**(2**256 - 33)` (yes, that's a really big number). It would then immediately fail, as it's not possible to provide enough gas to make that computation. This input data: 0000000000000000000000000000000000000000000000000000000000000001 0000000000000000000000000000000000000000000000000000000000000002 0000000000000000000000000000000000000000000000000000000000000020 03 ffff 8000000000000000000000000000000000000000000000000000000000000000 07 Would parse as a base of 3, an exponent of 65535, and a modulus of `2**255`, and it would ignore the remaining 0x07 byte. This input data: 0000000000000000000000000000000000000000000000000000000000000001 0000000000000000000000000000000000000000000000000000000000000002 0000000000000000000000000000000000000000000000000000000000000020 03 ffff 80 Would also parse as a base of 3, an exponent of 65535 and a modulus of `2**255`, as it attempts to grab 32 bytes for the modulus starting from 0x80 - but there is no further data, so it right-pads it with 31 zero bytes. # Rationale This allows for efficient RSA verification inside of the EVM, as well as other forms of number theory-based cryptography. Note that adding precompiles for addition and subtraction is not required, as the in-EVM algorithm is efficient enough, and multiplication can be done through this precompile via `a * b = ((a + b)**2 - (a - b)**2) / 4`. The bit-based exponent calculation is done specifically to fairly charge for the often-used exponents of 2 (for multiplication) and 3 and 65537 (for RSA verification). # Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 30 Jan 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-198 https://eips.ethereum.org/EIPS/eip-198 ENS support for contract ABIs Standards Track/ERC ## Simple Summary This EIP proposes a mechanism for storing ABI definitions in ENS, for easy lookup of contract interfaces by callers. ## Abstract ABIs are important metadata required for interacting with most contracts. At present, they are typically supplied out-of-band, which adds an additional burden to interacting with contracts, particularly on a one-off basis or where the ABI may be updated over time. The small size of ABIs permits an alternative solution, storing them in ENS, permitting name lookup and ABI discovery via the same process. ABIs are typically quite compact; the largest in-use ABI we could find, that for the DAO, is 9450 bytes uncompressed JSON, 6920 bytes uncompressed CBOR, and 1128 bytes when the JSON form is compressed with zlib. Further gains on CBOR encoding are possible using a CBOR extension that permits eliminating repeated strings, which feature extensively in ABIs. Most ABIs, however, are far shorter than this, consisting of only a few hundred bytes of uncompressed JSON. This EIP defines a resolver profile for retrieving contract ABIs, as well as encoding standards for storing ABIs for different applications, allowing the user to select between different representations based on their need for compactness and other considerations such as onchain access. ## Specification ### ABI encodings In order to allow for different tradeoffs between onchain size and accessibility, several ABI encodings are defined. Each ABI encoding is defined by a unique constant with only a single bit set, allowing for the specification of 256 unique encodings in a single uint. The currently recognised encodings are: | ID | Description | |----|----------------------| | 1 | JSON | | 2 | zlib-compressed JSON | | 4 | CBOR | | 8 | URI | This table may be extended in future through the EIP process. Encoding type 1 specifies plaintext JSON, uncompressed; this is the standard format in which ABIs are typically encoded, but also the bulkiest, and is not easily parseable onchain. Encoding type 2 specifies zlib-compressed JSON. This is significantly smaller than uncompressed JSON, and is straightforward to decode offchain. However, it is impracticalfor onchain consumers to use. Encoding type 4 is [CBOR](https://cbor.io/). CBOR is a binary encoding format that is a superset of JSON, and is both more compact and easier to parse in limited environments such as the EVM. Consumers that support CBOR are strongly encouraged to also support the [stringref extension](http://cbor.schmorp.de/stringref) to CBOR, which provides significant additional reduction in encoded size. Encoding type 8 indicates that the ABI can be found elsewhere, at the specified URI. This is typically the most compact of the supported forms, but also adds external dependencies for implementers. The specified URI may use any schema, but HTTP, IPFS, and Swarm are expected to be the most common. ### Resolver profile A new resolver interface is defined, consisting of the following method: function ABI(bytes32 node, uint256 contentType) constant returns (uint256, bytes); The interface ID of this interface is 0x2203ab56. contentType is a bitfield, and is the bitwise OR of all the encoding types the caller will accept. Resolvers that implement this interface must return an ABI encoded using one of the requested formats, or `(0, "")` if they do not have an ABI for this function, or do not support any of the requested formats. The `abi` resolver profile is valid on both forward and reverse records. ### ABI lookup process When attempting to fetch an ABI based on an ENS name, implementers should first attempt an ABI lookup on the name itself. If that lookup returns no results, they should attempt a reverse lookup on the Ethereum address the name resolves to. Implementers should support as many of the ABI encoding formats as practical. ## Rationale Storing ABIs onchain avoids the need to introduce additional dependencies for applications wishing to fetch them, such as swarm or HTTP access. Given the typical compactness of ABIs, we believe this is a worthwhile tradeoff in many cases. The two-step resolution process permits different names to provide different ABIs for the same contract, such as in the case where it's useful to provide a minimal ABI to some callers, as well as specifying ABIs for contracts that did not specify one of their own. The fallback to looking up an ABI on the reverse record permits contracts to specify their own canonical ABI, and prevents the need for duplication when multiple names reference the same contract without the need for different ABIs. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 06 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-205 https://eips.ethereum.org/EIPS/eip-205 Blockhash refactoring Standards Track/Core ### Summary Stores blockhashes in the state, reducing the protocol complexity and the need for client implementation complexity in order to process the BLOCKHASH opcode. Also extends the range of how far back blockhash checking can go, with the side effect of creating direct links between blocks with very distant block numbers, facilitating much more efficient initial light client syncing. ### Parameters * `CONSTANTINOPLE_FORK_BLKNUM`: TBD * `SUPER_USER`: 2**160 - 2 * `BLOCKHASH_CONTRACT_ADDR`: 0xf0 (ie. 240) * `BLOCKHASH_CONTRACT_CODE`: see below ### Specification If `block.number == CONSTANTINOPLE_FORK_BLKNUM`, then when processing the block, before processing any transactions set the code of BLOCKHASH_CONTRACT_ADDR to BLOCKHASH_CONTRACT_CODE. If `block.number >= CONSTANTINOPLE_FORK_BLKNUM`, then when processing a block, before processing any transactions execute a call with the parameters: * `SENDER`: SUPER_USER * `GAS`: 1000000 * `TO`: BLOCKHASH_CONTRACT_ADDR * `VALUE`: 0 * `DATA`: &lt;32 bytes corresponding to the block's prevhash&gt; If `block.number >= CONSTANTINOPLE_FORK_BLKNUM + 256`, then the BLOCKHASH opcode instead returns the result of executing a call (NOT a transaction) with the parameters: * `SENDER`: &lt;account from which the opcode was called&gt; * `GAS`: 1000000 * `TO`: BLOCKHASH_CONTRACT_ADDR * `VALUE`: 0 * `DATA`: 32 byte zero-byte-leftpadded integer representing the stack argument with which the opcode was called Also, for blocks where `block.number >= CONSTANTINOPLE_FORK_BLKNUM`, the gas cost is increased from 20 to 800 to reflect the higher costs of processing the algorithm in the contract code. ### BLOCKHASH_CONTRACT_CODE The Serpent source code is: ```python with offset = 0: if msg.sender == 0xfffffffffffffffffffffffffffffffffffffffe: with bn = block.number - 1: while bn: ~sstore(offset + ~mod(bn, 256), ~calldataload(0)) if ~mod(bn, 256): ~stop() bn = ~div(bn, 256) offset += 256 elif ~calldataload(0) >= 0 and ~calldataload(0) < block.number: with tbn = ~calldataload(0): with dist_minus_one = block.number - tbn - 1: while dist_minus_one >= 256 && ~mod(tbn, 256) == 0: offset += 256 tbn = ~div(tbn, 256) dist_minus_one = ~div(dist_minus_one, 256) if dist_minus_one >= 256: return(0) return(~sload(offset + ~mod(tbn, 256))) else: return(0) ``` The EVM init code is: ``` 0x6100f58061000e60003961010356600073fffffffffffffffffffffffffffffffffffffffe33141561005857600143035b801561005257600035610100820683015561010081061561003f57005b6101008104905061010082019150610022565b506100f3565b600060003512151561006e574360003512610071565b60005b156100e7576000356001814303035b6101008112151561009857600061010083061461009b565b60005b156100ba57610100830192506101008204915061010081049050610080565b610100811215156100d057600060a052602060a0f35b610100820683015460c052602060c0f350506100f2565b600060e052602060e0f35b5b505b6000f3 ``` The EVM bytecode that the contract code should be set to is: ``` 0x600073fffffffffffffffffffffffffffffffffffffffe33141561005857600143035b801561005257600035610100820683015561010081061561003f57005b6101008104905061010082019150610022565b506100f3565b600060003512151561006e574360003512610071565b60005b156100e7576000356001814303035b6101008112151561009857600061010083061461009b565b60005b156100ba57610100830192506101008204915061010081049050610080565b610100811215156100d057600060a052602060a0f35b610100820683015460c052602060c0f350506100f2565b600060e052602060e0f35b5b50 ``` ### Rationale This removes the need for implementations to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols. Fri, 10 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-210 https://eips.ethereum.org/EIPS/eip-210 New opcodes: RETURNDATASIZE and RETURNDATACOPY Standards Track/Core ## Simple Summary A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible. ## Abstract Please see summary. ## Motivation In some situations, it is vital for a function to be able to return data whose length cannot be anticipated before the call. In principle, this can be solved without alterations to the EVM, for example by splitting the call into two calls where the first is used to compute only the size. All of these mechanisms, though, are very expensive in at least some situations. A very useful example of such a worst-case situation is a generic forwarding contract; a contract that takes call data, potentially makes some checks and then forwards it as is to another contract. The return data should of course be transferred in a similar way to the original caller. Since the contract is generic and does not know about the contract it calls, there is no way to determine the size of the output without adapting the called contract accordingly or trying a logarithmic number of calls. Compiler implementors are advised to reserve a zero-length area for return data if the size of the return data is unknown before the call and then use `RETURNDATACOPY` in conjunction with `RETURNDATASIZE` to actually retrieve the data. Note that this proposal also makes the EIP that proposes to allow to return data in case of an intentional state reversion ([EIP-140](/EIPS/eip-140)) much more useful. Since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the CALL opcode has signalled a failure, even if the regular output area is not large enough to hold the data. ## Specification If `block.number >= BYZANTIUM_FORK_BLKNUM`, add two new opcodes and amend the semantics of any opcode that creates a new call frame (like `CALL`, `CREATE`, `DELEGATECALL`, ...) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see [EIP-140](/EIPS/eip-140)) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, `CREATE` and `CREATE2` are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty. As an optimization, it is possible to share the return data buffer across call frames because at most one will be non-empty at any time. `RETURNDATASIZE`: `0x3d` Pushes the size of the return data buffer onto the stack. Gas costs: 2 (same as `CALLDATASIZE`) `RETURNDATACOPY`: `0x3e` This opcode has similar semantics to `CALLDATACOPY`, but instead of copying data from the call data, it copies data from the return data buffer. Furthermore, accessing the return data buffer beyond its size results in a failure; i.e. if `start + length` overflows or results in a value larger than `RETURNDATASIZE`, the current call stops in an out-of-gas condition. In particular, reading 0 bytes from the end of the buffer will read 0 bytes; reading 0 bytes from one-byte out of the buffer causes an exception. Gas costs: `3 + 3 * ceil(amount / 32)` (same as `CALLDATACOPY`) ## Rationale Other solutions that would allow returning dynamic data were considered, but they all had to deduct the gas from the call opcode and thus were both complicated to implement and specify ([5/8](https://github.com/ethereum/EIPs/issues/8)). Since this proposal is very similar to the way calldata is handled, it fits nicely into the concept. Furthermore, the eWASM architecture already handles return data in exactly the same way. Note that the EVM implementation needs to keep the return data until the next call or the return from the current call. Since this resource was already paid for as part of the memory of the callee, it should not be a problem. Implementations may either choose to keep the full memory of the callee alive until the next call or copy only the return data to a special memory area. Keeping the memory of the callee until the next call-like opcode does not increase the peak memory usage in the following sense; any memory allocation in the caller's frame that happens after the return from the call can be moved before the call without a change in gas costs, but will add this allocation to the peak allocation. The number values of the opcodes were allocated in the same nibble block that also contains `CALLDATASIZE` and `CALLDATACOPY`. ## Backwards Compatibility This proposal introduces two new opcodes and stays fully backwards compatible apart from that. ## Test Cases ## Implementation ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 13 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-211 https://eips.ethereum.org/EIPS/eip-211 New opcode STATICCALL Standards Track/Core ## Simple Summary To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). ## Abstract This proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). Any opcode that attempts to perform such a modification (see below for details) will result in an exception instead of performing the modification. ## Motivation Currently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. This poses certain difficulties about smart contract engineers; after a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. Furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases. This EIP adds a way to call other contracts and restrict what they can do in the simplest way. It can be safely assumed that the state of all accounts is the same before and after a static call. ## Specification Introduce a new `STATIC` flag to the virtual machine. This flag is set to `false` initially. Its value is always copied to sub-calls with an exception for the new opcode below. Opcode: `0xfa`. `STATICCALL` functions equivalently to a `CALL`, except it takes only 6 arguments (the "value" argument is not included and taken to be zero), and calls the child with the `STATIC` flag set to `true` for the execution of the child. Once this call returns, the flag is reset to its value before the call. Any attempts to make state-changing operations inside an execution instance with `STATIC` set to `true` will instead throw an exception. These operations include `CREATE`, `CREATE2`, `LOG0`, `LOG1`, `LOG2`, `LOG3`, `LOG4`, `SSTORE`, and `SELFDESTRUCT`. They also include `CALL` with a non-zero value. As an exception, `CALLCODE` is not considered state-changing, even with a non-zero value. ## Rationale This allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else. This may also make purely functional HLLs easier to implement. ## Backwards Compatibility This proposal adds a new opcode but does not modify the behaviour of other opcodes and thus is backwards compatible for old contracts that do not use the new opcode and are not called via the new opcode. ## Test Cases To be written. ## Implementation ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 13 Feb 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-214 https://eips.ethereum.org/EIPS/eip-214 Token with transaction handling model Standards Track/ERC https://ethereum-magicians.org/t/erc-223-token-standard/12894 ## Abstract The following describes an interface and logic for fungible tokens that supports a `tokenReceived` callback to notify contract recipients when tokens are received. This makes tokens behave identical to ether. ## Motivation This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with such tokens. Specifically, this proposal: 1. Informs receiving contracts of incoming token transfers, as opposed to [ERC-20](/EIPS/eip-20) where the recipient of a token transfer gets no notification. 2. Is more gas-efficient when depositing tokens to contracts. 3. Allows for `_data` recording for financial transfers. ## Specification Contracts intending to receive these tokens MUST implement `tokenReceived`. Token transfers to contracts not implementing `tokenReceived` as described below MUST revert. ### Token contract #### Token Methods ##### `totalSupply` ```solidity function totalSupply() view returns (uint256) ``` Returns the total supply of the token. The functionality of this method is identical to that of ERC-20. ##### `name` ```solidity function name() view returns (string memory) ``` Returns the name of the token. The functionality of this method is identical to that of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. ##### `symbol` ```solidity function symbol() view returns (string memory) ``` Returns the symbol of the token. The functionality of this method is identical to that of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. ##### `decimals` ```solidity function decimals() view returns (uint8) ``` Returns the number of decimals of the token. The functionality of this method is identical to that of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. ##### `balanceOf` ```solidity function balanceOf(address _owner) view returns (uint256) ``` Returns the account balance of another account with address `_owner`. The functionality of this method is identical to that of ERC-20. ##### `transfer(address, uint)` ```solidity function transfer(address _to, uint _value) returns (bool) ``` This function must transfer tokens, and if `_to` is a contract, it must call the `tokenReceived(address, uint256, bytes calldata)` function of `_to`. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must be reverted. If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty. The `tokenReceived` function of `_to` MUST be called after all other operations to avoid re-entrancy attacks. NOTE: If `transfer` function is `payable` and ether was deposited then the amount of deposited ether MUST be delivered to `_to` address alongside tokens. If ether was sent alongside tokens in this way then ether MUST be delivered first, then token balances must be updated, then `tokenReceived` function MUST be called in `_to` if it is a contract. ##### `transfer(address, uint, bytes)` ```solidity function transfer(address _to, uint _value, bytes calldata _data) returns (bool) ``` This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must not occur. If `_to` is an externally owned address (determined by the code size being zero), then the transaction must be sent without executing `tokenReceived` in `_to`. `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty. NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. If `transfer` function is `payable` and ether was deposited then the amount of deposited ether MUST be delivered to `_to` address alongside tokens. The `tokenReceived` function of `_to` MUST be called after all other operations to avoid re-entrancy attacks. #### Events ##### `Transfer` ```solidity event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes _data) ``` Triggered when tokens are transferred. Compatible with and similar to the ERC-20 `Transfer` event. ### [ERC-223](/EIPS/eip-223) Token Receiver #### Receiver Methods ```solidity function tokenReceived(address _from, uint _value, bytes calldata _data) returns (bytes4) ``` A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens were sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. The `tokenReceived` function must return `0x8943ec02` after handling an incoming token transfer. The `tokenReceived` function call can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02). IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`. This function can be manually called by a EOA. ## Rationale This standard introduces a communication model by enforcing the `transfer` to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted. This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC-223 transfers are more gas-efficient while dealing with depositing to contracts as ERC-223 tokens can be deposited with just one transaction while ERC-20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). - [ERC-20](/EIPS/eip-20) deposit: `approve` ~46 gas, `transferFrom` ~75K gas - ERC-223 deposit: `transfer` and handling on the receivers side ~54K gas This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipients side and reject incorrect or improper transfers. This tokens utilize ONE transferring method for both types of interactions with contracts and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. One downside of the commonly used [ERC-20](/EIPS/eip-20) standard that ERC-223 is intended to solve is that [ERC-20](/EIPS/eip-20) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](/EIPS/eip-20) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. [ERC-20](/EIPS/eip-20) standard places the burden of determining the transferring method on the user and if the incorrect method is chosen the user can lose the transferred tokens. ERC-223 automatically determines the transferring method, preventing the user from losing tokens due to choosing wrong method. ERC-223 is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes a "deposit" pattern, similar to that of plain Ether. An ERC-223 deposit to a contract is a simple call of the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an ether transaction, or allow for public logging on chain should it be necessary for financial transactions. ## Backwards Compatibility The interface of this token is similar to that of ERC-20 and most functions serve the same purpose as their analogues in ERC-20. `transfer(address, uint256, bytes calldata)` function is not backwards compatible with ERC-20 interface. ERC-20 tokens can be delivered to a non-contract address with `transfer` function. ERC-20 tokens can be deposited to a contract address with `approve` + `transferFrom` pattern. Depositing ERC-20 tokens to the contract address with `transfer` function will always result in token deposit not being recognized by the recipient contract. Here is an example of the contract code that handles ERC-20 token deposit. The following contract can accepts `tokenA` deposits. It is impossible to prevent deposits of non-tokenA to this contract. If tokenA is deposited with `transfer` function then it will result in a loss of tokens for the depositor because the balance of the user will be decreased in the contract of tokenA but the value of `deposits` variable in the `ERC20Receiver` will not be increased i.e. the deposit will not be credited. As of 5/9/2023 **$201M worth of 50 examined ERC-20 tokens are already lost** in this way on Ethereum mainnet. ```solidity contract ERC20Receiver { address tokenA; mapping (address => uint256) deposits; function deposit(uint _value, address _token) public { require(_token == tokenA); IERC20(_token).transferFrom(msg.sender, address(this), _value); deposits[msg.sender] += _value; } } ``` ERC-223 tokens must be delivered to non-contract address or contract address in the same way with `transfer` function. Here is an example of the contract code that handles ERC-223 token deposit. The following contract can filter tokens and only accepts `tokenA`. Other ERC-223 tokens would be rejected. ```solidity contract ERC223Receiver { address tokenA; mapping (address => uint256) deposits; function tokenReceived(address _from, uint _value, bytes memory _data) public returns (bytes4) { require(msg.sender == tokenA); deposits[_from] += _value; return 0x8943ec02; } } ``` ## Security Considerations This token utilizes the model similar to plain ether behavior. Therefore replay issues must be taken into account. ### Reference Implementation ```solidity pragma solidity ^0.8.19; library Address { /** * @dev Returns true if `account` is a contract. * * This test is non-exhaustive, and there may be false-negatives: during the * execution of a contract's constructor, its address will be reported as * not containing a contract. * * > It is unsafe to assume that an address for which this function returns * false is an externally-owned account (EOA) and not a contract. */ function isContract(address account) internal view returns (bool) { // This method relies in extcodesize, which returns 0 for contracts in // construction, since the code is only stored at the end of the // constructor execution. uint256 size; // solhint-disable-next-line no-inline-assembly assembly { size := extcodesize(account) } return size > 0; } } abstract contract IERC223Recipient { /** * @dev Standard ERC-223 receiving function that will handle incoming token transfers. * * @param _from Token sender address. * @param _value Amount of tokens. * @param _data Transaction metadata. */ function tokenReceived(address _from, uint _value, bytes memory _data) public virtual returns (bytes4); } /** * @title Reference implementation of the ERC223 standard token. */ contract ERC223Token { /** * @dev Event that is fired on successful transfer. */ event Transfer(address indexed from, address indexed to, uint value, bytes data); string private _name; string private _symbol; uint8 private _decimals; uint256 private _totalSupply; mapping(address => uint256) private balances; // List of user balances. /** * @dev Sets the values for {name} and {symbol}, initializes {decimals} with * a default value of 18. * * To select a different value for {decimals}, use {_setupDecimals}. * * All three of these values are immutable: they can only be set once during * construction. */ constructor(string memory new_name, string memory new_symbol, uint8 new_decimals) { _name = new_name; _symbol = new_symbol; _decimals = new_decimals; } /** * @dev Returns the name of the token. */ function name() public view returns (string memory) { return _name; } /** * @dev Returns the symbol of the token, usually a shorter version of the * name. */ function symbol() public view returns (string memory) { return _symbol; } /** * @dev Returns the number of decimals used to get its user representation. * For example, if `decimals` equals `2`, a balance of `505` tokens should * be displayed to a user as `5,05` (`505 / 10 ** 2`). * * Tokens usually opt for a value of 18, imitating the relationship between * Ether and Wei. This is the value {ERC223} uses, unless {_setupDecimals} is * called. * * NOTE: This information is only used for _display_ purposes: it in * no way affects any of the arithmetic of the contract, including * {IERC223-balanceOf} and {IERC223-transfer}. */ function decimals() public view returns (uint8) { return _decimals; } /** * @dev See {IERC223-totalSupply}. */ function totalSupply() public view returns (uint256) { return _totalSupply; } /** * @dev See {IERC223-standard}. */ function standard() public view returns (string memory) { return "223"; } /** * @dev Returns balance of the `_owner`. * * @param _owner The address whose balance will be returned. * @return balance Balance of the `_owner`. */ function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } /** * @dev Transfer the specified amount of tokens to the specified address. * Invokes the `tokenFallback` function if the recipient is a contract. * The token transfer fails if the recipient is a contract * but does not implement the `tokenFallback` function * or the fallback function to receive funds. * * @param _to Receiver address. * @param _value Amount of tokens that will be transferred. * @param _data Transaction metadata. */ function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success) { // Standard function transfer similar to ERC20 transfer with no _data . // Added due to backwards compatibility reasons . balances[msg.sender] = balances[msg.sender] - _value; balances[_to] = balances[_to] + _value; if(Address.isContract(_to)) { IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); } emit Transfer(msg.sender, _to, _value, _data); return true; } /** * @dev Transfer the specified amount of tokens to the specified address. * This function works the same with the previous one * but doesn't contain `_data` param. * Added due to backwards compatibility reasons. * * @param _to Receiver address. * @param _value Amount of tokens that will be transferred. */ function transfer(address _to, uint _value) public returns (bool success) { bytes memory _empty = hex"00000000"; balances[msg.sender] = balances[msg.sender] - _value; balances[_to] = balances[_to] + _value; if(Address.isContract(_to)) { IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); } emit Transfer(msg.sender, _to, _value, _empty); return true; } } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 03 May 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-223 https://eips.ethereum.org/EIPS/eip-223 Clique proof-of-authority consensus protocol Standards Track/Core https://github.com/ethereum/EIPs/issues/225 ## Abstract Clique is a proof-of-authority consensus protocol. It shadows the design of Ethereum mainnet, so it can be added to any client with minimal effort. ## Motivation Ethereum's first official testnet was Morden. It ran from July 2015 to about November 2016, when due to the accumulated junk and some testnet consensus issues between Geth and Parity, it was finally laid to rest in favor of a testnet reboot. Ropsten was thus born, clearing out all the junk and starting with a clean slate. This ran well until the end of February 2017, when malicious actors decided to abuse the low PoW and gradually inflate the block gas limits to 9 billion (from the normal 4.7 million), at which point sending in gigantic transactions crippling the entire network. Even before that, attackers attempted multiple extremely long reorgs, causing network splits between different clients, and even different versions. The root cause of these attacks is that a PoW network is only as secure as the computing capacity placed behind it. Restarting a new testnet from zero wouldn't solve anything, since the attacker can mount the same attack over and over again. The Parity team decided to go with an emergency solution of rolling back a significant number of blocks, and enacting a soft-fork rule that disallows gas limits above a certain threshold. While this solution may work in the short term: * It's not elegant: Ethereum supposed to have dynamic block limits * It's not portable: other clients need to implement new fork logic themselves * It's not compatible with sync modes: fast and light clients are both out of luck * It's just prolonging the attacks: junk can still be steadily pushed in ad infinitum Parity's solution although not perfect, is nonetheless workable. I'd like to propose a longer term alternative solution, which is more involved, yet should be simple enough to allow rolling out in a reasonable amount of time. ### Standardized proof-of-authority As reasoned above, proof-of-work cannot work securely in a network with no value. Ethereum has its long term goal of proof-of-stake based on Casper, but that is heavy research so we cannot rely on that any time soon to fix today's problems. One solution however is easy enough to implement, yet effective enough to fix the testnet properly, namely a proof-of-authority scheme. The main design goals of the PoA protocol described here is that it should be very simple to implement and embed into any existing Ethereum client, while at the same time allow using existing sync technologies (fast, light, warp) without needing client developers to add custom logic to critical software. ## Design constraints There are two approaches to syncing a blockchain in general: * The classical approach is to take the genesis block and crunch through all the transactions one by one. This is tried and proven, but in Ethereum complexity networks quickly turns out to be very costly computationally. * The other is to only download the chain of block headers and verify their validity, after which point an arbitrary recent state may be downloaded from the network and checked against recent headers. A PoA scheme is based on the idea that blocks may only be minted by trusted signers. As such, every block (or header) that a client sees can be matched against the list of trusted signers. The challenge here is how to maintain a list of authorized signers that can change in time? The obvious answer (store it in an Ethereum contract) is also the wrong answer: fast, light and warp sync don't have access to the state during syncing. **The protocol of maintaining the list of authorized signers must be fully contained in the block headers.** The next obvious idea would be to change the structure of the block headers so it drops the notions of PoW, and introduces new fields to cater for voting mechanisms. This is also the wrong answer: changing such a core data structure in multiple implementations would be a nightmare development, maintenance and security wise. **The protocol of maintaining the list of authorized signers must fit fully into the current data models.** So, according to the above, we can't use the EVM for voting, rather have to resort to headers. And we can't change header fields, rather have to resort to the currently available ones. Not much wiggle room. ### Repurposing header fields for signing and voting The most obvious field that currently is used solely as *fun metadata* is the 32 byte **extra-data** section in block headers. Miners usually place their client and version in there, but some fill it with alternative "messages". The protocol would extend this field ~~to~~ with 65 bytes with the purpose of a secp256k1 miner signature. This would allow anyone obtaining a block to verify it against a list of authorized signers. It also makes the **miner** section in block headers obsolete (since the address can be derived from the signature). *Note, changing the length of a header field is a non invasive operation as all code (such as RLP encoding, hashing) is agnostic to that, so clients wouldn't need custom logic.* The above is enough to validate a chain, but how can we update a dynamic list of signers. The answer is that we can repurpose the newly obsoleted **miner** field and the PoA obsoleted **nonce** field to create a voting protocol: * During regular blocks, both of these fields would be set to zero. * If a signer wishes to enact a change to the list of authorized signers, it will: * Set the **miner** to the signer it wishes to vote about * Set the **nonce** to `0` or `0xff...f` to vote in favor of adding or kicking out Any clients syncing the chain can "tally" up the votes during block processing, and maintain a dynamically changing list of authorized signers by popular vote. To avoid having an infinite window to tally up votes in, and also to allow periodically flushing stale proposals, we can reuse the concept of an epoch from ethash, where every epoch transition flushes all pending votes. Furthermore, these epoch transitions can also act as stateless checkpoints containing the list of current authorized signers within the header extra-data. This permits clients to sync up based only on a checkpoint hash without having to replay all the voting that was done on the chain up to that point. It also allows the genesis header to fully define the chain, containing the list of initial signers. ### Attack vector: Malicious signer It may happen that a malicious user gets added to the list of signers, or that a signer key/machine is compromised. In such a scenario the protocol needs to be able to defend itself against reorganizations and spamming. The proposed solution is that given a list of N authorized signers, any signer may only mint 1 block out of every K. This ensures that damage is limited, and the remainder of the miners can vote out the malicious user. ### Attack vector: Censoring signer Another interesting attack vector is if a signer (or group of signers) attempts to censor out blocks that vote on removing them from the authorization list. To work around this, we restrict the allowed minting frequency of signers to 1 out of N/2. This ensures that malicious signers need to control at least 51% of signing accounts, at which case it's game over anyway. ### Attack vector: Spamming signer A final small attack vector is that of malicious signers injecting new vote proposals inside every block they mint. Since nodes need to tally up all votes to create the actual list of authorized signers, they need to track all votes through time. Without placing a limit on the vote window, this could grow slowly, yet unbounded. The solution is to place a ~~moving~~ window of W blocks after which votes are considered stale. ~~A sane window might be 1-2 epochs.~~ We'll call this an epoch. ### Attack vector: Concurrent blocks If the number of authorized signers are N, and we allow each signer to mint 1 block out of K, then at any point in time N-K+1 miners are allowed to mint. To avoid these racing for blocks, every signer would add a small random "offset" to the time it releases a new block. This ensures that small forks are rare, but occasionally still happen (as on the main net). If a signer is caught abusing it's authority and causing chaos, it can be voted out. ## Specification We define the following constants: * **`EPOCH_LENGTH`**: Number of blocks after which to checkpoint and reset the pending votes. * Suggested `30000` for the testnet to remain analogous to the mainnet `ethash` epoch. * **`BLOCK_PERIOD`**: Minimum difference between two consecutive block's timestamps. * Suggested `15s` for the testnet to remain analogous to the mainnet `ethash` target. * **`EXTRA_VANITY`**: Fixed number of extra-data prefix bytes reserved for signer *vanity*. * Suggested `32 bytes` to retain the current extra-data allowance and/or use. * **`EXTRA_SEAL`**: Fixed number of extra-data suffix bytes reserved for signer seal. * `65 bytes` fixed as signatures are based on the standard `secp256k1` curve. * Filled with zeros on genesis block. * **`NONCE_AUTH`**: Magic nonce number `0xffffffffffffffff` to vote on adding a new signer. * **`NONCE_DROP`**: Magic nonce number `0x0000000000000000` to vote on removing a signer. * **`UNCLE_HASH`**: Always `Keccak256(RLP([]))` as uncles are meaningless outside of PoW. * **`DIFF_NOTURN`**: Block score (difficulty) for blocks containing out-of-turn signatures. * Suggested `1` since it just needs to be an arbitrary baseline constant. * **`DIFF_INTURN`**: Block score (difficulty) for blocks containing in-turn signatures. * Suggested `2` to show a slight preference over out-of-turn signatures. We also define the following per-block constants: * **`BLOCK_NUMBER`**: Block height in the chain, where the height of the genesis is block `0`. * **`SIGNER_COUNT`**: Number of authorized signers valid at a particular instance in the chain. * **`SIGNER_INDEX`**: Zero-based index of the block signer in the sorted list of current authorized signers. * **`SIGNER_LIMIT`**: Number of consecutive blocks out of which a signer may only sign one. * Must be `floor(SIGNER_COUNT / 2) + 1` to enforce majority consensus on a chain. We repurpose the `ethash` header fields as follows: * **`beneficiary`** / **`miner`**: Address to propose modifying the list of authorized signers with. * Should be filled with zeroes normally, modified only while voting. * Arbitrary values are permitted nonetheless (even meaningless ones such as voting out non signers) to avoid extra complexity in implementations around voting mechanics. * **Must** be filled with zeroes on checkpoint (i.e. epoch transition) blocks. * Transaction execution **must** use the actual block signer (see `extraData`) for the `COINBASE` opcode and transaction fees **must** be attributed to the signer account. * **`nonce`**: Signer proposal regarding the account defined by the `beneficiary` field. * Should be **`NONCE_DROP`** to propose deauthorizing `beneficiary` as an existing signer. * Should be **`NONCE_AUTH`** to propose authorizing `beneficiary` as a new signer. * **Must** be filled with zeroes on checkpoint (i.e. epoch transition) blocks. * **Must** not take up any other value apart from the two above (for now). * **`extraData`**: Combined field for signer vanity, checkpointing and signer signatures. * First **`EXTRA_VANITY`** bytes (fixed) may contain arbitrary signer vanity data. * Last **`EXTRA_SEAL`** bytes (fixed) is the signer's signature sealing the header. * Checkpoint blocks **must** contain a list of signers (`N*20 bytes`) in between, **omitted** otherwise. * The list of signers in checkpoint block extra-data sections **must** be sorted in ascending byte order. * **`mixHash`**: Reserved for fork protection logic, similar to the extra-data during the DAO. * **Must** be filled with zeroes during normal operation. * **`ommersHash`**: **Must** be **`UNCLE_HASH`** as uncles are meaningless outside of PoW. * **`timestamp`**: **Must** be at least the parent timestamp + **`BLOCK_PERIOD`**. * **`difficulty`**: Contains the standalone score of the block to derive the quality of a chain. * **Must** be **`DIFF_NOTURN`** if `BLOCK_NUMBER % SIGNER_COUNT != SIGNER_INDEX` * **Must** be **`DIFF_INTURN`** if `BLOCK_NUMBER % SIGNER_COUNT == SIGNER_INDEX` ### Authorizing a block To authorize a block for the network, the signer needs to sign the block's sighash containing **everything except the signature itself**. This means that this hash contains every field of the header (`nonce` and `mixDigest` included), and also the `extraData` with the exception of the 65 byte signature suffix. The fields are hashed in the order of their definition in the yellow paper. Note that this sighash differs from the final block hash which also includes the signature. The sighash is signed using the standard `secp256k1` curve, and the resulting 65 byte signature (`R`, `S`, `V`, where `V` is `0` or `1`) is embedded into the `extraData` as the trailing 65 byte suffix. To ensure malicious signers (loss of signing key) cannot wreck havoc in the network, each signer is allowed to sign **maximum one** out of **`SIGNER_LIMIT`** consecutive blocks. The order is not fixed, but in-turn signing weighs more (**`DIFF_INTURN`**) than out of turn one (**`DIFF_NOTURN`**). #### Authorization strategies As long as signers conform to the above specs, they can authorize and distribute blocks as they see fit. The following suggested strategy will however reduce network traffic and small forks, so it's a suggested feature: * If a signer is allowed to sign a block (is on the authorized list and didn't sign recently). * Calculate the optimal signing time of the next block (parent + **`BLOCK_PERIOD`**). * If the signer is in-turn, wait for the exact time to arrive, sign and broadcast immediately. * If the signer is out-of-turn, delay signing by `rand(SIGNER_COUNT * 500ms)`. This small strategy will ensure that the in-turn signer (who's block weighs more) has a slight advantage to sign and propagate versus the out-of-turn signers. Also the scheme allows a bit of scale with the increase of the number of signers. ### Voting on signers Every epoch transition (genesis block included) acts as a stateless checkpoint, from which capable clients should be able to sync without requiring any previous state. This means epoch headers **must not** contain votes, all non settled votes are discarded, and tallying starts from scratch. For all non-epoch transition blocks: * Signers may cast one vote per own block to propose a change to the authorization list. * Only the latest proposal per target beneficiary is kept from a single signer. * Votes are tallied live as the chain progresses (concurrent proposals allowed). * Proposals reaching majority consensus **`SIGNER_LIMIT`** come into effect immediately. * Invalid proposals are **not** to be penalized for client implementation simplicity. **A proposal coming into effect entails discarding all pending votes for that proposal (both for and against) and starting with a clean slate.** #### Cascading votes A complex corner case may arise during signer deauthorization. When a previously authorized signer is dropped, the number of signers required to approve a proposal might decrease by one. This might cause one or more pending proposals to reach majority consensus, the execution of which might further cascade into new proposals passing. Handling this scenario is non obvious when multiple conflicting proposals pass simultaneously (e.g. add a new signer vs. drop an existing one), where the evaluation order might drastically change the outcome of the final authorization list. Since signers may invert their own votes in every block they mint, it's not so obvious which proposal would be "first". To avoid the pitfalls cascading executions would entail, the Clique proposal explicitly forbids cascading effects. In other words: **Only the `beneficiary` of the current header/vote may be added to/dropped from the authorization list. If that causes other proposals to reach consensus, those will be executed when their respective beneficiaries are "touched" again (given that majority consensus still holds at that point).** #### Voting strategies Since the blockchain can have small reorgs, a naive voting mechanism of "cast-and-forget" may not be optimal, since a block containing a singleton vote may not end up on the final chain. A simplistic but working strategy is to allow users to configure "proposals" on the signers (e.g. "add 0x...", "drop 0x..."). The signing code can then pick a random proposal for every block it signs and inject it. This ensures that multiple concurrent proposals as well as reorgs get eventually noted on the chain. This list may be expired after a certain number of blocks / epochs, but it's important to realize that "seeing" a proposal pass doesn't mean it won't get reorged, so it should not be immediately dropped when the proposal passes. ## Test Cases ```go // block represents a single block signed by a particular account, where // the account may or may not have cast a Clique vote. type block struct { signer string // Account that signed this particular block voted string // Optional value if the signer voted on adding/removing someone auth bool // Whether the vote was to authorize (or deauthorize) checkpoint []string // List of authorized signers if this is an epoch block } // Define the various voting scenarios to test tests := []struct { epoch uint64 // Number of blocks in an epoch (unset = 30000) signers []string // Initial list of authorized signers in the genesis blocks []block // Chain of signed blocks, potentially influencing auths results []string // Final list of authorized signers after all blocks failure error // Failure if some block is invalid according to the rules }{ { // Single signer, no votes cast signers: []string{"A"}, blocks: []block{ {signer: "A"} }, results: []string{"A"}, }, { // Single signer, voting to add two others (only accept first, second needs 2 votes) signers: []string{"A"}, blocks: []block{ {signer: "A", voted: "B", auth: true}, {signer: "B"}, {signer: "A", voted: "C", auth: true}, }, results: []string{"A", "B"}, }, { // Two signers, voting to add three others (only accept first two, third needs 3 votes already) signers: []string{"A", "B"}, blocks: []block{ {signer: "A", voted: "C", auth: true}, {signer: "B", voted: "C", auth: true}, {signer: "A", voted: "D", auth: true}, {signer: "B", voted: "D", auth: true}, {signer: "C"}, {signer: "A", voted: "E", auth: true}, {signer: "B", voted: "E", auth: true}, }, results: []string{"A", "B", "C", "D"}, }, { // Single signer, dropping itself (weird, but one less cornercase by explicitly allowing this) signers: []string{"A"}, blocks: []block{ {signer: "A", voted: "A", auth: false}, }, results: []string{}, }, { // Two signers, actually needing mutual consent to drop either of them (not fulfilled) signers: []string{"A", "B"}, blocks: []block{ {signer: "A", voted: "B", auth: false}, }, results: []string{"A", "B"}, }, { // Two signers, actually needing mutual consent to drop either of them (fulfilled) signers: []string{"A", "B"}, blocks: []block{ {signer: "A", voted: "B", auth: false}, {signer: "B", voted: "B", auth: false}, }, results: []string{"A"}, }, { // Three signers, two of them deciding to drop the third signers: []string{"A", "B", "C"}, blocks: []block{ {signer: "A", voted: "C", auth: false}, {signer: "B", voted: "C", auth: false}, }, results: []string{"A", "B"}, }, { // Four signers, consensus of two not being enough to drop anyone signers: []string{"A", "B", "C", "D"}, blocks: []block{ {signer: "A", voted: "C", auth: false}, {signer: "B", voted: "C", auth: false}, }, results: []string{"A", "B", "C", "D"}, }, { // Four signers, consensus of three already being enough to drop someone signers: []string{"A", "B", "C", "D"}, blocks: []block{ {signer: "A", voted: "D", auth: false}, {signer: "B", voted: "D", auth: false}, {signer: "C", voted: "D", auth: false}, }, results: []string{"A", "B", "C"}, }, { // Authorizations are counted once per signer per target signers: []string{"A", "B"}, blocks: []block{ {signer: "A", voted: "C", auth: true}, {signer: "B"}, {signer: "A", voted: "C", auth: true}, {signer: "B"}, {signer: "A", voted: "C", auth: true}, }, results: []string{"A", "B"}, }, { // Authorizing multiple accounts concurrently is permitted signers: []string{"A", "B"}, blocks: []block{ {signer: "A", voted: "C", auth: true}, {signer: "B"}, {signer: "A", voted: "D", auth: true}, {signer: "B"}, {signer: "A"}, {signer: "B", voted: "D", auth: true}, {signer: "A"}, {signer: "B", voted: "C", auth: true}, }, results: []string{"A", "B", "C", "D"}, }, { // Deauthorizations are counted once per signer per target signers: []string{"A", "B"}, blocks: []block{ {signer: "A", voted: "B", auth: false}, {signer: "B"}, {signer: "A", voted: "B", auth: false}, {signer: "B"}, {signer: "A", voted: "B", auth: false}, }, results: []string{"A", "B"}, }, { // Deauthorizing multiple accounts concurrently is permitted signers: []string{"A", "B", "C", "D"}, blocks: []block{ {signer: "A", voted: "C", auth: false}, {signer: "B"}, {signer: "C"}, {signer: "A", voted: "D", auth: false}, {signer: "B"}, {signer: "C"}, {signer: "A"}, {signer: "B", voted: "D", auth: false}, {signer: "C", voted: "D", auth: false}, {signer: "A"}, {signer: "B", voted: "C", auth: false}, }, results: []string{"A", "B"}, }, { // Votes from deauthorized signers are discarded immediately (deauth votes) signers: []string{"A", "B", "C"}, blocks: []block{ {signer: "C", voted: "B", auth: false}, {signer: "A", voted: "C", auth: false}, {signer: "B", voted: "C", auth: false}, {signer: "A", voted: "B", auth: false}, }, results: []string{"A", "B"}, }, { // Votes from deauthorized signers are discarded immediately (auth votes) signers: []string{"A", "B", "C"}, blocks: []block{ {signer: "C", voted: "D", auth: true}, {signer: "A", voted: "C", auth: false}, {signer: "B", voted: "C", auth: false}, {signer: "A", voted: "D", auth: true}, }, results: []string{"A", "B"}, }, { // Cascading changes are not allowed, only the account being voted on may change signers: []string{"A", "B", "C", "D"}, blocks: []block{ {signer: "A", voted: "C", auth: false}, {signer: "B"}, {signer: "C"}, {signer: "A", voted: "D", auth: false}, {signer: "B", voted: "C", auth: false}, {signer: "C"}, {signer: "A"}, {signer: "B", voted: "D", auth: false}, {signer: "C", voted: "D", auth: false}, }, results: []string{"A", "B", "C"}, }, { // Changes reaching consensus out of bounds (via a deauth) execute on touch signers: []string{"A", "B", "C", "D"}, blocks: []block{ {signer: "A", voted: "C", auth: false}, {signer: "B"}, {signer: "C"}, {signer: "A", voted: "D", auth: false}, {signer: "B", voted: "C", auth: false}, {signer: "C"}, {signer: "A"}, {signer: "B", voted: "D", auth: false}, {signer: "C", voted: "D", auth: false}, {signer: "A"}, {signer: "C", voted: "C", auth: true}, }, results: []string{"A", "B"}, }, { // Changes reaching consensus out of bounds (via a deauth) may go out of consensus on first touch signers: []string{"A", "B", "C", "D"}, blocks: []block{ {signer: "A", voted: "C", auth: false}, {signer: "B"}, {signer: "C"}, {signer: "A", voted: "D", auth: false}, {signer: "B", voted: "C", auth: false}, {signer: "C"}, {signer: "A"}, {signer: "B", voted: "D", auth: false}, {signer: "C", voted: "D", auth: false}, {signer: "A"}, {signer: "B", voted: "C", auth: true}, }, results: []string{"A", "B", "C"}, }, { // Ensure that pending votes don't survive authorization status changes. This // corner case can only appear if a signer is quickly added, removed and then // readded (or the inverse), while one of the original voters dropped. If a // past vote is left cached in the system somewhere, this will interfere with // the final signer outcome. signers: []string{"A", "B", "C", "D", "E"}, blocks: []block{ {signer: "A", voted: "F", auth: true}, // Authorize F, 3 votes needed {signer: "B", voted: "F", auth: true}, {signer: "C", voted: "F", auth: true}, {signer: "D", voted: "F", auth: false}, // Deauthorize F, 4 votes needed (leave A's previous vote "unchanged") {signer: "E", voted: "F", auth: false}, {signer: "B", voted: "F", auth: false}, {signer: "C", voted: "F", auth: false}, {signer: "D", voted: "F", auth: true}, // Almost authorize F, 2/3 votes needed {signer: "E", voted: "F", auth: true}, {signer: "B", voted: "A", auth: false}, // Deauthorize A, 3 votes needed {signer: "C", voted: "A", auth: false}, {signer: "D", voted: "A", auth: false}, {signer: "B", voted: "F", auth: true}, // Finish authorizing F, 3/3 votes needed }, results: []string{"B", "C", "D", "E", "F"}, }, { // Epoch transitions reset all votes to allow chain checkpointing epoch: 3, signers: []string{"A", "B"}, blocks: []block{ {signer: "A", voted: "C", auth: true}, {signer: "B"}, {signer: "A", checkpoint: []string{"A", "B"}}, {signer: "B", voted: "C", auth: true}, }, results: []string{"A", "B"}, }, { // An unauthorized signer should not be able to sign blocks signers: []string{"A"}, blocks: []block{ {signer: "B"}, }, failure: errUnauthorizedSigner, }, { // An authorized signer that signed recently should not be able to sign again signers: []string{"A", "B"}, blocks: []block{ {signer: "A"}, {signer: "A"}, }, failure: errRecentlySigned, }, { // Recent signatures should not reset on checkpoint blocks imported in a batch epoch: 3, signers: []string{"A", "B", "C"}, blocks: []block{ {signer: "A"}, {signer: "B"}, {signer: "A", checkpoint: []string{"A", "B", "C"}}, {signer: "A"}, }, failure: errRecentlySigned, }, } ``` ## Implementation A reference implementation is part of [go-ethereum](https://github.com/ethereum/go-ethereum/tree/master/consensus/clique) and has been functioning as the consensus engine behind the [Rinkeby](https://www.rinkeby.io) testnet since April, 2017. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 06 Mar 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-225 https://eips.ethereum.org/EIPS/eip-225 Formal process of hard forks Meta/ https://ethereum-magicians.org/t/eip-233-formal-process-of-hard-forks/1387 ## Abstract To describe the formal process of preparing and activating hard forks. ## Motivation Today discussions about hard forks happen at various forums and sometimes in ad-hoc ways. ## Specification A Meta EIP should be created and merged as a *Draft* as soon as a new hard fork is planned. This EIP should contain: - the desired codename of the hard fork, - activation block number once decided - a timeline section - an EIPs to include section - the **Requires** header should point to the previous hard fork meta EIP. The draft shall be updated with summaries of the decisions around the hard fork. ### Timeline Once a timeline with key dates is agreed upon for other crucial dates. The basic outline of a hardfork timeline should include: * Hard deadline to accept proposals for this hard fork * Soft deadline for major client implementations * Projected date for testnet network upgrade * Projected date for mainnet upgrade (the activation block number / projected date for this block) ### EIP Inclusion Process Anyone that wishes to propose a Core EIP for the hard fork should make a PR against the Meta EIP representing the hard fork. The EIP must be published as at least `Draft`. It enters the _Proposed EIPs_ section, along with at least one person who is a point of contact for wanting to include the EIP. EIPs can move states by discussion done on the "[All Core Devs Meetings](https://github.com/ethereum/pm/)": - If accepted for a hard fork, the EIP should be moved to the _Accepted EIPs_ section. If the EIP has major client implementations and no security issues by the timeline date, it is scheduled for inclusion. - If rejected from a hard fork, the EIP should be moved to the _Rejected EIPs_ section. - Once the EIPs in the _Accepted EIPs_ section have successfully launched on a testnet roll out, they are moved to the _Included EIPs_ section. --- The Meta EIP representing the hard fork should move in to the `Accepted` state once the changes are frozen (i.e. all referenced EIPs are in the `Accepted` state) and in to the `Final` state once the hard fork has been activated. ## Template A template for the [Istanbul Hardfork Meta 1679](/EIPS/eip-1679) is included below ([source file on GitHub](/EIPS/eip-1679)): ``` {% raw %} --- eip: 1679 title: "Hardfork Meta: Istanbul" author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn) type: Meta status: Draft created: 2019-01-04 requires: 1716 --- ## Abstract This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul. ## Specification - Codename: Istanbul - Activation: TBD ### Included EIPs - TBD ### Accepted EIPs - TBD ### Rejected EIPs - TBD ### Proposed EIPs - TBD ## Timeline * 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul" * 2019-07-19 (Fri) soft deadline for major client implementations * 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet) * 2019-10-16 (Wed) projected date for mainnet upgrade ("Istanbul") ## References - TBD (e.g. link to Core Dev notes or other references) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). {% endraw %} ``` ## Rationale A meta EIP for coordinating the hard fork should help in visibility and traceability of the scope of changes as well as provide a simple name and/or number for referring to the proposed fork. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 23 Mar 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-233 https://eips.ethereum.org/EIPS/eip-233 Add `blockHash` to JSON-RPC filter options. Standards Track/Interface https://github.com/ethereum/EIPs/issues/234 ## Simple Summary Add an option to JSON-RPC filter options (used by `eth_newFilter` and `eth_getLogs`) that allows specifying the block hash that should be included in the results. This option would be an alternative to `fromBlock`/`toBlock` options. ## Abstract This addition would allow clients to fetch logs for specific blocks, whether those blocks were in the current main chain or not. This resolves some issues that make it difficult/expensive to author robust clients due to the nature of chain reorgs, unreliable network connections and the result set not containing enough details in the empty case. ## Specification The filter options used by `eth_newFilter` would have an additional optional parameter named `blockHash` whose value is a single block hash. The Ethereum node responding to the request would either send back an error if the block hash was not found or it would return the results matching the filter (per normal operation) constrained to the block provided. Internally, this would function (presumably) similar to the `fromBlock` and `toBlock` filter options. ## Rationale A client (dApp) who needs reliable notification of both log additions (on new blocks) and log removals (on chain reorgs) cannot achieve this while relying solely on subscriptions and filters. This is because a combination of a network or remote node failure during a reorg can result in the client getting out of sync with reality. An example of where this can happen with Websockets is when the client opens a web socket connection, sets up a log filter subscription, gets notified of some new logs, then loses the web socket connection, then (while disconnected) a re-org occurs, then the client connects back and establishes a new log filter. In this scenario they will not receive notification of the log removals from the node because they were disconnected when the removals were broadcast and the loss of their connection resulted in the node forgetting about their existence. A similar scenario can be concocted for HTTP clients where between polls for updates, the node goes down and comes back (resulting in loss of filter state) and a re-org also occurs between the same two polls. In order to deal with this while still providing a robust mechanism for internal block/log additional/removal, the client can maintain a blockchain internally (last `n` blocks) and only subscribe/poll for new blocks. When a new block is received, the client can reconcile their internal model with the new block, potentially back-filling parents or rolling back/removing blocks from their internal model to get in sync with the node. This can account for any type of disconnect/reorg/outage scenario and also allows the client (as an added benefit) to talk to a cluster of Ethereum nodes (e.g., via round-robin) rather than being tightly coupled to a single node. Once the user has a reliable stream of blocks, they can then look at the bloom filter for the new block and if the block *may* have logs of interest they can fetch the filtered logs for that block from the node. The problem that arises is that a re-org may occur between when the client receives the block and when the client fetches the logs for that block. Given the current set of filter options, the client can only ask for logs by block number. In this scenario, the logs they get back will be for a block that *isn't* the block they want the logs for and is instead for a block that was re-orged in (and may not be fully reconciled with the internal client state). This can be partially worked around by looking at the resulting logs themselves and identifying whether or not they are for the block hash requested. However, if the result set is an empty array (no logs fetched) then the client is in a situation where they don't know what block the results are for. The results could have been legitimately empty (bloom filter can yield false positives) for the block in question, or they could be receiving empty logs for a block that they don't know about. At this point, there is no decision the client can make that allows them a guarantee of recovery. They can assume the empty logs were for the correct block, but if they weren't then they will never try to fetch again. This creates a problem if the block was only transiently re-orged out because it may come back before the next block poll so the client will never witness the reorg. They can assume the empty logs were for the wrong block, and refetch them, but they may continue to get empty results putting them right back into the same situation. By adding the ability to fetch logs by hash, the client can be guaranteed that if they get a result set, it is for the block in question. If they get an error, then they can take appropriate action (e.g., rollback that block client-side and re-fetch latest). ## Backwards Compatibility The only potential issue here is the `fromBlock` and `toBlock` fields. It wouldn't make sense to include both the hash and the number so it seems like `fromBlock`/`toBlock` should be mutually exclusive with `blockHash`. ## Test Cases `{ "jsonrpc": "2.0", "id": 1, "method": "eth_getLogs", params: [{"blockHash": "0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c"}] }` should return all of the logs for the block with hash `0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c`. If a `topics` field is added to the filter options then a filtered set of logs for that block should be returned. If no block exists with that hash then an error should be returned with a `code` of `-32000`, a `message` of `"Block not found."` and a `data` of `"0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c"`. ## Implementation - [x] [Geth](https://github.com/ethereum/go-ethereum/pull/16734) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 24 Mar 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-234 https://eips.ethereum.org/EIPS/eip-234 Ethereum purpose allocation for Deterministic Wallets Standards Track/ERC https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 ## Abstract This EIP defines a logical hierarchy for deterministic wallets based on [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), the purpose scheme defined in [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) and [this proposed change to BIP43](https://github.com/bitcoin/bips/pull/523). This EIP is a particular application of BIP43. ## Motivation Because Ethereum is based on account balances rather than UTXO, the hierarchy defined by BIP44 is poorly suited. As a result, several competing derivation path strategies have sprung up for deterministic wallets, resulting in inter-client incompatibility. This BIP seeks to provide a path to standardise this in a fashion better suited to Ethereum's unique requirements. ## Specification We define the following 2 levels in BIP32 path: <pre> m / purpose' / subpurpose' / EIP' </pre> Apostrophe in the path indicates that BIP32 hardened derivation is used. Each level has a special meaning, described in the chapters below. ### Purpose Purpose is set to 43, as documented in [this proposed change to BIP43](https://github.com/bitcoin/bips/pull/523). The purpose field indicates that this path is for a non-bitcoin cryptocurrency. Hardened derivation is used at this level. ### Subpurpose Subpurpose is set to 60, the SLIP-44 code for Ethereum. Hardened derivation is used at this level. ### EIP EIP is set to the EIP number specifying the remainder of the BIP32 derivation path. This permits new Ethereum-focused applications of deterministic wallets without needing to interface with the BIP process. Hardened derivation is used at this level. ## Rationale The existing convention is to use the 'Ethereum' coin type, leading to paths starting with `m/44'/60'/*`. Because this still assumes a UTXO-based coin, we contend that this is a poor fit, resulting in standardisation, usability, and security compromises. As a result, we are making the above proposal to define an entirely new hierarchy for Ethereum-based chains. ## Backwards Compatibility The introduction of another derivation path requires existing software to add support for this scheme in addition to any existing schemes. Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption, and has the potential to improve matters significantly in the long run. ## Test Cases TBD ## Implementation None yet. ## References [This discussion on derivation paths](https://github.com/ethereum/EIPs/issues/84) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 13 Apr 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-600 https://eips.ethereum.org/EIPS/eip-600 Ethereum hierarchy for deterministic wallets Standards Track/ERC https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 ## Abstract This EIP defines a logical hierarchy for deterministic wallets based on [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), the purpose scheme defined in [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) and eip-draft-ethereum-purpose. This EIP is a particular application of eip-draft-ethereum-purpose. ## Motivation At present, different Ethereum clients and wallets use different derivation paths; a summary of them can be found [here](https://github.com/ethereum/EIPs/issues/84#issuecomment-292324521). Some of these paths violate BIP44, the standard defining derivation paths starting with `m/44'/`. This creates confusion and incompatibility between wallet implementations, in some cases making funds from one wallet inaccessible on another, and in others requiring prompting users manually for a derivation path, which hinders usability. Further, BIP44 was designed with UTXO-based blockchains in mind, and is a poor fit for Ethereum, which uses an accounts abstraction instead. As an alternative, we propose a deterministic wallet hierarchy better tailored to Ethereum's unique requirements. ## Specification We define the following 4 levels in BIP32 path: <pre> m / purpose' / subpurpose' / EIP' / wallet' </pre> Apostrophe in the path indicates that BIP32 hardened derivation is used. Each level has a special meaning, described in the chapters below. ### Purpose Purpose is a constant set to 43, indicating the key derivation is for a non-bitcoin cryptocurrency. Hardened derivation is used at this level. ### Subpurpose Subpurpose is set to 60, the SLIP-44 code for Ethereum. Hardened derivation is used at this level. ### EIP EIP is set to the EIP number specifying the remainder of the BIP32 derivation path. For paths following this EIP specification, the number assigned to this EIP is used. Hardened derivation is used at this level. ### Wallet This component of the path splits the wallet into different user identities, allowing a single wallet to have multiple public identities. Accounts are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. Hardened derivation is used at this level. Software should prevent a creation of an account if a previous account does not have a transaction history (meaning its address has not been used before). Software needs to discover all used accounts after importing the seed from an external source. ## Rationale The existing convention is to use the 'Ethereum' coin type, leading to paths starting with `m/44'/60'/*`. Because this still assumes a UTXO-based coin, we contend that this is a poor fit, resulting in standardisation, usability, and security compromises. As a result, we are making the above proposal to define an entirely new hierarchy for Ethereum-based chains. ## Backwards Compatibility The introduction of another derivation path requires existing software to add support for this scheme in addition to any existing schemes. Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption, and has the potential to improve matters significantly in the long run. For applications that utilise mnemonics, the authors expect to submit another EIP draft that describes a method for avoiding backwards compatibility concerns when transitioning to this new derivation path. ## Test Cases TBD ## Implementation None yet. ## References [This discussion on derivation paths](https://github.com/ethereum/EIPs/issues/84) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 13 Apr 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-601 https://eips.ethereum.org/EIPS/eip-601 Hardfork Meta: Homestead Meta/ ## Abstract This specifies the changes included in the hard fork named Homestead. ## Specification - Codename: Homestead - Activation: - Block >= 1,150,000 on Mainnet - Block >= 494,000 on Morden - Block >= 0 on future testnets - Included EIPs: - [EIP-2](/EIPS/eip-2) (Homestead Hard-fork Changes) - [EIP-7](/EIPS/eip-7) (DELEGATECALL) - [EIP-8](/EIPS/eip-8) (Networking layer: devp2p Forward Compatibility Requirements for Homestead) ## References 1. https://blog.ethereum.org/2016/02/29/homestead-release/ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 23 Apr 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-606 https://eips.ethereum.org/EIPS/eip-606 Hardfork Meta: Spurious Dragon Meta/ ## Abstract This specifies the changes included in the hard fork named Spurious Dragon. ## Specification - Codename: Spurious Dragon - Aliases: State-clearing - Activation: - Block >= 2,675,000 on Mainnet - Block >= 1,885,000 on Morden - Included EIPs: - [EIP-155](/EIPS/eip-155) (Simple replay attack protection) - [EIP-160](/EIPS/eip-160) (EXP cost increase) - [EIP-161](/EIPS/eip-161) (State trie clearing) - [EIP-170](/EIPS/eip-170) (Contract code size limit) ## References 1. https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 23 Apr 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-607 https://eips.ethereum.org/EIPS/eip-607 Hardfork Meta: Tangerine Whistle Meta/ ## Abstract This specifies the changes included in the hard fork named Tangerine Whistle (EIP 150). ## Specification - Codename: Tangerine Whistle - Aliases: EIP 150, Anti-DoS - Activation: - Block >= 2,463,000 on Mainnet - Included EIPs: - [EIP-150](/EIPS/eip-150) (Gas cost changes for IO-heavy operations) ## References 1. https://blog.ethereum.org/2016/10/13/announcement-imminent-hard-fork-eip150-gas-cost-changes/ 2. https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 23 Apr 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-608 https://eips.ethereum.org/EIPS/eip-608 Hardfork Meta: Byzantium Meta/ ## Abstract This specifies the changes included in the hard fork named Byzantium. ## Specification - Codename: Byzantium - Aliases: Metropolis/Byzantium, Metropolis part 1 - Activation: - Block >= 4,370,000 on Mainnet - Block >= 1,700,000 on Ropsten testnet - Included EIPs: - [EIP-100](/EIPS/eip-100) (Change difficulty adjustment to target mean block time including uncles) - [EIP-140](/EIPS/eip-140) (REVERT instruction in the Ethereum Virtual Machine) - [EIP-196](/EIPS/eip-196) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) - [EIP-197](/EIPS/eip-197) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) - [EIP-198](/EIPS/eip-198) (Precompiled contract for bigint modular exponentiation) - [EIP-211](/EIPS/eip-211) (New opcodes: RETURNDATASIZE and RETURNDATACOPY) - [EIP-214](/EIPS/eip-214) (New opcode STATICCALL) - [EIP-649](/EIPS/eip-649) (Difficulty Bomb Delay and Block Reward Reduction) - [EIP-658](/EIPS/eip-658) (Embedding transaction status code in receipts) ## References 1. https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 23 Apr 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-609 https://eips.ethereum.org/EIPS/eip-609 Subroutines and Static Jumps for the EVM Standards Track/Core https://ethereum-magicians.org/t/eip-615-subroutines-and-static-jumps-for-the-evm-last-call/3472 ## Simple Summary In the 21st century, on a blockchain circulating billions of ETH, formal specification and verification are an essential tool against loss. Yet the design of the EVM makes this unnecessarily difficult. Further, the design of the EVM makes near-linear-time compilation to machine code difficult. We propose to move forward with proposals to resolve these problems by tightening EVM security guarantees and reducing barriers to performance. ## Abstract EVM code is currently difficult to statically analyze, hobbling critical tools for preventing the many expensive bugs our blockchain has experienced. Further, none of the current implementations of the Ethereum Virtual Machine—including the compilers—are sufficiently performant to reduce the need for precompiles and otherwise meet the network's long-term demands. This proposal identifies dynamic jumps as a major reason for these issues, and proposes changes to the EVM specification to address the problem, making further efforts towards a safer and more performant the EVM possible. We also propose to validate—in near-linear time—that EVM contracts correctly use subroutines, avoid misuse of the stack, and meet other safety conditions _before_ placing them on the blockchain. Validated code precludes most runtime exceptions and the need to test for them. And well-behaved control flow and use of the stack makes life easier for interpreters, compilers, formal analysis, and other tools. ## Motivation Currently the EVM supports only dynamic jumps, where the address to jump to is an argument on the stack. Worse, the EVM fails to provide ordinary, alternative control flow facilities like subroutines and switches provided by Wasm and most CPUs. So dynamic jumps cannot be avoided, yet they obscure the structure of the code and thus mostly inhibit control- and data-flow analysis. This puts the quality and speed of optimized compilation fundamentally at odds. Further, since many jumps can potentially be to any jump destination in the code, the number of possible paths through the code can go up as the product of the number of jumps by the number of destinations, as does the time complexity of static analysis. Many of these cases are undecidable at deployment time, further inhibiting static and formal analyses. However, given Ethereum's security requirements, **near-linear** **`n log n`** **time complexity** is essential. Otherwise, Contracts can be crafted or discovered with quadratic complexity to use as denial of service attack vectors against validations and optimizations. But absent dynamic jumps code can be statically analyzed in linear time. That allows for _linear time validation_. It also allows for code generation and such optimizations as can be done in `log n` time to comprise an _`n log n`_ _time compiler_. And absent dynamic jumps, and with proper subroutines the EVM is a better target for code generation from other languages, including * Solidity * Vyper * LLVM IR * front ends include C, C++, Common Lisp, D, Fortran, Haskell, Java, Javascript, Kotlin, Lua, Objective-C, Pony, Pure, Python, Ruby, Rust, Scala, Scheme, and Swift The result is that all of the following validations and optimizations can be done at deployment time with near-linear `(n log n)` time complexity. * The absence of most exceptional halting states can be validated. * The maximum use of resources can be sometimes be calculated. * Bytecode can be compiled to machine code in near-linear time. * Compilation can more effectively optimize use of smaller registers. * Compilation can more effectively optimize injection of gas metering. ## Specification ### Dependencies > **[EIP-1702](/EIPS/eip-1702). Generalized Account Versioning Scheme.** This proposal needs a versioning scheme to allow for its bytecode (and eventually eWasm bytecode) to be deployed with existing bytecode on the same blockchain. ### Proposal We propose to deprecate two existing instructions—`JUMP` and `JUMPI`—and propose new instructions to support their legitimate uses. In particular, it must remain possible to compile Solidity and Vyper code to EVM bytecode, with no significant loss of performance or increase in gas price. Especially important is efficient translation to and from [eWasm](https://github.com/ewasm/design) and to machine code. To that end we maintain a close correspondence between [Wasm](https://webassembly.github.io/spec/core/_download/WebAssembly.pdf), [x86](https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf), [ARM](https://static.docs.arm.com/100076/0100/arm_instruction_set_reference_guide_100076_0100_00_en.pdf) and proposed EVM instructions. | EIP-615 | Wasm | x86 | ARM | --------- | ------------- | ---- | ---- | | JUMPTO | br | JMP | B | | JUMPIF | br_if | JE | BEQ | | JUMPV | br_table | JMP | TBH | | JUMPSUB | call | CALL | BL | | JUMPSUBV | call_indirect | CALL | BL | | RETURN | return | RET | RET | | GETLOCAL | local.get | POP | POP | | PUTLOCAL | local.put | PUSH | PUSH | | BEGINSUB | func | | | | BEGINDATA | tables | | | #### Preliminaries These forms > *`INSTRUCTION`* > > *`INSTRUCTION x`* > > *`INSTRUCTION x, y`* name an *`INSTRUCTION`* with no, one and two arguments, respectively. An instruction is represented in the bytecode as a single-byte opcode. Any arguments are laid out as immediate data bytes following the opcode inline, interpreted as fixed length, MSB-first, two's-complement, two-byte positive integers. (Negative values are reserved for extensions.) #### Branches and Subroutines The two most important uses of `JUMP` and `JUMPI` are static jumps and return jumps. Conditional and unconditional static jumps are the mainstay of control flow. Return jumps are implemented as a dynamic jump to a return address pushed on the stack. With the combination of a static jump and a dynamic return jump you can—and Solidity does—implement subroutines. The problem is that static analysis cannot tell the one place the return jump is going, so it must analyze every possibility (a heavy analysis). Static jumps are provided by > `JUMPTO jump_target` > > `JUMPIF jump_target` > > which are the same as `JUMP` and `JUMPI` except that they jump to an immediate `jump_target` rather than an address on the stack. To support subroutines, `BEGINSUB`, `JUMPSUB`, and `RETURNSUB` are provided. Brief descriptions follow, and full semantics are given below. > `BEGINSUB n_args, n_results` > > marks the **single** entry to a subroutine. `n_args` items are taken off of the stack at entry to, and `n_results` items are placed on the stack at return from the subroutine. The subroutine ends at the next `BEGINSUB` instruction (or `BEGINDATA`, below) or at the end of the bytecode. > `JUMPSUB jump_target` > > jumps to an immediate subroutine address. > `RETURNSUB` > >returns from the current subroutine to the instruction following the JUMPSUB that entered it. #### Switches, Callbacks, and Virtual Functions Dynamic jumps are also used for `O(1)` indirection: an address to jump to is selected to push on the stack and be jumped to. So we also propose two more instructions to provide for constrained indirection. We support these with vectors of `JUMPDEST` or `BEGINSUB` offsets stored inline, which can be selected with an index on the stack. That constrains validation to a specified subset of all possible destinations. The danger of quadratic blow up is avoided because it takes as much space to store the jump vectors as it does to code the worst case exploit. Dynamic jumps to a `JUMPDEST` are used to implement `O(1)` jumptables, which are useful for dense switch statements. Wasm and most CPUs provide similar instructions. > `JUMPV n, jump_targets` > > jumps to one of a vector of `n` `JUMPDEST` offsets via a zero-based index on the stack. The vector is stored inline at the `jump_targets` offset after the BEGINDATA bytecode as MSB-first, two's-complement, two-byte positive integers. If the index is greater than or equal to `n - 1` the last (default) offset is used. Dynamic jumps to a `BEGINSUB` are used to implement `O(1)` virtual functions and callbacks, which take at most two pointer dereferences on most CPUs. Wasm provides a similar instruction. > `JUMPSUBV n, jump_targets` > >jumps to one of a vector of `n` `BEGINSUB` offsets via a zero-based index on the stack. The vector is stored inline at the `jump_targets` offset after the DATA bytecode, as MSB-first, two's-complement, two-byte positive integers. If the index is greater than or equal to `n - 1` the last (default) offset is used. #### Variable Access These operations provide convenient access to subroutine parameters and local variables at fixed stack offsets within a subroutine. Otherwise only sixteen variables can be directly addressed. > `PUTLOCAL n` > > Pops the stack to the local variable `n`. > `GETLOCAL n` > > Pushes the local variable `n` onto the stack. Local variable `n` is the nth stack item below the frame pointer, `FP[-n]`, as defined below. #### Data There needs to be a way to place unreachable data into the bytecode that will be skipped over and not validated. Indirect jump vectors will not be valid code. Initialization code must create runtime code from data that might not be valid code. And unreachable data might prove useful to programs for other purposes. > `BEGINDATA` > > specifies that all of the following bytes to the end of the bytecode are data, and not reachable code. #### Structure Valid EIP-615 EVM bytecode begins with a valid header. This is the magic number ‘\0evm’ followed by the semantic versioning number '\1\5\0'. (For Wasm the header is '\0asm\1'). Following the header is the BEGINSUB opcode for the _main_ routine. It takes no arguments and returns no values. Other subroutines may follow the _main_ routine, and an optional BEGINDATA opcode may mark the start of a data section. ### Semantics Jumps to and returns from subroutines are described here in terms of * The EVM data stack, (as defined in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)) usually just called “the stack.” * A return stack of `JUMPSUB` and `JUMPSUBV` offsets. * A frame stack of frame pointers. We will adopt the following conventions to describe the machine state: * The _program counter_ `PC` is (as usual) the byte offset of the currently executing instruction. * The _stack pointer_ `SP` corresponds to the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)'s substate `s` of the machine state. * `SP[0]` is where a new item is can be pushed on the stack. * `SP[1]` is the first item on the stack, which can be popped off the stack. * The stack grows towards lower addresses. * The _frame pointer_ `FP` is set to `SP + n_args` at entry to the currently executing subroutine. * The _stack items_ between the frame pointer and the current stack pointer are called the _frame_. * The current number of items in the frame, `FP - SP`, is the _frame size_. > **Note**: Defining the frame pointer so as to include the arguments is unconventional, but better fits our stack semantics and simplifies the remainder of the proposal. The frame pointer and return stacks are internal to the subroutine mechanism, and not directly accessible to the program. This is necessary to prevent the program from modifying its own state in ways that could be invalid. Execution of EVM bytecode begins with the _main_ routine with no arguments, `SP` and `FP` set to 0, and with one value on the return stack—`code_size - 1`. (Executing the virtual byte of 0 after this offset causes an EVM to stop. Thus executing a `RETURNSUB` with no prior `JUMPSUB` or `JUMBSUBV`—that is, in the _main_ routine—executes a `STOP`.) Execution of a subroutine begins with `JUMPSUB` or `JUMPSUBV`, which * pushes `PC` on the return stack, * pushes `FP` on the frame stack * thus suspending execution of the current subroutine, * sets `FP` to `SP + n_args`, and * sets `PC` to the specified `BEGINSUB` address * thus beginning execution of the new subroutine. Execution of a subroutine is suspended during and resumed after execution of nested subroutines, and ends upon encountering a `RETURNSUB`, which * sets `FP` to the top of the virtual frame stack and pops the stack, * sets `SP` to `FP + n_results`, * sets `PC` to top of the return stack and pops the stack, and * advances `PC` to the next instruction thus resuming execution of the enclosing subroutine or _main_ routine. A `STOP` or `RETURN` also ends the execution of a subroutine. For example, starting from this stack, ``` _________________ | locals 20 <- FP frame | 21 ______|___________ 22 <- SP ``` and after pushing two arguments and branching with `JUMPSUB` to a `BEGINSUB 2, 3` ``` PUSH 10 PUSH 11 JUMPSUB beginsub ``` and initializing three local variables ``` PUSH 99 PUSH 98 PUSH 97 ``` the stack looks like this ``` 20 21 __________________ 22 | arguments 10 <- FP frame |___________ 11 | locals 99 | 98 ______|___________ 97 <- SP ``` After some amount of computation the stack could look like this ``` 20 21 __________________ 22 | returns 44 <- FP | 43 frame |___________ 42 | locals 13 ______|___________ 14 <- SP ``` and after `RETURNSUB` would look like this ``` _________________ | locals 20 <- FP | 21 frame |___________ 22 | returns 44 | 43 ______|___________ 42 <- SP ``` ### Validity We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state, but we must validate code in linear time. So our validation does not consider the code’s data and computations, only its control flow and stack use. This means we will reject programs with invalid code paths, even if those paths are not reachable. Most conditions can be validated, and will not need to be checked at runtime; the exceptions are sufficient gas and sufficient stack. As such, static analysis may yield false negatives belonging to well-understood classes of code requiring runtime checks. Aside from those cases, we can validate large classes at validation time and with linear complexity. _Execution_ is as defined in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)—a sequence of changes in the EVM state. The conditions on valid code are preserved by state changes. At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state. The Yellow Paper defines five such states. >**1** Insufficient gas >**2** More than 1024 stack items >**3** Insufficient stack items >**4** Invalid jump destination >**5** Invalid instruction We propose to expand and extend the Yellow Paper conditions to handle the new instructions we propose. To handle the return stack we expand the conditions on stack size: >**2a** The size of the data stack does not exceed 1024. >**2b** The size of the return stack does not exceed 1024. Given our more detailed description of the data stack we restate condition 3—stack underflow—as >**3** `SP` must be less than or equal to `FP` Since the various `DUP` and `SWAP` operations—as well as `PUTLOCAL` and `GETLOCAL`—are defined as taking items off the stack and putting them back on, this prevents them from accessing data below the frame pointer, since taking too many items off of the stack would mean that `SP` is less than `FP`. To handle the new jump instructions and subroutine boundaries, we expand the conditions on jumps and jump destinations. >**4a** `JUMPTO`, `JUMPIF`, and `JUMPV` address only `JUMPDEST` instructions. >**4b** `JUMPSUB` and `JUMPSUBV` address only `BEGINSUB` instructions. >**4c** `JUMP` instructions do not address instructions outside of the subroutine they occur in. We have two new conditions on execution to ensure consistent use of the stack by subroutines: >**6** For `JUMPSUB` and `JUMPSUBV` the frame size is at least the `n_args` of the `BEGINSUB`(s) to jump to. >**7** For `RETURNSUB` the frame size is equal to the `n_results` of the enclosing `BEGINSUB`. Finally, we have one condition that prevents pathological uses of the stack: >**8** For every instruction in the code the frame size is constant. In practice, we must test at runtime for conditions 1 and 2—sufficient gas and sufficient stack. We don’t know how much gas there will be, we don’t know how deep a recursion may go, and analysis of stack depth even for non-recursive programs is nontrivial. All of the remaining conditions we validate statically. #### Costs & Codes All of the instructions are `O(1)` with a small constant, requiring just a few machine operations each, whereas a `JUMP` or `JUMPI` typically does an `O(log n)` binary search of an array of `JUMPDEST` offsets before every jump. With the cost of `JUMPI` being _high_ and the cost of `JUMP` being _mid_, we suggest the cost of `JUMPV` and `JUMPSUBV` should be _mid_, `JUMPSUB` and `JUMPIF` should be _low_, and`JUMPTO` and the rest should be _verylow_. Measurement will tell. We suggest the following opcodes: ``` 0xb0 JUMPTO 0xb1 JUMPIF 0xb2 JUMPV 0xb3 JUMPSUB 0xb4 JUMPSUBV 0xb5 BEGINSUB 0xb6 BEGINDATA 0xb7 RETURNSUB 0xb8 PUTLOCAL 0xb9 GETLOCAL ``` ## Backwards Compatibility These changes would need to be implemented in phases at decent intervals: >**1.** If this EIP is accepted, invalid code should be deprecated. Tools should stop generating invalid code, users should stop writing it, and clients should warn about loading it. >**2.** A later hard fork would require clients to place only valid code on the block chain. Note that despite the fork old EVM code will still need to be supported indefinitely; older contracts will continue to run, and to create new contracts. If desired, the period of deprecation can be extended indefinitely by continuing to accept code not versioned as new—but without validation. That is, by delaying or canceling phase 2. Regardless, we will need a versioning scheme like [EIP-1702](/EIPS/eip-1702) to allow current code and EIP-615 code to coexist on the same blockchain. ## Rationale This design was highly constrained by the existing EVM semantics, the requirement for eWasm compatibility, and the security demands of the Ethereum environment. It was also informed by the lead author's previous work implementing Java and Scheme interpreters. As such there was very little room for alternative designs. As described above, the approach was simply to deprecate the problematic dynamic jumps, then ask what opcodes were necessary to provide for the features they supported. These needed to include those provided by eWasm, which themselves were modeled after typical hardware. The only real innovation was to move the frame pointer and the return pointer to their own stacks, so as to prevent any possibility of overwriting them. (Although Forth also uses a return stack.) This allowed for treating subroutine arguments as local variables, and facilitated the return of multiple values. ## Implementation Implementation of this proposal need not be difficult. At the least, interpreters can simply be extended with the new opcodes and run unchanged otherwise. The new opcodes require only stacks for the frame pointers and return offsets and the few pushes, pops, and assignments described above. The bulk of the effort is the validator, which in most languages can almost be transcribed from the pseudocode above. A lightly tested C++ reference implementation is available in [Greg Colvin's Aleth fork.](https://github.com/gcolvin/aleth/tree/master/libaleth-interpreter) This version required circa 110 lines of new interpreter code and a well-commented, 178-line validator. ## Appendix A ### Validation Validation comprises two tasks: * Check that jump destinations are correct and instructions valid. * Check that subroutines satisfy the conditions on control flow and stack use. We sketch out these two validation functions in pseudo-C below. To simplify the presentation only the five primitives are handled (`JUMPV` and `JUMPSUBV` would just add more complexity to loop over their vectors), we assume helper functions for extracting instruction arguments from immediate data and managing the stack pointer and program counter, and some optimizations are forgone. #### Validating Jumps Validating that jumps are to valid addresses takes two sequential passes over the bytecode—one to build sets of jump destinations and subroutine entry points, another to check that addresses jumped to are in the appropriate sets. ``` bytecode[code_size] // contains EVM bytecode to validate is_sub[code_size] // is there a BEGINSUB at PC? is_dest[code_size] // is there a JUMPDEST at PC? sub_for_pc[code_size] // which BEGINSUB is PC in? bool validate_jumps(PC) { current_sub = PC // build sets of BEGINSUBs and JUMPDESTs for (PC = 0; instruction = bytecode[PC]; PC = advance_pc(PC)) { if instruction is invalid return false if instruction is BEGINDATA break; if instruction is BEGINSUB is_sub[PC] = true current_sub = PC sub_for_pc[PC] = current_sub if instruction is JUMPDEST is_dest[PC] = true sub_for_pc[PC] = current_sub } // check that targets are in subroutine for (PC = 0; instruction = bytecode[PC]; PC = advance_pc(PC)) { if instruction is BEGINDATA break; if instruction is BEGINSUB current_sub = PC if instruction is JUMPSUB if is_sub[jump_target(PC)] is false return false if instruction is JUMPTO or JUMPIF if is_dest[jump_target(PC)] is false return false if sub_for_pc[PC] is not current_sub return false } return true } ``` Note that code like this is already run by EVMs to check dynamic jumps, including building the jump destination set every time a contract is run, and doing a lookup in the jump destination set before every jump. #### Subroutine Validation This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertices and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is `O(|E|+|V|)`: The sum of the number of edges and number of vertices in the graph. The basic approach is to call `validate_subroutine(i, 0, 0)`, for `i` equal to the first instruction in the EVM code through each `BEGINDATA` offset. `validate_subroutine()` traverses instructions sequentially, recursing when `JUMP` and `JUMPI` instructions are encountered. When a destination is reached that has been visited before it returns, thus breaking cycles. It returns true if the subroutine is valid, false otherwise. ``` bytecode[code_size] // contains EVM bytecode to validate frame_size[code_size ] // is filled with -1 // we validate each subroutine individually, as if at top level // * PC is the offset in the code to start validating at // * return_pc is the top PC on return stack that RETURNSUB returns to // * at top level FP = SP = 0 is both the frame size and the stack size // * as items are pushed SP get more negative, so the stack size is -SP validate_subroutine(PC, return_pc, SP) { // traverse code sequentially, recurse for jumps while true { instruction = bytecode[PC] // if frame size set we have been here before if frame_size[PC] >= 0 { // check for constant frame size if instruction is JUMPDEST if -SP != frame_size[PC] return false // return to break cycle return true } frame_size[PC] = -SP // effect of instruction on stack n_removed = removed_items(instructions) n_added = added_items(instruction) // check for stack underflow if -SP < n_removed return false // net effect of removing and adding stack items SP += n_removed SP -= n_added // check for stack overflow if -SP > 1024 return false if instruction is STOP, RETURN, or SUICIDE return true // violates single entry if instruction is BEGINSUB return false // return to top or from recursion to JUMPSUB if instruction is RETURNSUB return true;; if instruction is JUMPSUB { // check for enough arguments sub_pc = jump_target(PC) if -SP < n_args(sub_pc) return false return true } // reset PC to destination of jump if instruction is JUMPTO { PC = jump_target(PC) continue } // recurse to jump to code to validate if instruction is JUMPIF { if not validate_subroutine(jump_target(PC), return_pc, SP) return false } // advance PC according to instruction PC = advance_pc(PC) } // check for right number of results if (-SP != n_results(return_pc) return false return true } ``` ## Appendix B ### EVM Analysis There is a large and growing ecosystem of researchers, authors, teachers, auditors, and analytic tools--providing software and services focused on the correctness and security of EVM code. A small sample is given here. #### Some Tools * [Contract Library](https://contract-library.com/) * [EthereumJ](https://github.com/ethereum/ethereumj) * [Exthereum](https://github.com/exthereum/blockchain) * [Harmony](https://github.com/ether-camp/ethereum-harmony) * [JEB](https://www.pnfsoftware.com/blog/ethereum-smart-contract-decompiler/) * [Mythril](https://github.com/ConsenSys/mythril) * [Securify](https://github.com/eth-sri/securify) * [Skale](https://www.skalelabs.com/) * [Status](https://status.im/) #### Some Papers * [A Formal Verification Tool for Ethereum VM Bytecode](https://www.google.com/url?q=http://fsl.cs.illinois.edu/FSL/papers/2018/park-zhang-saxena-daian-rosu-2018-fse/park-zhang-saxena-daian-rosu-2018-fse-public.pdf) * [A Lem formalization of EVM and some Isabelle/HOL proofs](https://github.com/pirapira/eth-isabelle) * [A survey of attacks on Ethereum smart contracts](https://eprint.iacr.org/2016/1007.pdf) * [Defining the Ethereum Virtual Machine for Interactive Theorem Provers](https://www.google.com/url?q=http://fc17.ifca.ai/wtsc/Defining%2520the%2520Ethereum%2520Virtual%2520Machine%2520for%2520Interactive%2520Theorem%2520Provers.pdf) * [Ethereum 2.0 Specifications](https://github.com/ethereum/eth2.0-specs) * [Formal Verification of Smart Contracts](https://www.cs.umd.edu/~aseem/solidetherplas.pdf) * [JelloPaper: Human Readable Semantics of EVM in K](https://jellopaper.org/) * [KEVM: A Complete Semantics of the Ethereum Virtual Machine.](https://www.ideals.illinois.edu/items/102260) * [Making Smart Contracts Smarter](https://eprint.iacr.org/2016/633.pdf) * [Securify: Practical Security Analysis of Smart Contracts](https://arxiv.org/pdf/1806.01143.pdf) * [The Thunder Protocol](https://docs.thundercore.com/thunder-whitepaper.pdf) * [Towards Verifying Ethereum Smart Contract Bytecode in Isabelle/HOL](https://trustworthy.systems/publications/full_text/Amani_BBS_18.pdf) *[A Lem formalization of EVM 1.5](https://github.com/seed/eth-isabelle/tree/evm15) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 10 Dec 2016 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-615 https://eips.ethereum.org/EIPS/eip-615 SIMD Operations for the EVM Standards Track/Core ## ABSTRACT A proposal to provide Single Instruction Multiple Data types and operations for the Ethereum Virtual Machine, making full use of the 256-bit wide EVM stack items, and offering substantial performance gains for both vector and scalar operations. ## MOTIVATION Most all modern CPUs include SIMD hardware that operates on wide registers of data, applying a Single Instruction to Multiple Data lanes in parallel, where lanes divide a register into a vector of scalar elements of equal size. This model is an excellent fit for the wide stack items of the EVM, offering substantial performance boosts for operations that can be expressed as parallel operations on vectors of scalars. For some examples, a brief literature search finds SIMD speedups of * up to 7X for [SHA-512](http://keccak.noekeon.org/sw_performance.html) * 4X for [elliptic curve scalar multiplication](https://link.springer.com/chapter/10.1007/3-540-45439-X_16) * 3X to 4X for [BLAKE2b](https://github.com/minio/blake2b-simd) * up to 3X for [OpenSSL](https://software.intel.com/en-us/articles/improving-openssl-performance) * 2X to 3X for [elliptic curve modular multiplication](http://ieee-hpec.org/2013/index_htm_files/24-Simd-acceleration-Pabbuleti-2886999.pdf) * 1.7X to 1.9X for [SHA-256](https://github.com/minio/sha256-simd) * 1.3X for [RSA encryption](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.738.1218&rep=rep1&type=pdf) ## SPECIFICATION ### Encoding We propose a simple encoding of SIMD operations as extended two-byte codes. The first byte is the opcode, and the second byte is the SIMD type: scalar type, lane width, and number of elements. N bits | Field -|- 8 | opcode 1 | scalar type: 0 = unsigned integer, 1 = IEEE float 1 | reserved: 0 2 | lane width: log base 2 of the number of bytes, as an MSB first integer 1 | reserved: 0 3 | element count: log base 2 of the number of lanes, as an MSB first integer Thus we can specify SIMD types with unsigned integer lanes from 8 to 64 bits in vectors of 32 to 2 lanes, respectively. Floating point lanes however support only 32- and 64-bit IEEE floating point. And a type of _0x7F_ represents a normal 256-bit EVM integer. _Note that when the element count is one the operation is on one scalar, so this specification also provides for native operations on single scalars of native sizes._ _Note that floating point operations are **not** proposed for inclusion in the initial release, but we considered it important to reserve code space for possible future expansion._ ### Semantics We define the following extended versions of the EVM's arithmetic, logic, and comparison operations. As with the normal versions, they consume their arguments from the stack and place their results on the stack, except that their arguments are vectors rather than scalars. lo\hi | B | C -|-|- 0| | XLT 1| XADD | XGT 2| XMUL | XSLT 3| XSUB | XSGT 4| XDIV | XEQ 5| XSDIV | XISZERO 6| XMOD | XAND 7| XSMOD | XOR 8| | XXOR 9| | XNOT A| | XINDEX B| | XSHL C| | XSHR D| | XSAR E| XCAST | XROL F| XSHUFFLE | XROR Except for XSHUFFLE, XCAST, and XINDEX all the extended operations on unsigned integer values have the same semantics as the corresponding operations for codes 01 through 1F, except that the modulus varies by scalar type and the operations are applied pair-wise to the elements of the source operands to compute the destination elements. _The source operands must have the same element type and number of elements._ E.g. ``` PUSH uint8[1, 2, 3] PUSH uint8[4, 5, 6] XADD ``` leaves ``` uint8[5, 7, 9] ``` on the stack. XSHUFFLE takes two vectors on the stack: a vector to permute and a permutation mask. E.g. ``` PUSH uint64[4, 5, 6, 0] PUSH uint8[2, 0, 1, 3] SHUFFLE ``` leaves ``` uint64[6, 4, 5 , 0] ``` on the stack. The mask must have integral type, and the same number of elements as the source vector. The second byte of the XCAST opcode is applied to the item on the stack to create a new vector of the specified type. Elements are converted according to the usual C conventions, missing elements are set to zero, and extra elements are discarded. If the stack item is not a vector it is converted to a vector by taking its bits least-significant-bit first and copying them into the corresponding bits of each element, least-significant-element first. Again, excess data is truncated and missing data is 0-filled. Vectors are converted to 256-bit EVM integers via the reverse process., with elements that are floating point NANs normalized to all bits on. _Note that MLOAD and MSTORE are valid only on 256-bit EVM integers. For SIMD vectors an XCAST is needed after a load and before a store to convert vectors to and from 256-bit integers._ XINDEX has the same semantics as BYTE, except that individual elements of the vector are indexed. Floating point values follow IEEE 754 semantics. Since those are not defined for shifting and rotating those operations are defined here as having no effect. Extended operations other than XSHUFFLE and XCAST are only valid on vectors of the same SIMD type. This can be validated at contract creation time, or else checked at runtime. ### Subroutines If [EIP-187](https://github.com/ethereum/EIPs/pull/187) is accepted a type-safe syntax for declaring subroutines taking vector arguments will be needed. * `BEGINSUBX n_args, arg_types... n_results, result_types...` marks the **single** entry to a subroutine. `n_args` items are taken off of the stack at entry to, and `n_results` items are placed on the stack at return from the subroutine. `n_args` and `n_results` are given as one immediate byte each. The `arg_types` and `result_types` are given in the same encoding as second byte of the SIMD opcodes, and must match the values on the stack. The bytecode for a subroutine ends at the next `BEGINSUB`, `BEGINSUBX` or `BEGINDATA` instruction or at the end of the bytecode. ## RATIONALE Currently, the lowest common denominator for SIMD hardware (e.g. Intel SSE2 and ARM Neon) is 16-byte registers supporting integer lanes of 1, 2, 4, and 8 bytes, and floating point lanes of 4 and 8 bytes. More recent SIMD hardware (e.g. Intel AVX) supports 32-byte registers, and EVM stack items are also 32 bytes wide. The limits above derive from these numbers, assuring that EVM code is within the bounds of available hardware - and the reserved bits provide room for growth. For most modern languages (including Rust, Python, Go, Java, and C++) compilers can do a good job of generating SIMD code for parallelizable loops, and/or there are intrinsics or libraries available for explicit access to SIMD hardware. So a portable software implementation will likely provide good use of the hardware on most platforms, and intrinsics or libraries can be used as available and needed. Thus we can expect these operations to take about the same (or for 256-bit vectors on 128-bit hardware up to twice) the time to execute regardless of element size or number of elements. ### Gas One motivation for these operations, besides taking full advantage of the hardware, is assigning lower gas costs for operations on smaller scalars. On a machine with 64-bit registers the standard algorithms from Knuth's [Art of Computer Programming](https://library.aceondo.net/ebooks/Computer_Science/algorithm-the_art_of_computer_programming-knuth.pdf) require 32-bit digits, using the upper half of a register for overflows, so for 256-bit values N=8 digits are needed, and for 64-bit values N=2 digits are needed. The cycle counts for these algorithms are: operation | cycles | N = 2 | N = 4 | N = 8 -|-|-|-|- add | 10 _N_ + 6 | 26 | 46 | 86 subtract | 12 _N_ + 3 |27 | 51 | 99 multiply | 28 _N_**2 + 11 _N_ + 3 | 137 | 495 |1883 divide | 15 _N_**2 + 119 _N_ + 111 | 409 | 827 | 2023 The remaining operations are of about the same complexity as addition and subtraction, or less. Given that JUMPDEST is a no-op, and is assigned a gas price of 1, this can be taken as the overhead of the interpreter. All of the arithmetic operations are assigned the same gas price of 5, for a remaining runtime of 4. The interpreter loop itself takes about 6 to 8 C instructions, so ADD and SUB are reasonably priced, but MUL is some 5 to 21 times slower than ADD or SUB, and DIV is some 15 to 23 times slower, so they are clearly mispriced. By comparison, on most [Intel](https://software.intel.com/sites/landingpage/IntrinsicsGuide) and [ARM](https://developer.arm.com/docs/100166/latest/programmers-model/instruction-set-summary/table-of-processor-instructions) SIMD units instructions take approximately the following cycle counts, independent of register width. operation | Intel cycles | ARM cycles | gas -|-|-|- add | .5 | 1 | 1 subtract | .5 | 1 | 1 multiply | 2 | 1 | 1 divide | 10 | 12 | 2 Since all but the divide operation take fewer cycles than the interpreter overhead they are assigned the minimal cost of 1. Division takes slightly more, and is assigned a cost of 2. Tue, 25 Apr 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-616 https://eips.ethereum.org/EIPS/eip-616 Whisper Specification Standards Track/Networking ## Abstract This EIP describes the format of Whisper messages within the ÐΞVp2p Wire Protocol. This EIP should substitute the [existing specification](https://github.com/ethereum/wiki/wiki/Whisper-Wire-Protocol). More detailed documentation on Whisper could be found [here](https://github.com/ethereum/go-ethereum/wiki/Whisper). ## Motivation It is necessary to specify the standard for Whisper messages in order to ensure forward compatibility of different Whisper clients. ## Specification All Whisper messages sent as ÐΞVp2p Wire Protocol packets should be RLP-encoded arrays of data containing two objects: integer packet code followed by another object (whose type depends on the packet code). If Whisper node does not support a particular packet code, it should just ignore the packet without generating any error. ### Packet Codes The message codes reserved for Whisper protocol: 0 - 127. Messages with unknown codes must be ignored, for forward compatibility of future versions. The Whisper sub-protocol should support the following packet codes: | EIP | Name | Int Value | |-------|----------------------------|-----------| | | Status | 0 | | | Messages | 1 | | | PoW Requirement | 2 | | | Bloom Filter | 3 | |-------|----------------------------|-----------| The following message codes are optional, but they are reserved for specific purpose. | EIP | Name | Int Value | |-------|----------------------------|-----------| | | P2P Request | 126 | | | P2P Message | 127 | |-------|----------------------------|-----------| ### Packet Format and Usage **Status** [`0`] This packet contains two objects: integer message code (0x00) followed by a list of values: integer version, float PoW requirement, and bloom filter, in this order. The bloom filter parameter is optional; if it is missing or nil, the node is considered to be full node (i.e. accepts all messages). The format of PoW and bloom filter please see below (message codes 2 and 3). Status message should be sent after the initial handshake and prior to any other messages. **Messages** [`1`, `whisper_envelopes`] This packet contains two objects: integer message code (0x01) followed by a list (possibly empty) of Whisper Envelopes. This packet is used for sending the standard Whisper envelopes. **PoW Requirement** [`2`, `PoW`] This packet contains two objects: integer message code (0x02) followed by a single floating point value of PoW. This value is the IEEE 754 binary representation of 64-bit floating point number. Values of qNAN, sNAN, INF and -INF are not allowed. Negative values are also not allowed. This packet is used by Whisper nodes for dynamic adjustment of their individual PoW requirements. Recipient of this message should no longer deliver the sender messages with PoW lower than specified in this message. PoW is defined as average number of iterations, required to find the current BestBit (the number of leading zero bits in the hash), divided by message size and TTL: PoW = (2**BestBit) / (size * TTL) PoW calculation: fn short_rlp(envelope) = rlp of envelope, excluding env_nonce field. fn pow_hash(envelope, env_nonce) = sha3(short_rlp(envelope) ++ env_nonce) fn pow(pow_hash, size, ttl) = 2**leading_zeros(pow_hash) / (size * ttl) where size is the size of the full RLP-encoded envelope. **Bloom Filter** [`3`, `bytes`] This packet contains two objects: integer message code (0x03) followed by a byte array of arbitrary size. This packet is used by Whisper nodes for sharing their interest in messages with specific topics. The Bloom filter is used to identify a number of topics to a peer without compromising (too much) privacy over precisely what topics are of interest. Precise control over the information content (and thus efficiency of the filter) may be maintained through the addition of bits. Blooms are formed by the bitwise OR operation on a number of bloomed topics. The bloom function takes the topic and projects them onto a 512-bit slice. At most, three bits are marked for each bloomed topic. The projection function is defined as a mapping from a 4-byte slice S to a 512-bit slice D; for ease of explanation, S will dereference to bytes, whereas D will dereference to bits. LET D[*] = 0 FOREACH i IN { 0, 1, 2 } DO LET n = S[i] IF S[3] & (2 ** i) THEN n += 256 D[n] = 1 END FOR OPTIONAL **P2P Request** [`126`, `whisper_envelope`] This packet contains two objects: integer message code (0x7E) followed by a single Whisper Envelope. This packet is used for sending Dapp-level peer-to-peer requests, e.g. Whisper Mail Client requesting old messages from the Whisper Mail Server. **P2P Message** [`127`, `whisper_envelope`] This packet contains two objects: integer message code (0x7F) followed by a single Whisper Envelope. This packet is used for sending the peer-to-peer messages, which are not supposed to be forwarded any further. E.g. it might be used by the Whisper Mail Server for delivery of old (expired) messages, which is otherwise not allowed. ### Whisper Envelope Envelopes are RLP-encoded structures of the following format: [ Expiry, TTL, Topic, Data, Nonce ] `Expiry`: 4 bytes (UNIX time in seconds). `TTL`: 4 bytes (time-to-live in seconds). `Topic`: 4 bytes of arbitrary data. `Data`: byte array of arbitrary size (contains encrypted message). `Nonce`: 8 bytes of arbitrary data (used for PoW calculation). ### Contents of Data Field of the Message (Optional) This section outlines the optional description of Data Field to set up an example. Later it may be moved to a separate EIP. It is only relevant if you want to decrypt the incoming message, but if you only want to send a message, any other format would be perfectly valid and must be forwarded to the peers. Data field contains encrypted message of the Envelope. In case of symmetric encryption, it also contains appended Salt (a.k.a. AES Nonce, 12 bytes). Plaintext (unencrypted) payload consists of the following concatenated fields: flags, auxiliary field, payload, padding and signature (in this sequence). flags: 1 byte; first two bits contain the size of auxiliary field, third bit indicates whether the signature is present. auxiliary field: up to 4 bytes; contains the size of payload. payload: byte array of arbitrary size (may be zero). padding: byte array of arbitrary size (may be zero). signature: 65 bytes, if present. salt: 12 bytes, if present (in case of symmetric encryption). Those unable to decrypt the message data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialised as the concatenation of the `R`, `S` and `V` parameters of the SECP-256k1 ECDSA signature, in that order. `R` and `S` are both big-endian encoded, fixed-width 256-bit unsigned. `V` is an 8-bit big-endian encoded, non-normalised and should be either 27 or 28. The padding field was introduced in order to align the message size, since message size alone might reveal important metainformation. Padding can be arbitrary size. However, it is recommended that the size of Data Field (excluding the Salt) before encryption (i.e. plain text) should be factor of 256 bytes. ### Payload Encryption Asymmetric encryption uses the standard Elliptic Curve Integrated Encryption Scheme with SECP-256k1 public key. Symmetric encryption uses AES GCM algorithm with random 96-bit nonce. ## Rationale Packet codes 0x00 and 0x01 are already used in all Whisper versions. Packet code 0x02 will be necessary for the future development of Whisper. It will provide possibility to adjust the PoW requirement in real time. It is better to allow the network to govern itself, rather than hardcode any specific value for minimal PoW requirement. Packet code 0x03 will be necessary for scalability of the network. In case of too much traffic, the nodes will be able to request and receive only the messages they are interested in. Packet codes 0x7E and 0x7F may be used to implement Whisper Mail Server and Client. Without P2P messages it would be impossible to deliver the old messages, since they will be recognized as expired, and the peer will be disconnected for violating the Whisper protocol. They might be useful for other purposes when it is not possible to spend time on PoW, e.g. if a stock exchange will want to provide live feed about the latest trades. ## Backwards Compatibility This EIP is compatible with Whisper version 6. Any client which does not implement certain packet codes should gracefully ignore the packets with those codes. This will ensure the forward compatibility. ## Implementation The golang implementation of Whisper (v.6) already uses packet codes 0x00 - 0x03. Parity's implementation of v.6 will also use codes 0x00 - 0x03. Codes 0x7E and 0x7F are reserved, but still unused and left for custom implementation of Whisper Mail Server. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 05 May 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-627 https://eips.ethereum.org/EIPS/eip-627 Storage of text records in ENS Standards Track/ERC https://github.com/ethereum/EIPs/issues/2439 ## Abstract This EIP defines a resolver profile for ENS that permits the lookup of arbitrary key-value text data. This allows ENS name holders to associate e-mail addresses, URLs and other informational data with a ENS name. ## Motivation There is often a desire for human-readable metadata to be associated with otherwise machine-driven data; used for debugging, maintenance, reporting and general information. In this EIP we define a simple resolver profile for ENS that permits ENS names to associate arbitrary key-value text. ## Specification ### Resolver Profile A new resolver interface is defined, consisting of the following method: ```solidity interface IERC634 { /// @notice Returns the text data associated with a key for an ENS name /// @param node A nodehash for an ENS name /// @param key A key to lookup text data for /// @return The text data function text(bytes32 node, string key) view returns (string text); } ``` The [EIP-165](/EIPS/eip-165) interface ID of this interface is `0x59d1d43c`. The `text` data may be any arbitrary UTF-8 string. If the key is not present, the empty string must be returned. ### Global Keys Global Keys must be made up of lowercase letters, numbers and the hyphen (-). - **avatar** - a URL to an image used as an avatar or logo - **description** - A description of the name - **display** - a canonical display name for the ENS name; this MUST match the ENS name when its case is folded, and clients should ignore this value if it does not (e.g. `"ricmoo.eth"` could set this to `"RicMoo.eth"`) - **email** - an e-mail address - **keywords** - A list of comma-separated keywords, ordered by most significant first; clients that interpresent this field may choose a threshold beyond which to ignore - **mail** - A physical mailing address - **notice** - A notice regarding this name - **location** - A generic location (e.g. `"Toronto, Canada"`) - **phone** - A phone number as an E.164 string - **url** - a website URL ### Service Keys Service Keys must be made up of a *reverse dot notation* for a namespace which the service owns, for example, DNS names (e.g. `.com`, `.io`, etc) or ENS name (i.e. `.eth`). Service Keys must contain at least one dot. This allows new services to start using their own keys without worrying about colliding with existing services and also means new services do not need to update this document. The following services are common, which is why recommendations are provided here, but ideally a service would declare its own key. - **com.github** - a GitHub username - **com.peepeth** - a Peepeth username - **com.linkedin** - a LinkedIn username - **com.twitter** - a Twitter username - **io.keybase** - a Keybase username - **org.telegram** - a Telegram username This technique also allows for a service owner to specify a hierarchy for their keys, such as: - **com.example.users** - **com.example.groups** - **com.example.groups.public** - **com.example.groups.private** ### Legacy Keys The following keys were specified in earlier versions of this EIP, which is still in draft. Their use is not likely very wide, but applications attempting maximal compatibility may wish to query these keys as a fallback if the above replacement keys fail. - **vnd.github** - a GitHub username (renamed to `com.github`) - **vnd.peepeth** - a peepeth username (renamced to `com.peepeth`) - **vnd.twitter** - a twitter username (renamed to `com.twitter`) ## Rationale ### Application-specific vs general-purpose record types Rather than define a large number of specific record types (each for generally human-readable data) such as `url` and `email`, we follow an adapted model of DNS's `TXT` records, which allow for a general keys and values, allowing future extension without adjusting the resolver, while allowing applications to use custom keys for their own purposes. ## Backwards Compatibility Not applicable. ## Security Considerations None. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 17 May 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-634 https://eips.ethereum.org/EIPS/eip-634 Metropolis Difficulty Bomb Delay and Block Reward Reduction Standards Track/Core https://github.com/ethereum/EIPs/issues/649 ## Simple Summary The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately one and a half year and to reduce the block rewards with the Byzantium fork, the first part of the Metropolis fork. ## Abstract Starting with `BYZANTIUM_FORK_BLKNUM` the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 3 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 3 ETH, uncle and nephew rewards will be adjusted accordingly. ## Motivation The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another one and a half years. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake. ## Specification #### Relax Difficulty with Fake Block Number For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: fake_block_number = max(0, block.number - 3_000_000) if block.number >= BYZANTIUM_FORK_BLKNUM else block.number #### Adjust Block, Uncle, and Nephew rewards To ensure a constant Ether issuance, adjust the block reward to `new_block_reward`, where new_block_reward = 3_000_000_000_000_000_000 if block.number >= BYZANTIUM_FORK_BLKNUM else block.reward (3E18 wei, or 3,000,000,000,000,000,000 wei, or 3 ETH). Analogue, if an uncle is included in a block for `block.number >= BYZANTIUM_FORK_BLKNUM` such that `block.number - uncle.number = k`, the uncle reward is new_uncle_reward = (8 - k) * new_block_reward / 8 This is the existing pre-Metropolis formula for uncle rewards, simply adjusted with `new_block_reward`. The nephew reward for `block.number >= BYZANTIUM_FORK_BLKNUM` is new_nephew_reward = new_block_reward / 32 This is the existing pre-Metropolis formula for nephew rewards, simply adjusted with `new_block_reward`. ## Rationale This will delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times at the end of 2018. An alternate proposal was to add special rules to the difficulty calculation to effectively _pause_ the difficulty between different blocks. This would lead to similar results. This was previously discussed at All Core Devs Meeting [#09](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%209.md#metropolis-timing-and-roadmap-discussion), [#12](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2012.md#5-metropolis-update), [#13](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2013.md#3-eip-186-reduce-eth-issuance-before-proof-of-stake-hudson), and [#14](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2014.md#1-eip-186-reduce-eth-issuance-before-proof-of-stake-core-devs). Consensus on the specification was achieved in All Core Devs Meeting [#19](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2019.md) and specification drafted in EIP issue [#649](https://github.com/ethereum/EIPs/issues/649). It was decided to replace EIP [#186](https://github.com/ethereum/EIPs/issues/186) and include the block reward reduction along with the difficulty bomb delay in All Core Devs Meeting [#20](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2020.md) and [#21](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2021.md); accepted in [#22](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2022.md). ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the first of the two Metropolis hard-forks, the _Byzantium_ fork. ## Test Cases Test cases exist in ethereum/tests [#269](https://github.com/ethereum/tests/pull/269). ## Implementation The following clients implemented EIP-649: - Geth [#15028](https://github.com/ethereum/go-ethereum/pull/15028) - Parity [#5855](https://github.com/paritytech/parity/pull/5855) - EthereumJ [#927](https://github.com/ethereum/ethereumj/pull/927) - Cpp-Ethereum [#4050](https://github.com/ethereum/cpp-ethereum/issues/4050) - PyEthereum [#383](https://github.com/ethereum/pyethereum/pull/383) The Yellow Paper implements EIP-649 in [#333](https://github.com/ethereum/yellowpaper/pull/333). Other notable implementations: - Eth-Isabelle [#459](https://github.com/pirapira/eth-isabelle/issues/459) - Py-EVM [#123](https://github.com/ethereum/py-evm/pull/123) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 21 Jun 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-649 https://eips.ethereum.org/EIPS/eip-649 Embedding transaction status code in receipts Standards Track/Core ## Abstract This EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed. ## Motivation With the introduction of the REVERT opcode in EIP140, it is no longer possible for users to assume that a transaction failed iff it consumed all gas. As a result, there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied. Full nodes can provide RPCs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical. Instead, we propose to replace the intermediate state root, already obsoleted by EIP98, with the return status (1 for success, 0 for failure). This both allows callers to determine success status, and remedies the previous omission of return data from the receipt. ## Specification For blocks where block.number >= BYZANTIUM_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success. ## Rationale This constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for Metropolis. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 30 Jun 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-658 https://eips.ethereum.org/EIPS/eip-658 SWAPN, DUPN and EXCHANGE instructions Standards Track/Core https://ethereum-magicians.org/t/eip-663-unlimited-swap-and-dup-instructions/3346 ## Abstract Currently, `SWAP*` and `DUP*` instructions are limited to a stack depth of 16. Introduce three new instructions, `SWAPN`, `DUPN` and `EXCHANGE` which lift this limitation and allow accessing the stack at higher depths. ## Motivation While the stack is 1024 items deep, easy access is only possible for the top 16 items. Supporting more local variables is possible via manually keeping them in memory or through a "stack to memory elevation" in a compiler. This can result in complex and inefficient code. Furthermore, implementing higher level constructs, such as functions, on top of EVM will result in a list of input and output parameters as well as an instruction offset to return to. The number of these arguments (or stack items) can easily exceed 16 and thus will require extra care from a compiler to lay them out in a way that all of them are still accessible. Lastly, swapping items besides the 1st and Nth items in the stack is very important for compilers implementing stack scheduling algorithms (the analog of register allocation for stack machines), which try to minimize stack traffic given a set of variables and usage analysis. Introducing `SWAPN`, `DUPN` and `EXCHANGE` will provide an option to compilers to simplify accessing deep stack items. ## Specification We introduce three new instructions: 1. `DUPN` (`0xe6`) 2. `SWAPN` (`0xe7`) 3. `EXCHANGE` (`0xe8`) If the code is legacy bytecode, any of these instructions result in an *exceptional halt*. (*Note: This means no change to behaviour.*) If the code is valid EOF1, the following rules apply: 1. The instructions are followed by an 8-bit immediate value, which we call `imm`, and can have a value of 0 to 255. 1. In the case of `DUPN` and `SWAPN`, we introduce the variable `n` which equals to `imm + 1`. 2. In the case of `EXCHANGE`, we introduce the variable `n` which is equal to `(imm >> 4) + 1`, and the variable `m` which is equal to `(imm & 0x0F) + 1` (i.e., the first and second nibbles of `imm`, converted to one-indexing). 2. Code validation is extended to check that no relative jump instruction (`RJUMP`/`RJUMPI`/`RJUMPV`) targets immediate values of `DUPN`, `SWAPN` or `EXCHANGE`. 3. The stack validation algorithm of [EIP-5450](/EIPS/eip-5450) is extended: 1. Before `DUPN` if the current stack height is less than `n`, code is invalid. After `DUPN`, the stack height is incremented. 2. Before `SWAPN` if the current stack height is less than `n + 1`, code is invalid. After `SWAPN`, the stack height is unchanged. 3. Before `EXCHANGE` if the current stack height is less than `n + m + 1`, code is invalid. After `EXCHANGE`, the stack height is unchanged. 4. Execution rules: 1. `DUPN`: the `n`'th stack item is duplicated at the top of the stack. (*Note: We use 1-based indexing here.*) 2. `SWAPN`: the `n + 1`'th stack item is swapped with the top of the stack. 3. `EXCHANGE`: the `n + 1`'th stack item is swapped with the `n + m + 1`'th stack item. The gas cost for all three instructions is set at 3. ## Rationale ### Use of an immediate argument Allowing dynamic selection of the arguments to swap, dup, or exchange could be used to prevent static analysis of the contents of the stack. Since static analysis is an important tool for security auditors we want to do what we can to make their jobs easier. Hence, the operands require an immediate argument that is not dynamic in nature. ### EOF-only Since this instruction depends on an immediate argument encoding, it can only be enabled within EOF. In legacy bytecode that encoding could contradict jumpdest-analysis. ### Size of immediate argument For `DUPN` and `SWAPN` a 16-bit size was considered to accommodate the full stack space of 1024 items, however: 1. that would require an additional restriction/check (`n < 1024`) 2. the 256 depth is a large improvement over the current 16 and the overhead of an extra byte would make it less useful Similarly for `EXCHANGE`, the proposed scheme allows addressing of 32 items. ### Gas cost The gas cost for these operations is the same as for existing `DUP*` and `SWAP*` instructions, because they are just implemented as pointer swaps. ### `EXCHANGE` vs `SWAPN` As mentioned before, `EXCHANGE` is important to compilers implementing stack scheduling algorithms. Specifically, in the case that a stack item is scheduled to be consumed deeper in the stack (for instance, the 3rd item in the stack needs to be moved into 2nd position in order to be consumed by the next operation), that currently takes three instructions, `SWAP2 SWAP3 SWAP2`. However, in the EVM implementation, the implementation is just a pointer swap, so it could be implemented in a single instruction at no extra runtime cost to the client. ## Backwards Compatibility This has no effect on backwards compatibility because the opcodes were not previously allocated and the feature is only enabled in EOF. ## Test Cases Given `stack[]` is a 0-based data structure, and `n`, `m` and `imm` are defined as according to the spec: - `DUPN imm` to fail validation if `stack_height < n`. - `SWAPN imm` to fail validation if `stack_height < n + 1`. - `EXCHANGE imm` to fail validation if `stack_height < n + m + 1`. - `DUPN imm` to increment maximum stack height of a function. Validation fails if maximum stack height exceeds limit of 1023. - `DUPN imm`, `SWAPN imm`, and `EXCHANGE imm` to fail at run-time if gas available is less than 3. - `DUPN imm` should duplicate the `stack[n - 1]` item and push it to the stack - `SWAPN imm` should swap `stack[n]` with `stack[stack.top()]` - `EXCHANGE imm` should swap `stack[n]` with `stack[n + m]`. ## Security Considerations The authors are not aware of any additional risks introduced here. The EVM stack is fixed at 1024 items and most implementations keep that in memory at all times. This change will increase the number of stack items accessible via single instruction. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 03 Jul 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-663 https://eips.ethereum.org/EIPS/eip-663 Add precompiled contract for Ed25519 signature verification Standards Track/Core ## Simple Summary Support performant and cheap verification of Ed25519 cryptographic signatures in smart contracts in general by adding a precompiled contract for Ed25519 signature verification to the EVM. ## Abstract Verification of Ed25519 cryptographic signatures is obviously possible in EVM bytecode. However, the gas cost will be very high, and computationally expensive, as such tight, wide word operations intensive code as required for Ed25519 is not a good fit for the EVM bytecode model. The addition of a native compiled function, in a precompiled contract, to the EVM solves both cost and performance problems. ## Motivation Ed25519 and Ed448 (that is, EdDSA using Curve25519 or Curve448) are IETF recommendations ([RFC7748](https://tools.ietf.org/html/rfc7748)) with some attractive properties: * Ed25519 is intended to operate at around the 128-bit security level and Ed448 at around the 224-bit security level * EdDSA uses small public keys (32 or 57 octets) and signatures (64 or 114 octets) for Ed25519 and Ed448, respectively * Ed25519/Ed448 are designed so that fast, constant-time (timing attack resistant) and generally side-channel resistant implementations are easier to produce Despite being around only for some years, post-Snowden, these curves [have gained wide use](https://ianix.com/pub/ed25519-deployment.html) quickly in various protocols and systems: * TLS / ECDH(E) (session keys) * TLS / x.509 (client and server certificates) * DNSSEC (zone signing) * OpenSSH (user keys) * GNUPG/OpenPGP (user keys) * OpenBSD Signify (software signing) One motivation for Ed25519 signature verification in smart contracts is to **associate** existing off-chain systems, records or accounts that use Ed25519 (like above) with blockchain addresses or **delegate** by allowing to sign data with Ed25519 (only), and then submit this Ed25519-signed data anonymously (via any Eth sender address) to the blockchain, having the contract check the Ed25519 signature of the transaction. Another motivation is the processing of external, Ed25519 proof-of-stake based blockchains within Ethereum smart contracts. When a transactions contains data that comes with an Ed25519 signature, that proves that the sender of the Ethereum transaction was also in control of the private key (and the data), and this allows the contract to establish an association between the blockchain and the external system or account, and the external system establish the reverse relation. For example, a contract might check a Ed25519 signed piece of data submitted to the Ethereum transaction like the current block number. That proves to the contract, that the sender is in possession of both the Ethereum private key and the Ed25519 private key, and hence the contract will accept an association between both. This again can be the root anchor for various powerful applications, as now a potentially crypto holding key owner has proven to be in control of some external off-chain system or account, like e.g. a DNS server, a DNS domain, a cluster node and so on. ## Specification If `block.number >= CONSTANTINOPLE_FORK_BLKNUM`, add a precompiled contract for Ed25519 signature verification (`ED25519VFY`). The proposal adds a new precompiled function `ED25519VFY` with the following input and output. `ED25519VFY` takes as **input 128 octets**: 1. **message**: the 32-octet message that was signed 2. **public key**: the 32-octet Ed25519 public key of the signer 3. **signature**: the 64-octet Ed25519 signature `ED25519VFY` returns as **output 4 octets**: * `0x00000000` if signature is valid * any non-zero value indicates a signature verification failure ### Address The address of `ED25519VFY` is **`0x9`.** ### Gas costs Gas cost for `ED25519VFY` is **2000**. ## Rationale The proposed `ED25519VFY` function takes the signer public key as a call parameter, as with Ed25519, I don't believe it is possible to derive the signers public key from the signature and message alone. The proposed `ED25519VFY` function uses a zero return value to indicate success, since this allows for different errors to be distinguished by return value, as all non-zero return values signal a verification failure. `ECRECOVER` has a gas cost of 3000. Since Ed25519 is computationally cheaper, the gas price should be less. ## Backwards Compatibility As the proposed precompiled contract is deployed at a reserved (<255) and previously unused address, an implementation of the proposal should not introduce any backward compatibility issues. ## Test Cases Test vectors for Ed25519 can be found in this IETF ID https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6. More test vectors can be found in the regression tests of NaCl (see references). ## Implementation ### libsodium libsodium is a mature, high-quality C implementation of Ed25519, with bindings for many languages. Further, libsodium is (to my knowledge, and as of today 2018/04) the only Ed25519 implementation that has gone through a [Security Assessment](https://www.privateinternetaccess.com/blog/2017/08/libsodium-v1-0-12-and-v1-0-13-security-assessment/). To minimize consensus failure risks, the proposal recommends to use libsodium for adding the precompile in all Ethereum client implementations. > Note: as an alternative to libsodium, I looked into HACL, an implementation of Ed25519 in F* (a ML dialect) that can be transpiled to C, and that was formally verified for functional correctness and memory safety of the resulting C code. However, this is new and compared to libsodium which is a "know thing" seems risky nevertheless. ### libsodium bindings Here is an overview of the language bindings to libsodium for four Ethereum clients this proposal recommends: | Client | Language | libsodium binding | ---------------|----------|--------------------| | Geth | Go | use cgo with C [libsodium](https://github.com/jedisct1/libsodium)| | Parity | Rust | [sodiumoxide](https://github.com/dnaq/sodiumoxide)| | PyEthereum | Python | [PyNaCl](https://github.com/pyca/pynacl)| | cpp-ethereum | C++ | [libsodium](https://github.com/jedisct1/libsodium)| ---------------------------------------------------------------------------- ### PRs Implementations of this proposal are here: 1. [go-ethereum PR #16453](https://github.com/ethereum/go-ethereum/pull/16453) 2. [pyethereum PR #862](https://github.com/ethereum/pyethereum/pull/862) 3. [parity PR #8330](https://github.com/paritytech/parity/pull/8330) 4. [cpp-ethereum PR #4945](https://github.com/ethereum/cpp-ethereum/pull/4945) ## References * RFC7748 - Elliptic Curves for Security https://tools.ietf.org/html/rfc7748 * Definition of Ed25519: https://ed25519.cr.yp.to/ed25519-20110926.pdf * Ed25519 - high-speed high-security signatures: https://ed25519.cr.yp.to/ * NaCl - Networking and Cryptography library: https://nacl.cr.yp.to/sign.html * NaCl Crypto Libraries (which contains Ed25519): https://ianix.com/pub/ed25519-deployment.html * Test vectors for Ed25519: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6 * NaCl regression tests: https://ed25519.cr.yp.to/python/sign.py and https://ed25519.cr.yp.to/python/sign.input * On the recoverability of public keys from signature+message (alone): https://crypto.stackexchange.com/questions/9936/what-signature-schemes-allow-recovering-the-public-key-from-a-signature * Bernstein, D., "Curve25519: new Diffie-Hellman speed records", DOI 10.1007/11745853_14, February 2006, https://cr.yp.to/ecdh.html * Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", June 2015, https://eprint.iacr.org/2015/625> * RFC8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC (https://datatracker.ietf.org/doc/html/rfc8080) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 25 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-665 https://eips.ethereum.org/EIPS/eip-665 URL Format for Transaction Requests Standards Track/ERC https://ethereum-magicians.org/t/erc-681-representing-various-transactions-as-urls ## Simple Summary A standard way of representing various transactions, especially payment requests in ether and [ERC-20](/EIPS/eip-20) tokens as URLs. ## Abstract URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format for payment requests allows for instant invocation of the user's preferred wallet application (even if it is a webapp or a swarm đapp), with the correct parameterization of the payment transaction only to be confirmed by the (authenticated) user. ## Motivation The convenience of representing payment requests by standard URLs has been a major factor in the wide adoption of Bitcoin. Bringing a similarly convenient mechanism to Ethereum would speed up its acceptance as a payment platform among end-users. In particular, URLs embedded in broadcast Intents are the preferred way of launching applications on the Android operating system and work across practically all applications. Desktop web browsers have a standardized way of defining protocol handlers for URLs with specific protocol specifications. Other desktop applications typically launch the web browser upon encountering a URL. Thus, payment request URLs could be delivered through a very broad, ever growing selection of channels. This specification supersedes the defunct ERC-67, which is a URL format for representing arbitrary transactions in a low-level fashion. This ERC focuses specifically on the important special case of payment requests, while allowing for other, ABI-specified transactions. ## Specification ### Syntax Payment request URLs contain "ethereum" in their schema (protocol) part and are constructed as follows: request = schema_prefix target_address [ "@" chain_id ] [ "/" function_name ] [ "?" parameters ] schema_prefix = "ethereum" ":" [ "pay-" ] target_address = ethereum_address chain_id = 1*DIGIT function_name = STRING ethereum_address = ( "0x" 40*HEXDIG ) / ENS_NAME parameters = parameter *( "&" parameter ) parameter = key "=" value key = "value" / "gas" / "gasLimit" / "gasPrice" / TYPE value = number / ethereum_address / STRING number = [ "-" / "+" ] *DIGIT [ "." 1*DIGIT ] [ ( "e" / "E" ) [ 1*DIGIT ] ] Where `TYPE` is a standard ABI type name, as defined in [Ethereum Contract ABI specification](https://solidity.readthedocs.io/en/develop/abi-spec.html). `STRING` is a URL-encoded unicode string of arbitrary length, where delimiters and the percentage symbol (`%`) are mandatorily hex-encoded with a `%` prefix. Note that a `number` can be expressed in *scientific notation*, with a multiplier of a power of 10. Only integer numbers are allowed, so the exponent MUST be greater or equal to the number of decimals after the point. If *key* in the parameter list is `value`, `gasLimit`, `gasPrice` or `gas` then *value* MUST be a `number`. Otherwise, it must correspond to the `TYPE` string used as *key*. For the syntax of ENS_NAME, please consult [ERC-137](/EIPS/eip-137) defining Ethereum Name Service. ### Semantics `target_address` is mandatory and denotes either the beneficiary of native token payment (see below) or the contract address with which the user is asked to interact. `chain_id` is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no `chain_id` is present, the client's current network setting remains effective. If `function_name` is missing, then the URL is requesting payment in the native token of the blockchain, which is ether in our case. The amount is specified in `value` parameter, in the atomic unit (i.e. wei). The use of scientific notation is strongly encouraged. For example, requesting 2.014 ETH to address `0xfb6916095ca1df60bb79Ce92ce3ea74c37c5d359` would look as follows: [ethereum:0xfb6916095ca1df60bb79Ce92ce3ea74c37c5d359?value=2.014e18](ethereum:0xfb6916095ca1df60bb79Ce92ce3ea74c37c5d359?value=2.014e18) Requesting payments in [ERC-20](/EIPS/eip-20) tokens involves a request to call the `transfer` function of the token contract with an `address` and a `uint256` typed parameter, containing the *beneficiary address* and the *amount in atomic units*, respectively. For example, requesting a Unicorn to address `0x8e23ee67d1332ad560396262c48ffbb01f93d052` looks as follows: [ethereum:0x89205a3a3b2a69de6dbf7f01ed13b2108b2c43e7/transfer?address=0x8e23ee67d1332ad560396262c48ffbb01f93d052&uint256=1](ethereum:0x89205a3a3b2a69de6dbf7f01ed13b2108b2c43e7/transfer?address=0x8e23ee67d1332ad560396262c48ffbb01f93d052&uint256=1) If using ENS names instead of hexadecimal addresses, the resolution is up to the payer, at any time between receiving the URL and sending the transaction. Hexadecimal addresses always take precedence over ENS names, i. e. even if there exists a matching ENS name consisting of `0x` followed by 40 hexadecimal digits, it should never be resolved. Instead, the hexadecimal address should be used directly. Note that the indicated amount is only a suggestion (as are all the supplied arguments) which the user is free to change. With no indicated amount, the user should be prompted to enter the amount to be paid. Similarly `gasLimit` and `gasPrice` are suggested user-editable values for *gas limit* and *gas price*, respectively, for the requested transaction. It is acceptable to abbreviate `gasLimit` as `gas`, the two are treated synonymously. ## Rationale The proposed format is chosen to resemble `bitcoin:` URLs as closely as possible, as both users and application programmers are already familiar with that format. In particular, this motivated the omission of the unit, which is often used in Ethereum ecosystem. Handling different orders of magnitude is facilitated by the exponent so that amount values can be expressed in their nominal units, just like in the case of `bitcoin:`. The use of scientific notation is strongly encouraged when expressing monetary value in ether or [ERC-20](/EIPS/eip-20) tokens. For better human readability, the exponent should be the decimal value of the nominal unit: 18 for ether or the value returned by `decimals()` of the token contract for [ERC-20](/EIPS/eip-20) tokens. Additional parameters may be added, if popular use cases requiring them emerge in practice. The `0x` prefix before ethereum addresses specified as hexadecimal numbers is following established practice and also unambiguously distinguishes hexadecimal addresses from ENS names consisting of 40 alphanumeric characters. Future upgrades that are partially or fully incompatible with this proposal must use a prefix other than `pay-` that is separated by a dash (`-`) character from whatever follows it. ## Backwards Compatibility In the fairly common case of only indicating the recipient address in a request for payment in ether, this specification is compatible with the superseded ERC-67. ## Security Considerations Since irreversible transactions can be initiated with parameters from such URLs, the integrity and authenticity of these URLs are of great importance. In particular, changing either the recipient address or the amount transferred can be a profitable attack. Users should only use URLs received from authenticated sources with adequate integrity protection. To prevent malicious redirection of payments using ENS, hexadecimal interpretation of Ethereum addresses must have precedence over ENS lookups. Client software may alert the user if an ENS address is visually similar to a hexadecimal address or even outright reject such addresses as likely phishing attacks. In order to make sure that the amount transacted is the same as the amount intended, the amount communicated to the human user should be easily verifiable by inspection, including the order of magnitude. In case of [ERC-20](/EIPS/eip-20) token payments, if the payer client has access to the blockchain or some other trusted source of information about the token contract, the interface should display the amount in the units specified in the token contract. Otherwise, it should be displayed as expressed in the URL, possibly alerting the user to the uncertainty of the nominal unit. To facilitate human inspection of the amount, the use of scientific notation with an exponent corresponding to the nominal unit of the transacted token (e.g. 18 in case of ether) is advisable. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 01 Aug 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-681 https://eips.ethereum.org/EIPS/eip-681 Revert creation in case of collision Standards Track/Core https://ethereum-magicians.org/t/eip-revert-on-address-collision/13442 ## Abstract This EIP causes contract creation to throw an error when attempted at an address with pre-existing code. This prevents an attack consisting of deploying contract code and later changing the code arbitrarily by "creating" an account at that existing address. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. If a contract creation is attempted due to a creation transaction, the `CREATE` opcode, the `CREATE2` opcode, or any other reason, and the destination address already has either a nonzero nonce, or a nonzero code length, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks. ## Rationale One of the core tenets of smart contracts is that their code will not change. However with sufficient computing power an attacker can change the code stored in an address to any other code, steal funds or execute other malicious activity. ## Backwards Compatibility This is an execution layer upgrade, and so it requires a hard fork. ## Test Cases Given a genesis allocation of ``` Address : 0xd0bBEc6D2c628b7e2E6D5556daA14a5181b604C5, Balance : 1000000000000000000, // 1 ether Nonce : 0, code : "", Address : 0x7658771dc6Af74a3d2F8499D349FF9c1a0DF8826, Balance : 0, Nonce : 1, Code : "0xB0B0FACE", ``` A contract created in the first transaction from EOA `0xd0bBEc6...` (`227bcc6959669226360814723ed739f1214201584b6a27409dfb8228b8be5f59`), with no salt, should revert. ## Security Considerations This EIP is a security upgrade: it enforces the immutability of deployed code. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 20 Mar 2023 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-684 https://eips.ethereum.org/EIPS/eip-684 Address Collision of Contract Address Causes Exceptional Halt Standards Track/Core ## Simple Summary This EIP proposes to make contract creation fail on an account with nonempty code or non-zero nonce. ## Abstract Some test cases in the consensus test suite try to deploy a contract at an address already with nonempty code. Although such cases can virtually never happen on the main network before the Constantinople fork block, the test cases detected discrepancies in clients' behavior. Currently, the Yellow Paper says that the contract creation starts with the empty code and the initial nonce even in the case of address collisions. To simplify the semantics, this EIP proposes that address collisions cause failures of contract creation. ## Motivation This EIP has no practical relevance to the main net history, but simplifies testing and reasoning. This EIP has no effects after Constantinople fork because [EIP-86](/EIPS/eip-86) contains the changes proposed in this EIP. Even before the Constantinople fork, this EIP has no practical relevance because the change is visible only in case of a hash collision of keccak256. Regarding testing, this EIP relieves clients from supporting reversion of code overwriting. Regarding reasoning, this EIP establishes an invariant that non-empty code is never modified. ## Specification If `block.number >= 0`, when a contract creation is on an account with non-zero nonce or non-empty code, the creation fails as if init code execution resulted in an exceptional halt. This applies to contract creation triggered by a contract creation transaction and by CREATE instruction. ## Rationale It seems impractical to implement never-used features just for passing tests. Client implementations will be simpler with this EIP. ## Backwards Compatibility This EIP is backwards compatible on the main network. ## Test Cases At least the BlockchainTest called `createJS\_ExampleContract\_d0g0v0\_EIP158` will distinguish clients that implement this EIP. ## Implementation ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 15 Aug 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-689 https://eips.ethereum.org/EIPS/eip-689 Create `eth_chainId` method for JSON-RPC Standards Track/Interface https://ethereum-magicians.org/t/eip-695-create-eth-chainid-method-for-json-rpc/1845 ## Simple Summary Include `eth_chainId` method in `eth_`-namespaced JSON-RPC methods. ## Abstract The `eth_chainId` method should return a single STRING result for an integer value in hexadecimal format, describing the currently configured `CHAIN_ID` value used for signing replay-protected transactions, introduced by [EIP-155](/EIPS/eip-155). ## Motivation Currently although we can use `net_version` RPC call to get the current network ID, there's no RPC for querying the chain ID. This makes it impossible to determine the current actual blockchain using the RPC. ## Specification ### `eth_chainId` Returns the currently configured chain ID, a value used in replay-protected transaction signing as introduced by [EIP-155](/EIPS/eip-155). The chain ID returned should always correspond to the information in the current known head block. This ensures that caller of this RPC method can always use the retrieved information to sign transactions built on top of the head. If the current known head block does not specify a chain ID, the client should treat any calls to `eth_chainId` as though the method were not supported, and return a suitable error. #### Parameters None. #### Returns `QUANTITY` - integer of the current chain ID. #### Example ```js curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":83}' // Result { "id": 83, "jsonrpc": "2.0", "result": "0x3d" // 61 } ``` ## Rationale An ETH/ETC client can accidentally connect to an ETC/ETH RPC endpoint without knowing it unless it tries to sign a transaction or it fetches a transaction that is known to have signed with a chain ID. This has since caused trouble for application developers, such as MetaMask, to add multi-chain support. ## Backwards Compatibility Not relevant. ## Security Considerations Consumers should prefer `eth_chainId` over `net_version`, so that they can reliably identify chain they are communicating with. Implementers should take care to implement `eth_chainId` correctly and promote its use, since the chain ID is critical in replay attack prevention as described in [EIP-155](/EIPS/eip-155), and consumers will rely on it to identify the chain they are communicating with. ## Implementation - [Parity PR](https://github.com/paritytech/parity/pull/6329) - [Geth PR](https://github.com/ethereum/go-ethereum/pull/17617) - [Geth Classic PR](https://github.com/ethereumproject/go-ethereum/pull/336) ## Reference Return value `QUANTITY` adheres to standard JSON RPC hex value encoding, as documented in the [Ethereum.org documentation](https://ethereum.org/en/developers/docs/apis/json-rpc/#hex-encoding). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 21 Aug 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-695 https://eips.ethereum.org/EIPS/eip-695 OPCODE 0x46 BLOCKREWARD Standards Track/Core https://github.com/ethereum/EIPs/issues/698 ## Simple Summary This EIP adds an additional opcode to the EVM which will return a finalized blocks reward value. ## Abstract In the EVM, the 0x40 opcodes are reserved for `Block Information`. Currently reserved opcodes are: * `0X40 BLOCKHASH` * `0X41 COINBASE` * `0X42 TIMESTAMP` * `0X43 NUMBER` * `0X44 DIFFICULTY` * `0X45 GASLIMIT` This EIP would add an additional opcode, `0x46 BLOCKREWARD`, which would return the block reward for any finalized block. The finalized block reward would include the base reward, uncle payments, and gas. ## Motivation Per EIP-649 ( #669 ) periodic block reward reductions/variance are now planned in the roadmap, however, this EIP is consensus system agnostic and is most useful in decentralized pool operations and for any contract that benefits from knowing a block reward payout(i.e. Merge mined tokens) ## Specification After block `n` all clients should process opcode `0x46` as follows: * Value: `0x46` * Mnemonic: `BLOCKREWARD` * δ:` 0` nothing removed from stack * α:`1` block reward added to stack * Description: `Get the block's reward emission` * GasCost: `G<sub>base</sub>` Where:`µ'<sub>s</sub>[0] ≡ I<sub>HR</sub>` ## Rationale ### Contract Mining Pools For distributed consensus systems(staking pools and mining pools) ad hoc groups combine resources in order to reduce variance in payouts. Broadly, pool operations function by allowing a collective of miners / stakers to verify their contribution to solving PoW or staking share by periodically submitting solutions which are representative of the miners probability of finding a true block. In all these schemes `B` stands for a block reward minus pool fee and `p` is a probability of finding a block in a share attempt ( `p=1/D`, where `D` is current block difficulty). Some common methods of mining pool payout are pay-per-share, `R = B * p`, proportional [`R = B * (n/N)` where `n` is amount of a miners shares, and `N` is amount of all shares in this round.], and pay-per-last-N-shares [`R = B * (n/N)` where miner's reward is calculated on a basis of `N` last shares, instead of all shares for the last round]. All of these methods are predicated on knowing the block reward paid for a given block. In order to provide a trust minimized solution, `0x46` can be used to call a blocks reward for computing payouts. ### Merge mined tokens Contracts could create tokens which could be variably ‘minted’ as a function of block reward by calling `0x46` ## Backwards Compatibility ### Currently deployed contracts No impact ### Current clients This EIP would be incompatible with currently deployed clients that are not able to handle `0x46` and would process all transactions and block containing the opcode as invalid. Implementation should occur as part of a coordinated hardfork. ## Implementation ## Further reading [Mining Pools](https://en.wikipedia.org/wiki/Mining_pool) The Yellow Paper Appendix H. Virtual Machine Specification section H.2 ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 28 Aug 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-698 https://eips.ethereum.org/EIPS/eip-698 DEVp2p snappy compression Standards Track/Networking ## Abstract The base networking protocol (DEVp2p) used by Ethereum currently does not employ any form of compression. This results in a massive amount of bandwidth wasted in the entire network, making both initial sync as well as normal operation slower and laggier. This EIP proposes a tiny extension to the DEVp2p protocol to enable [Snappy compression](https://en.wikipedia.org/wiki/Snappy_(compression)) on all message payloads after the initial handshake. After extensive benchmarks, results show that data traffic is decreased by 60-80% for initial sync. You can find exact numbers below. ## Motivation Synchronizing the Ethereum main network (block 4,248,000) in Geth using fast sync currently consumes 1.01GB upload and 33.59GB download bandwidth. On the Rinkeby test network (block 852,000) it's 55.89MB upload and 2.51GB download. However, most of this data (blocks, transactions) are heavily compressible. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network. The motivation behind doing this at the DEVp2p level (opposed to eth for example) is that it would enable compression for all sub-protocols (eth, les, bzz) seamlessly, reducing any complexity those protocols might incur in trying to individually optimize for data traffic. ## Specification Bump the advertised DEVp2p version number from `4` to `5`. If during handshake, the remote side advertises support only for version `4`, run the exact same protocol as until now. If the remote side advertises a DEVp2p version `>= 5`, inject a Snappy compression step right before encrypting the DEVp2p message during sending: * A message consists of `{Code, Size, Payload}` * Compress the original payload with Snappy and store it in the same field. * Update the message size to the length of the compressed payload. * Encrypt and send the message as before, oblivious to compression. Similarly to message sending, when receiving a DEVp2p v5 message from a remote node, insert a Snappy decompression step right after decrypting the DEVp2p message: * A message consists of `{Code, Size, Payload}` * Decrypt the message payload as before, oblivious to compression. * Decompress the payload with Snappy and store it in the same field. * Update the message size to the length of the decompressed payload. Important caveats: * The handshake message is **never** compressed, since it is needed to negotiate the common version. * Snappy framing is **not** used, since the DEVp2p protocol already message oriented. *Note: Snappy supports uncompressed binary literals (up to 4GB) too, leaving room for fine-tuned future optimisations for already compressed or encrypted data that would have no gain of compression (Snappy usually detects this case automatically).* ### Avoiding DOS attacks Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindly decompress messages, since they may get significantly larger than 16MB. However, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory (*[the stream starts with the uncompressed length up to a maximum of `2^32 - 1` stored as a little-endian varint](https://github.com/google/snappy/blob/master/format_description.txt#L20)*). This can be used to discard any messages which decompress above some threshold. **The proposal is to use the same limit (16MB) as the threshold for decompressed messages.** This retains the same guarantees that the current DEVp2p protocol does, so there won't be surprises in application level protocols. ## Alternatives (discarded) **Alternative solutions to data compression that have been brought up and discarded are:** Extend protocol `xyz` to support compressed messages versus doing it at DEVp2p level: * **Pro**: Can be better optimized when to compress and when not to. * **Con**: Mixes in transport layer encoding into application layer logic. * **Con**: Makes the individual message specs more convoluted with compression details. * **Con**: Requires cross client coordination on every single protocol, making the effort much harder and repeated (eth, les, shh, bzz). Introduce seamless variations of protocol such as `xyz` expanded with `xyz-compressed`: * **Pro**: Can be done (hacked in) without cross client coordination. * **Con**: Litters the network with client specific protocol announces. * **Con**: Needs to be specced in an EIP for cross interoperability anyway. **Other ideas that have been discussed and discarded:** Don't explicitly limit the decompressed message size, only the compressed one: * **Pro**: Allows larger messages to traverse through DEVp2p. * **Con**: Upper layer protocols need to check and discard large messages. * **Con**: Needs lazy decompression to allow size limitations without DOS. ## Backwards Compatibility This proposal is fully backward compatible. Clients upgrading to the proposed DEVp2p protocol version `5` should still support skipping the compression step for connections that only advertise version `4` of the DEVp2p protocol. ## Implementation You can find a reference implementation of this EIP in https://github.com/ethereum/go-ethereum/pull/15106. ## Test vectors There is more than one valid encoding of any given input, and there is more than one good internal compression algorithm within Snappy when trading off throughput for output size. As such, different implementations might produce slight variations in the compressed form, but all should be cross compatible between each other. As an example, take hex encoded RLP of block #272621 from the Rinkeby test network: [block.rlp (~3MB)](https://gist.githubusercontent.com/karalabe/72a1a6c4c1dbe6d4996879e415697f06/raw/195bf0c0050ee9805fcd5db4b5b650c58879a55f/block.rlp). * Encoding the raw RLP via [Go's Snappy library](https://github.com/golang/snappy) yields: [block.go.snappy (~70KB)](https://gist.githubusercontent.com/karalabe/72a1a6c4c1dbe6d4996879e415697f06/raw/195bf0c0050ee9805fcd5db4b5b650c58879a55f/block.go.snappy). * Encoding the raw RLP via [Python's Snappy library](https://github.com/andrix/python-snappy) yields: [block.py.snappy (~70KB)](https://gist.githubusercontent.com/karalabe/72a1a6c4c1dbe6d4996879e415697f06/raw/195bf0c0050ee9805fcd5db4b5b650c58879a55f/block.py.snappy). You can verify that an encoded binary can be decoded into the proper plaintext using the following snippets: ### Go ```sh $ go get https://github.com/golang/snappy ``` ```go package main import ( "bytes" "encoding/hex" "fmt" "io/ioutil" "log" "os" "github.com/golang/snappy" ) func main() { // Read and decode the decompressed file plainhex, err := ioutil.ReadFile(os.Args[1]) if err != nil { log.Fatalf("Failed to read decompressed file %s: %v", os.Args[1], err) } plain, err := hex.DecodeString(string(plainhex)) if err != nil { log.Fatalf("Failed to decode decompressed file: %v", err) } // Read and decode the compressed file comphex, err := ioutil.ReadFile(os.Args[2]) if err != nil { log.Fatalf("Failed to read compressed file %s: %v", os.Args[2], err) } comp, err := hex.DecodeString(string(comphex)) if err != nil { log.Fatalf("Failed to decode compressed file: %v", err) } // Make sure they match decomp, err := snappy.Decode(nil, comp) if err != nil { log.Fatalf("Failed to decompress compressed file: %v", err) } if !bytes.Equal(plain, decomp) { fmt.Println("Booo, decompressed file does not match provided plain text!") return } fmt.Println("Yay, decompressed data matched provided plain text!") } ``` ```sh $ go run main.go block.rlp block.go.snappy Yay, decompressed data matched provided plain text! $ go run main.go block.rlp block.py.snappy Yay, decompressed data matched provided plain text! ``` ### Python ```bash $ pip install python-snappy ``` ```py import snappy import sys # Read and decode the decompressed file with open(sys.argv[1], 'rb') as file: plainhex = file.read() plain = plainhex.decode("hex") # Read and decode the compressed file with open(sys.argv[2], 'rb') as file: comphex = file.read() comp = comphex.decode("hex") # Make sure they match decomp = snappy.uncompress(comp) if plain != decomp: print "Booo, decompressed file does not match provided plain text!" else: print "Yay, decompressed data matched provided plain text!" ``` ```sh $ python main.py block.rlp block.go.snappy Yay, decompressed data matched provided plain text! $ python main.py block.rlp block.py.snappy Yay, decompressed data matched provided plain text! ``` ## References * Snappy website: https://google.github.io/snappy/ * Snappy specification: https://github.com/google/snappy/blob/master/format_description.txt ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 07 Sep 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-706 https://eips.ethereum.org/EIPS/eip-706 Typed structured data hashing and signing Standards Track/Interface https://ethereum-magicians.org/t/eip-712-eth-signtypeddata-as-a-standard-for-machine-verifiable-and-human-readable-typed-data-signing/397 ## Abstract This is a standard for hashing and signing of typed structured data as opposed to just bytestrings. It includes a * theoretical framework for correctness of encoding functions, * specification of structured data similar to and compatible with Solidity structs, * safe hashing algorithm for instances of those structures, * safe inclusion of those instances in the set of signable messages, * an extensible mechanism for domain separation, * new RPC call `eth_signTypedData`, and * an optimized implementation of the hashing algorithm in EVM. It does not include replay protection. ## Motivation Signing data is a solved problem if all we care about are bytestrings. Unfortunately in the real world we care about complex meaningful messages. Hashing structured data is non-trivial and errors result in loss of the security properties of the system. As such, the adage "don't roll your own crypto" applies. Instead, a peer-reviewed well-tested standard method needs to be used. This EIP aims to be that standard. This EIP aims to improve the usability of off-chain message signing for use on-chain. We are seeing growing adoption of off-chain message signing as it saves gas and reduces the number of transactions on the blockchain. Currently signed messages are an opaque hex string displayed to the user with little context about the items that make up the message. ![eth_sign screenshot](/assets/eip-712/eth_sign.png) Here we outline a scheme to encode data along with its structure which allows it to be displayed to the user for verification when signing. Below is an example of what a user could be shown when signing a message according to the present proposal. ![eth_signTypedData screenshot](/assets/eip-712/eth_signTypedData.png) ## Specification The set of signable messages is extended from transactions and bytestrings `𝕋 ∪ 𝔹⁸ⁿ` to also include structured data `𝕊`. The new set of signable messages is thus `𝕋 ∪ 𝔹⁸ⁿ ∪ 𝕊`. They are encoded to bytestrings suitable for hashing and signing as follows: * `encode(transaction : 𝕋) = RLP_encode(transaction)` * `encode(message : 𝔹⁸ⁿ) = "\x19Ethereum Signed Message:\n" ‖ len(message) ‖ message` where `len(message)` is the _non-zero-padded_ ascii-decimal encoding of the number of bytes in `message`. * `encode(domainSeparator : 𝔹²⁵⁶, message : 𝕊) = "\x19\x01" ‖ domainSeparator ‖ hashStruct(message)` where `domainSeparator` and `hashStruct(message)` are defined below. This encoding is deterministic because the individual components are. The encoding is injective because the three cases always differ in first byte. (`RLP_encode(transaction)` does not start with `\x19`.) The encoding is compliant with [ERC-191][ERC-191]. The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte domain separator `domainSeparator` and the 'data to sign' is the 32-byte `hashStruct(message)`. [ERC-191]: /EIPS/eip-191 ### Definition of typed structured data `𝕊` To define the set of all structured data, we start with defining acceptable types. Like ABIv2 these are closely related to Solidity types. It is illustrative to adopt Solidity notation to explain the definitions. The standard is specific to the Ethereum Virtual Machine, but aims to be agnostic to higher level languages. Example: ```Solidity struct Mail { address from; address to; string contents; } ``` **Definition**: A _struct type_ has valid identifier as name and contains zero or more member variables. Member variables have a member type and a name. **Definition**: A _member type_ can be either an atomic type, a dynamic type or a reference type. **Definition**: The _atomic types_ are `bytes1` to `bytes32`, `uint8` to `uint256`, `int8` to `int256`, `bool` and `address`. These correspond to their definition in Solidity. Note that there are no aliases `uint` and `int`. Note that contract addresses are always plain `address`. Fixed point numbers are not supported by the standard. Future versions of this standard may add new atomic types. **Definition**: The _dynamic types_ are `bytes` and `string`. These are like the atomic types for the purpose of type declaration, but their treatment in encoding is different. **Definition**: The _reference types_ are arrays and structs. Arrays are either fixed size or dynamic and denoted by `Type[n]` or `Type[]` respectively. Structs are references to other structs by their name. The standard supports recursive struct types. **Definition**: The set of structured typed data `𝕊` contains all the instances of all the struct types. ### Definition of `hashStruct` The `hashStruct` function is defined as * `hashStruct(s : 𝕊) = keccak256(typeHash ‖ encodeData(s))` where `typeHash = keccak256(encodeType(typeOf(s)))` **Note**: The `typeHash` is a constant for a given struct type and does not need to be runtime computed. ### Definition of `encodeType` The type of a struct is encoded as `name ‖ "(" ‖ member₁ ‖ "," ‖ member₂ ‖ "," ‖ … ‖ memberₙ ")"` where each member is written as `type ‖ " " ‖ name`. For example, the above `Mail` struct is encoded as `Mail(address from,address to,string contents)`. If the struct type references other struct types (and these in turn reference even more struct types), then the set of referenced struct types is collected, sorted by name and appended to the encoding. An example encoding is `Transaction(Person from,Person to,Asset tx)Asset(address token,uint256 amount)Person(address wallet,string name)`. ### Definition of `encodeData` The encoding of a struct instance is `enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ)`, i.e. the concatenation of the encoded member values in the order that they appear in the type. Each encoded member value is exactly 32-byte long. The atomic values are encoded as follows: Boolean `false` and `true` are encoded as `uint256` values `0` and `1` respectively. Addresses are encoded as `uint160`. Integer values are sign-extended to 256-bit and encoded in big endian order. `bytes1` to `bytes31` are arrays with a beginning (index `0`) and an end (index `length - 1`), they are zero-padded at the end to `bytes32` and encoded in beginning to end order. This corresponds to their encoding in ABI v1 and v2. The dynamic values `bytes` and `string` are encoded as a `keccak256` hash of their contents. The array values are encoded as the `keccak256` hash of the concatenated `encodeData` of their contents (i.e. the encoding of `SomeType[5]` is identical to that of a struct containing five members of type `SomeType`). The struct values are encoded recursively as `hashStruct(value)`. This is undefined for cyclical data. ### Definition of `domainSeparator` ```Solidity domainSeparator = hashStruct(eip712Domain) ``` where the type of `eip712Domain` is a struct named `EIP712Domain` with one or more of the below fields. Protocol designers only need to include the fields that make sense for their signing domain. Unused fields are left out of the struct type. * `string name` the user readable name of signing domain, i.e. the name of the DApp or the protocol. * `string version` the current major version of the signing domain. Signatures from different versions are not compatible. * `uint256 chainId` the [EIP-155][EIP-155] chain id. The user-agent _should_ refuse signing if it does not match the currently active chain. * `address verifyingContract` the address of the contract that will verify the signature. The user-agent _may_ do contract specific phishing prevention. * `bytes32 salt` a disambiguating salt for the protocol. This can be used as a domain separator of last resort. [EIP-155]: /EIPS/eip-155 Future extensions to this standard can add new fields with new user-agent behaviour constraints. User-agents are free to use the provided information to inform/warn users or refuse signing. Dapp implementers should not add private fields, new fields should be proposed through the EIP process. The `EIP712Domain` fields should be the order as above, skipping any absent fields. Future field additions must be in alphabetical order and come after the above fields. User-agents should accept fields in any order as specified by the `EIP712Domain` type. ### Specification of the `eth_signTypedData` JSON RPC The method `eth_signTypedData` is added to the Ethereum JSON-RPC. The method parallels `eth_sign`. #### eth_signTypedData The sign method calculates an Ethereum specific signature with: `sign(keccak256("\x19\x01" ‖ domainSeparator ‖ hashStruct(message)))`, as defined above. **Note**: the address to sign with must be unlocked. ##### Parameters 1. `Address` - 20 Bytes - Address of the account that will sign the messages. 2. `TypedData` - Typed structured data to be signed. Typed data is a JSON object containing type information, domain separator parameters and the message object. Below is the json-schema definition for `TypedData` param. ```JavaScript { type: 'object', properties: { types: { type: 'object', properties: { EIP712Domain: {type: 'array'}, }, additionalProperties: { type: 'array', items: { type: 'object', properties: { name: {type: 'string'}, type: {type: 'string'} }, required: ['name', 'type'] } }, required: ['EIP712Domain'] }, primaryType: {type: 'string'}, domain: {type: 'object'}, message: {type: 'object'} }, required: ['types', 'primaryType', 'domain', 'message'] } ``` ##### Returns `DATA`: Signature. As in `eth_sign` it is a hex encoded 65 byte array starting with `0x`. It encodes the `r`, `s` and `v` parameters from appendix F of the yellow paper in big-endian format. Bytes 0...32 contain the `r` parameter, bytes 32...64 the `s` parameter and the last byte the `v` parameter. Note that the `v` parameter includes the chain id as specified in [EIP-155][eip-155]. ##### Example Request: ```shell curl -X POST --data '{"jsonrpc":"2.0","method":"eth_signTypedData","params":["0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826", {"types":{"EIP712Domain":[{"name":"name","type":"string"},{"name":"version","type":"string"},{"name":"chainId","type":"uint256"},{"name":"verifyingContract","type":"address"}],"Person":[{"name":"name","type":"string"},{"name":"wallet","type":"address"}],"Mail":[{"name":"from","type":"Person"},{"name":"to","type":"Person"},{"name":"contents","type":"string"}]},"primaryType":"Mail","domain":{"name":"Ether Mail","version":"1","chainId":1,"verifyingContract":"0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC"},"message":{"from":{"name":"Cow","wallet":"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826"},"to":{"name":"Bob","wallet":"0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB"},"contents":"Hello, Bob!"}}],"id":1}' ``` Result: ```JavaScript { "id":1, "jsonrpc": "2.0", "result": "0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c" } ``` An example how to use Solidity ecrecover to verify the signature calculated with `eth_signTypedData` can be found in the [Example.js][example-js]. The contract is deployed on the testnet Ropsten and Rinkeby. [example-js]: /assets/eip-712/Example.js #### personal_signTypedData There also should be a corresponding `personal_signTypedData` method which accepts the password for an account as the last argument. ### Specification of the Web3 API Two methods are added to Web3.js version 1 that parallel the `web3.eth.sign` and `web3.eth.personal.sign` methods. #### web3.eth.signTypedData ```JavaScript web3.eth.signTypedData(typedData, address [, callback]) ``` Signs typed data using a specific account. This account needs to be unlocked. ##### Parameters 1. ``Object`` - Domain separator and typed data to sign. Structured according to the JSON-Schema specified above in the `eth_signTypedData` JSON RPC call. 2. ``String|Number`` - Address to sign data with. Or an address or index of a local wallet in :ref:`web3.eth.accounts.wallet <eth_accounts_wallet>`. 3. ``Function`` - (optional) Optional callback, returns an error object as first parameter and the result as second. **Note**: The 2. ``address`` parameter can also be an address or index from the `web3.eth.accounts.wallet <eth_accounts_wallet>`. It will then sign locally using the private key of this account. ##### Returns ``Promise`` returns ``String`` - The signature as returned by `eth_signTypedData`. ##### Example See the `eth_signTypedData` JSON-API example above for the value of `typedData`. ```JavaScript web3.eth.signTypedData(typedData, "0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826") .then(console.log); > "0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c" ``` #### web3.eth.personal.signTypedData ```JavaScript web3.eth.personal.signTypedData(typedData, address, password [, callback]) ``` Identical to `web3.eth.signTypedData` except for an additional `password` parameter analogous to `web3.eth.personal.sign`. ## Rationale The `encode` function is extended with a new case for the new types. The first byte of the encoding distinguishes the cases. For the same reason it is not safe to start immediately with the domain separator or a `typeHash`. While hard, it may be possible to construct a `typeHash` that also happens to be a prefix of a valid RLP encoded transaction. The domain separator prevents collision of otherwise identical structures. It is possible that two DApps come up with an identical structure like `Transfer(address from,address to,uint256 amount)` that should not be compatible. By introducing a domain separator the DApp developers are guaranteed that there can be no signature collision. The domain separator also allows for multiple distinct signatures use-cases on the same struct instance within a given DApp. In the previous example, perhaps signatures from both `from` and `to` are required. By providing two distinct domain separators these signatures can be distinguished from each other. **Alternative 1**: Use the target contract address as domain separator. This solves the first problem, contracts coming up with identical types, but does not address the second use-case. The standard does suggest implementors to use the target contract address where this is appropriate. The function `hashStruct` starts with a `typeHash` to separate types. By giving different types a different prefix the `encodeData` function only has to be injective within a given type. It is okay for `encodeData(a)` to equal `encodeData(b)` as long as `typeOf(a)` is not `typeOf(b)`. ### Rationale for `typeHash` The `typeHash` is designed to turn into a compile time constant in Solidity. For example: ```Solidity bytes32 constant MAIL_TYPEHASH = keccak256( "Mail(address from,address to,string contents)"); ``` For the type hash several alternatives were considered and rejected for the reasons: **Alternative 2**: Use ABIv2 function signatures. `bytes4` is not enough to be collision resistant. Unlike function signatures, there is negligible runtime cost incurred by using longer hashes. **Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the semantics other than the function. This is already causing a practical collision between [ERC-20]'s and [ERC-721]'s `transfer(address,uint256)`, where in the former the `uint256` refers to an amount and the latter to a unique id. In general ABIv2 favors compatibility where a hashing standard should prefer incompatibility. [ERC-20]: /EIPS/eip-20 [ERC-721]: /EIPS/eip-721 **Alternative 4**: 256-bit ABIv2 signatures extended with parameter names and struct names. The `Mail` example from above would be encoded as `Mail(Person(string name,address wallet) from,Person(string name,address wallet) to,string contents)`. This is longer than the proposed solution. And indeed, the length of the string can grow exponentially in the length of the input (consider `struct A{B a;B b;}; struct B {C a;C b;}; …`). It also does not allow a recursive struct type (consider `struct List {uint256 value; List next;}`). **Alternative 5**: Include natspec documentation. This would include even more semantic information in the schemaHash and further reduces chances of collision. It makes extending and amending documentation a breaking changes, which contradicts common assumptions. It also makes the schemaHash mechanism very verbose. ### Rationale for `encodeData` The `encodeData` is designed to allow easy implementation of `hashStruct` in Solidity: ```Solidity function hashStruct(Mail memory mail) pure returns (bytes32 hash) { return keccak256(abi.encode( MAIL_TYPEHASH, mail.from, mail.to, keccak256(mail.contents) )); } ``` it also allows for an efficient in-place implementation in EVM ```Solidity function hashStruct(Mail memory mail) pure returns (bytes32 hash) { // Compute sub-hashes bytes32 typeHash = MAIL_TYPEHASH; bytes32 contentsHash = keccak256(mail.contents); assembly { // Back up select memory let temp1 := mload(sub(mail, 32)) let temp2 := mload(add(mail, 128)) // Write typeHash and sub-hashes mstore(sub(mail, 32), typeHash) mstore(add(mail, 64), contentsHash) // Compute hash hash := keccak256(sub(mail, 32), 128) // Restore memory mstore(sub(mail, 32), temp1) mstore(add(mail, 64), temp2) } } ``` The in-place implementation makes strong but reasonable assumptions on the memory layout of structs in memory. Specifically it assumes structs are not allocated below address 32, that members are stored in order, that all values are padded to 32-byte boundaries, and that dynamic and reference types are stored as a 32-byte pointers. **Alternative 6**: Tight packing. This is the default behaviour in Solidity when calling `keccak256` with multiple arguments. It minimizes the number of bytes to be hashed but requires complicated packing instructions in EVM to do so. It does not allow in-place computation. **Alternative 7**: ABIv2 encoding. Especially with the upcoming `abi.encode` it should be easy to use `abi.encode` as the `encodeData` function. The ABIv2 standard by itself fails the determinism security criteria. There are several valid ABIv2 encodings of the same data. ABIv2 does not allow in-place computation. **Alternative 8**: Leave `typeHash` out of `hashStruct` and instead combine it with the domain separator. This is more efficient, but then the semantics of the Solidity `keccak256` hash function are not injective. **Alternative 9**: Support cyclical data structures. The current standard is optimized for tree-like data structures and undefined for cyclical data structures. To support cyclical data a stack containing the path to the current node needs to be maintained and a stack offset substituted when a cycle is detected. This is prohibitively more complex to specify and implement. It also breaks composability where the hashes of the member values are used to construct the hash of the struct (the hash of the member values would depend on the path). It is possible to extend the standard in a compatible way to define hashes of cyclical data. Similarly, a straightforward implementation is sub-optimal for directed acyclic graphs. A simple recursion through the members can visit the same node twice. Memoization can optimize this. ### Rationale for `domainSeparator` Since different domains have different needs, an extensible scheme is used where the DApp specifies a `EIP712Domain` struct type and an instance `eip712Domain` which it passes to the user-agent. The user-agent can then apply different verification measures depending on the fields that are there. ## Backwards Compatibility The RPC calls, web3 methods and `SomeStruct.typeHash` parameter are currently undefined. Defining them should not affect the behaviour of existing DApps. The Solidity expression `keccak256(someInstance)` for an instance `someInstance` of a struct type `SomeStruct` is valid syntax. It currently evaluates to the `keccak256` hash of the memory address of the instance. This behaviour should be considered dangerous. In some scenarios it will appear to work correctly but in others it will fail determinism and/or injectiveness. DApps that depend on the current behaviour should be considered dangerously broken. ## Test Cases An example contract can be found in [Example.sol][ex-sol] and an example implementation of signing in JavaScript in [Example.js][ex-js] [ex-sol]: /assets/eip-712/Example.sol [ex-js]: /assets/eip-712/Example.js ## Security Considerations ### Replay attacks This standard is only about signing messages and verifying signatures. In many practical applications, signed messages are used to authorize an action, for example an exchange of tokens. It is _very important_ that implementers make sure the application behaves correctly when it sees the same signed message twice. For example, the repeated message should be rejected or the authorized action should be idempotent. How this is implemented is specific to the application and out of scope for this standard. ### Frontrunning attacks The mechanism for reliably broadcasting a signature is application-specific and out of scope for this standard. When the signature is broadcast to a blockchain for use in a contract, the application has to be secure against frontrunning attacks. In this kind of attack, an attacker intercepts the signature and submits it to the contract before the original intended use takes place. The application should behave correctly when the signature is submitted first by an attacker, for example by rejecting it or simply producing exactly the same effect as intended by the signer. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 12 Sep 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-712 https://eips.ethereum.org/EIPS/eip-712 Non-Fungible Token Standard Standards Track/ERC https://github.com/ethereum/eips/issues/721 ## Simple Summary A standard interface for non-fungible tokens, also known as deeds. ## Abstract The following standard allows for the implementation of a standard API for NFTs within smart contracts. This standard provides basic functionality to track and transfer NFTs. We considered use cases of NFTs being owned and transacted by individuals as well as consignment to third party brokers/wallets/auctioneers ("operators"). NFTs can represent ownership over digital or physical assets. We considered a diverse universe of assets, and we know you will dream up many more: - Physical property — houses, unique artwork - Virtual collectibles — unique pictures of kittens, collectible cards - "Negative value" assets — loans, burdens and other responsibilities In general, all houses are distinct and no two kittens are alike. NFTs are *distinguishable* and you must track the ownership of each one separately. ## Motivation A standard interface allows wallet/broker/auction applications to work with any NFT on Ethereum. We provide for simple ERC-721 smart contracts as well as contracts that track an *arbitrarily large* number of NFTs. Additional applications are discussed below. This standard is inspired by the ERC-20 token standard and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking NFTs because each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible). Differences between this standard and EIP-20 are examined below. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. **Every ERC-721 compliant contract must implement the `ERC721` and `ERC165` interfaces** (subject to "caveats" below): ```solidity pragma solidity ^0.4.20; /// @title ERC-721 Non-Fungible Token Standard /// @dev See https://eips.ethereum.org/EIPS/eip-721 /// Note: the ERC-165 identifier for this interface is 0x80ac58cd. interface ERC721 /* is ERC165 */ { /// @dev This emits when ownership of any NFT changes by any mechanism. /// This event emits when NFTs are created (`from` == 0) and destroyed /// (`to` == 0). Exception: during contract creation, any number of NFTs /// may be created and assigned without emitting Transfer. At the time of /// any transfer, the approved address for that NFT (if any) is reset to none. event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); /// @dev This emits when the approved address for an NFT is changed or /// reaffirmed. The zero address indicates there is no approved address. /// When a Transfer event emits, this also indicates that the approved /// address for that NFT (if any) is reset to none. event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); /// @dev This emits when an operator is enabled or disabled for an owner. /// The operator can manage all NFTs of the owner. event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); /// @notice Count all NFTs assigned to an owner /// @dev NFTs assigned to the zero address are considered invalid, and this /// function throws for queries about the zero address. /// @param _owner An address for whom to query the balance /// @return The number of NFTs owned by `_owner`, possibly zero function balanceOf(address _owner) external view returns (uint256); /// @notice Find the owner of an NFT /// @dev NFTs assigned to zero address are considered invalid, and queries /// about them do throw. /// @param _tokenId The identifier for an NFT /// @return The address of the owner of the NFT function ownerOf(uint256 _tokenId) external view returns (address); /// @notice Transfers the ownership of an NFT from one address to another address /// @dev Throws unless `msg.sender` is the current owner, an authorized /// operator, or the approved address for this NFT. Throws if `_from` is /// not the current owner. Throws if `_to` is the zero address. Throws if /// `_tokenId` is not a valid NFT. When transfer is complete, this function /// checks if `_to` is a smart contract (code size > 0). If so, it calls /// `onERC721Received` on `_to` and throws if the return value is not /// `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`. /// @param _from The current owner of the NFT /// @param _to The new owner /// @param _tokenId The NFT to transfer /// @param data Additional data with no specified format, sent in call to `_to` function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; /// @notice Transfers the ownership of an NFT from one address to another address /// @dev This works identically to the other function with an extra data parameter, /// except this function just sets data to "". /// @param _from The current owner of the NFT /// @param _to The new owner /// @param _tokenId The NFT to transfer function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE /// TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE /// THEY MAY BE PERMANENTLY LOST /// @dev Throws unless `msg.sender` is the current owner, an authorized /// operator, or the approved address for this NFT. Throws if `_from` is /// not the current owner. Throws if `_to` is the zero address. Throws if /// `_tokenId` is not a valid NFT. /// @param _from The current owner of the NFT /// @param _to The new owner /// @param _tokenId The NFT to transfer function transferFrom(address _from, address _to, uint256 _tokenId) external payable; /// @notice Change or reaffirm the approved address for an NFT /// @dev The zero address indicates there is no approved address. /// Throws unless `msg.sender` is the current NFT owner, or an authorized /// operator of the current owner. /// @param _approved The new approved NFT controller /// @param _tokenId The NFT to approve function approve(address _approved, uint256 _tokenId) external payable; /// @notice Enable or disable approval for a third party ("operator") to manage /// all of `msg.sender`'s assets /// @dev Emits the ApprovalForAll event. The contract MUST allow /// multiple operators per owner. /// @param _operator Address to add to the set of authorized operators /// @param _approved True if the operator is approved, false to revoke approval function setApprovalForAll(address _operator, bool _approved) external; /// @notice Get the approved address for a single NFT /// @dev Throws if `_tokenId` is not a valid NFT. /// @param _tokenId The NFT to find the approved address for /// @return The approved address for this NFT, or the zero address if there is none function getApproved(uint256 _tokenId) external view returns (address); /// @notice Query if an address is an authorized operator for another address /// @param _owner The address that owns the NFTs /// @param _operator The address that acts on behalf of the owner /// @return True if `_operator` is an approved operator for `_owner`, false otherwise function isApprovedForAll(address _owner, address _operator) external view returns (bool); } interface ERC165 { /// @notice Query if a contract implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 /// @dev Interface identification is specified in ERC-165. This function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceID` and /// `interfaceID` is not 0xffffffff, `false` otherwise function supportsInterface(bytes4 interfaceID) external view returns (bool); } ``` A wallet/broker/auction application MUST implement the **wallet interface** if it will accept safe transfers. ```solidity /// @dev Note: the ERC-165 identifier for this interface is 0x150b7a02. interface ERC721TokenReceiver { /// @notice Handle the receipt of an NFT /// @dev The ERC721 smart contract calls this function on the recipient /// after a `transfer`. This function MAY throw to revert and reject the /// transfer. Return of other than the magic value MUST result in the /// transaction being reverted. /// Note: the contract address is always the message sender. /// @param _operator The address which called `safeTransferFrom` function /// @param _from The address which previously owned the token /// @param _tokenId The NFT identifier which is being transferred /// @param _data Additional data with no specified format /// @return `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))` /// unless throwing function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4); } ``` The **metadata extension** is OPTIONAL for ERC-721 smart contracts (see "caveats", below). This allows your smart contract to be interrogated for its name and for details about the assets which your NFTs represent. ```solidity /// @title ERC-721 Non-Fungible Token Standard, optional metadata extension /// @dev See https://eips.ethereum.org/EIPS/eip-721 /// Note: the ERC-165 identifier for this interface is 0x5b5e139f. interface ERC721Metadata /* is ERC721 */ { /// @notice A descriptive name for a collection of NFTs in this contract function name() external view returns (string _name); /// @notice An abbreviated name for NFTs in this contract function symbol() external view returns (string _symbol); /// @notice A distinct Uniform Resource Identifier (URI) for a given asset. /// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined in RFC /// 3986. The URI may point to a JSON file that conforms to the "ERC721 /// Metadata JSON Schema". function tokenURI(uint256 _tokenId) external view returns (string); } ``` This is the "ERC721 Metadata JSON Schema" referenced above. ```json { "title": "Asset Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this NFT represents" }, "description": { "type": "string", "description": "Describes the asset to which this NFT represents" }, "image": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." } } } ``` The **enumeration extension** is OPTIONAL for ERC-721 smart contracts (see "caveats", below). This allows your contract to publish its full list of NFTs and make them discoverable. ```solidity /// @title ERC-721 Non-Fungible Token Standard, optional enumeration extension /// @dev See https://eips.ethereum.org/EIPS/eip-721 /// Note: the ERC-165 identifier for this interface is 0x780e9d63. interface ERC721Enumerable /* is ERC721 */ { /// @notice Count NFTs tracked by this contract /// @return A count of valid NFTs tracked by this contract, where each one of /// them has an assigned and queryable owner not equal to the zero address function totalSupply() external view returns (uint256); /// @notice Enumerate valid NFTs /// @dev Throws if `_index` >= `totalSupply()`. /// @param _index A counter less than `totalSupply()` /// @return The token identifier for the `_index`th NFT, /// (sort order not specified) function tokenByIndex(uint256 _index) external view returns (uint256); /// @notice Enumerate NFTs assigned to an owner /// @dev Throws if `_index` >= `balanceOf(_owner)` or if /// `_owner` is the zero address, representing invalid NFTs. /// @param _owner An address where we are interested in NFTs owned by them /// @param _index A counter less than `balanceOf(_owner)` /// @return The token identifier for the `_index`th NFT assigned to `_owner`, /// (sort order not specified) function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256); } ``` ### Caveats The 0.4.20 Solidity interface grammar is not expressive enough to document the ERC-721 standard. A contract which complies with ERC-721 MUST also abide by the following: - Solidity issue #3412: The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: `payable`, implicit nonpayable, `view`, and `pure`. Your implementation MUST meet the mutability guarantee in this interface and you MAY meet a stronger guarantee. For example, a `payable` function in this interface may be implemented as nonpayable (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.20 is that you can edit this interface to add stricter mutability before inheriting from your contract. - Solidity issue #3419: A contract that implements `ERC721Metadata` or `ERC721Enumerable` SHALL also implement `ERC721`. ERC-721 implements the requirements of interface ERC-165. - Solidity issue #2330: If a function is shown in this specification as `external` then a contract will be compliant if it uses `public` visibility. As a workaround for version 0.4.20, you can edit this interface to switch to `public` before inheriting from your contract. - Solidity issues #3494, #3544: Use of `this.*.selector` is marked as a warning by Solidity, a future version of Solidity will not mark this as an error. *If a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification.* ## Rationale There are many proposed uses of Ethereum smart contracts that depend on tracking distinguishable assets. Examples of existing or planned NFTs are LAND in Decentraland, the eponymous punks in CryptoPunks, and in-game items using systems like DMarket or EnjinCoin. Future uses include tracking real-world assets, like real-estate (as envisioned by companies like Ubitquity or Propy). It is critical in each of these cases that these items are not "lumped together" as numbers in a ledger, but instead each asset must have its ownership individually and atomically tracked. Regardless of the nature of these assets, the ecosystem will be stronger if we have a standardized interface that allows for cross-functional asset management and sales platforms. **"NFT" Word Choice** "NFT" was satisfactory to nearly everyone surveyed and is widely applicable to a broad universe of distinguishable digital assets. We recognize that "deed" is very descriptive for certain applications of this standard (notably, physical property). *Alternatives considered: distinguishable asset, title, token, asset, equity, ticket* **NFT Identifiers** Every NFT is identified by a unique `uint256` ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair `(contract address, uint256 tokenId)` will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a "black box". Also note that NFTs MAY become invalid (be destroyed). Please see the enumeration functions for a supported enumeration interface. The choice of `uint256` allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to `uint256`. **Transfer Mechanism** ERC-721 standardizes a safe transfer function `safeTransferFrom` (overloaded with and without a `bytes` parameter) and an unsafe function `transferFrom`. Transfers may be initiated by: - The owner of an NFT - The approved address of an NFT - An authorized operator of the current owner of an NFT Additionally, an authorized operator may set the approved address for an NFT. This provides a powerful set of tools for wallet, broker and auction applications to quickly use a *large* number of NFTs. The transfer and accept functions' documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results: - **Disallow transfers if the contract is paused** — prior art, CryptoKitties deployed contract, line 611 - **Blocklist certain address from receiving NFTs** — prior art, CryptoKitties deployed contract, lines 565, 566 - **Disallow unsafe transfers** — `transferFrom` throws unless `_to` equals `msg.sender` or `countOf(_to)` is non-zero or was non-zero previously (because such cases are safe) - **Charge a fee to both parties of a transaction** — require payment when calling `approve` with a non-zero `_approved` if it was previously the zero address, refund payment if calling `approve` with the zero address if it was previously a non-zero address, require payment when calling any transfer function, require transfer parameter `_to` to equal `msg.sender`, require transfer parameter `_to` to be the approved address for the NFT - **Read only NFT registry** — always throw from `safeTransferFrom`, `transferFrom`, `approve` and `setApprovalForAll` Failed transactions will throw, a best practice identified in ERC-223, ERC-677, ERC-827 and OpenZeppelin's implementation of SafeERC20.sol. ERC-20 defined an `allowance` feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue \#438. In ERC-721, there is no allowance because every NFT is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20's original design without problems that have been later discovered. Creation of NFTs ("minting") and destruction of NFTs ("burning") is not included in the specification. Your contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying NFTs. We questioned if the `operator` parameter on `onERC721Received` was necessary. In all cases we could imagine, if the operator was important then that operator could transfer the token to themself and then send it -- then they would be the `from` address. This seems contrived because we consider the operator to be a temporary owner of the token (and transferring to themself is redundant). When the operator sends the token, it is the operator acting on their own accord, NOT the operator acting on behalf of the token holder. This is why the operator and the previous token owner are both significant to the token recipient. *Alternatives considered: only allow two-step ERC-20 style transaction, require that transfer functions never throw, require all functions to return a boolean indicating the success of the operation.* **ERC-165 Interface** We chose Standard Interface Detection (ERC-165) to expose the interfaces that a ERC-721 smart contract supports. A future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your ERC-721 implementation to implement `ERC721Enumerable`, `ERC721Metadata`, or other interfaces by delegating to a separate contract. **Gas and Complexity** (regarding the enumeration extension) This specification contemplates implementations that manage a few and *arbitrarily large* numbers of NFTs. If your application is able to grow then avoid using for/while loops in your code (see CryptoKitties bounty issue \#4). These indicate your contract may be unable to scale and gas costs will rise over time without bound. We have deployed a contract, XXXXERC721, to Testnet which instantiates and tracks 340282366920938463463374607431768211456 different deeds (2^128). That's enough to assign every IPV6 address to an Ethereum account owner, or to track ownership of nanobots a few micron in size and in aggregate totalling half the size of Earth. You can query it from the blockchain. And every function takes less gas than querying the ENS. This illustration makes clear: the ERC-721 standard scales. *Alternatives considered: remove the asset enumeration function if it requires a for-loop, return a Solidity array type from enumeration functions.* **Privacy** Wallets/brokers/auctioneers identified in the motivation section have a strong need to identify which NFTs an owner owns. It may be interesting to consider a use case where NFTs are not enumerable, such as a private registry of property ownership, or a partially-private registry. However, privacy cannot be attained because an attacker can simply (!) call `ownerOf` for every possible `tokenId`. **Metadata Choices** (metadata extension) We have required `name` and `symbol` functions in the metadata extension. Every token EIP and draft we reviewed (ERC-20, ERC-223, ERC-677, ERC-777, ERC-827) included these functions. We remind implementation authors that the empty string is a valid response to `name` and `symbol` if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as *your* contract. How a client may determine which ERC-721 smart contracts are well-known (canonical) is outside the scope of this standard. A mechanism is provided to associate NFTs with URIs. We expect that many implementations will take advantage of this to provide metadata for each NFT. The image size recommendation is taken from Instagram, they probably know much about image usability. The URI MAY be mutable (i.e. it changes from time to time). We considered an NFT representing ownership of a house, in this case metadata about the house (image, occupants, etc.) can naturally change. Metadata is returned as a string value. Currently this is only usable as calling from `web3`, not from other contracts. This is acceptable because we have not considered a use case where an on-blockchain application would query such information. *Alternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough)* **Community Consensus** A significant amount of discussion occurred on the original ERC-721 issue, additionally we held a first live meeting on Gitter that had good representation and well advertised (on Reddit, in the Gitter #ERC channel, and the original ERC-721 issue). Thank you to the participants: - [@ImAllInNow](https://github.com/imallinnow) Rob from DEC Gaming / Presenting Michigan Ethereum Meetup Feb 7 - [@Arachnid](https://github.com/arachnid) Nick Johnson - [@jadhavajay](https://github.com/jadhavajay) Ajay Jadhav from AyanWorks - [@superphly](https://github.com/superphly) Cody Marx Bailey - XRAM Capital / Sharing at hackathon Jan 20 / UN Future of Finance Hackathon. - [@fulldecent](https://github.com/fulldecent) William Entriken A second event was held at ETHDenver 2018 to discuss distinguishable asset standards (notes to be published). We have been very inclusive in this process and invite anyone with questions or contributions into our discussion. However, this standard is written only to support the identified use cases which are listed herein. ## Backwards Compatibility We have adopted `balanceOf`, `totalSupply`, `name` and `symbol` semantics from the ERC-20 specification. An implementation may also include a function `decimals` that returns `uint8(0)` if its goal is to be more compatible with ERC-20 while supporting this standard. However, we find it contrived to require all ERC-721 implementations to support the `decimals` function. Example NFT implementations as of February 2018: - CryptoKitties -- Compatible with an earlier version of this standard. - CryptoPunks -- Partially ERC-20 compatible, but not easily generalizable because it includes auction functionality directly in the contract and uses function names that explicitly refer to the assets as "punks". - Auctionhouse Asset Interface -- The author needed a generic interface for the Auctionhouse ÐApp (currently ice-boxed). His "Asset" contract is very simple, but is missing ERC-20 compatibility, `approve()` functionality, and metadata. This effort is referenced in the discussion for EIP-173. Note: "Limited edition, collectible tokens" like Curio Cards and Rare Pepe are *not* distinguishable assets. They're actually a collection of individual fungible tokens, each of which is tracked by its own smart contract with its own total supply (which may be `1` in extreme cases). The `onERC721Received` function specifically works around old deployed contracts which may inadvertently return 1 (`true`) in certain circumstances even if they don't implement a function (see Solidity DelegateCallReturnValue bug). By returning and checking for a magic value, we are able to distinguish actual affirmative responses versus these vacuous `true`s. ## Test Cases 0xcert ERC-721 Token includes test cases written using Truffle. ## Implementations 0xcert ERC721 -- a reference implementation - MIT licensed, so you can freely use it for your projects - Includes test cases - Active bug bounty, you will be paid if you find errors Su Squares -- an advertising platform where you can rent space and place images - Complete the Su Squares Bug Bounty Program to seek problems with this standard or its implementation - Implements the complete standard and all optional interfaces ERC721ExampleDeed -- an example implementation - Implements using the OpenZeppelin project format XXXXERC721, by William Entriken -- a scalable example implementation - Deployed on testnet with 1 billion assets and supporting all lookups with the metadata extension. This demonstrates that scaling is NOT a problem. ## References **Standards** 1. [ERC-20](/EIPS/eip-20) Token Standard. 1. [ERC-165](/EIPS/eip-165) Standard Interface Detection. 1. [ERC-173](/EIPS/eip-173) Owned Standard. 1. [ERC-223](https://github.com/ethereum/EIPs/issues/223) Token Standard. 1. [ERC-677](https://github.com/ethereum/EIPs/issues/677) `transferAndCall` Token Standard. 1. [ERC-827](https://github.com/ethereum/EIPs/issues/827) Token Standard. 1. Ethereum Name Service (ENS). https://ens.domains 1. Instagram -- What's the Image Resolution? https://help.instagram.com/1631821640426723 1. JSON Schema. https://json-schema.org/ 1. Multiaddr. https://github.com/multiformats/multiaddr 1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt **Issues** 1. The Original ERC-721 Issue. https://github.com/ethereum/eips/issues/721 1. Solidity Issue \#2330 -- Interface Functions are External. https://github.com/ethereum/solidity/issues/2330 1. Solidity Issue \#3412 -- Implement Interface: Allow Stricter Mutability. https://github.com/ethereum/solidity/issues/3412 1. Solidity Issue \#3419 -- Interfaces Can't Inherit. https://github.com/ethereum/solidity/issues/3419 1. Solidity Issue \#3494 -- Compiler Incorrectly Reasons About the `selector` Function. https://github.com/ethereum/solidity/issues/3494 1. Solidity Issue \#3544 -- Cannot Calculate Selector of Function Named `transfer`. https://github.com/ethereum/solidity/issues/3544 1. CryptoKitties Bounty Issue \#4 -- Listing all Kitties Owned by a User is `O(n^2)`. https://github.com/axiomzen/cryptokitties-bounty/issues/4 1. OpenZeppelin Issue \#438 -- Implementation of `approve` method violates ERC20 standard. https://github.com/OpenZeppelin/zeppelin-solidity/issues/438 1. Solidity DelegateCallReturnValue Bug. https://solidity.readthedocs.io/en/develop/bugs.html#DelegateCallReturnValue **Discussions** 1. Reddit (announcement of first live discussion). https://www.reddit.com/r/ethereum/comments/7r2ena/friday_119_live_discussion_on_erc_nonfungible/ 1. Gitter #EIPs (announcement of first live discussion). https://gitter.im/ethereum/EIPs?at=5a5f823fb48e8c3566f0a5e7 1. ERC-721 (announcement of first live discussion). https://github.com/ethereum/eips/issues/721#issuecomment-358369377 1. ETHDenver 2018. https://ethdenver.com **NFT Implementations and Other Projects** 1. CryptoKitties. https://www.cryptokitties.co 1. 0xcert ERC-721 Token. https://github.com/0xcert/ethereum-erc721 1. Su Squares. https://tenthousandsu.com 1. Decentraland. https://decentraland.org 1. CryptoPunks. https://www.larvalabs.com/cryptopunks 1. DMarket. https://www.dmarket.io 1. Enjin Coin. https://enjincoin.io 1. Ubitquity. https://www.ubitquity.io 1. Propy. https://tokensale.propy.com 1. CryptoKitties Deployed Contract. https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#code 1. Su Squares Bug Bounty Program. https://github.com/fulldecent/su-squares-bounty 1. XXXXERC721. https://github.com/fulldecent/erc721-example 1. ERC721ExampleDeed. https://github.com/nastassiasachs/ERC721ExampleDeed 1. Curio Cards. https://mycuriocards.com 1. Rare Pepe. https://rarepepewallet.com 1. Auctionhouse Asset Interface. https://github.com/dob/auctionhouse/blob/master/contracts/Asset.sol 1. [OpenZeppelin `SafeERC20.sol` Implementation](/assets/eip-721/SafeERC20.sol). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 24 Jan 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-721 https://eips.ethereum.org/EIPS/eip-721 General data key/value store and execution Standards Track/ERC https://ethereum-magicians.org/t/discussion-for-eip725/12158 ## Abstract The following describes two standards that allow for a generic data storage in a smart contract and a generic execution through a smart contract. These can be used separately or in conjunction and can serve as building blocks for smart contract accounts, upgradable metadata, and other means. ## Motivation The initial motivation came out of the need to create a smart contract account system that's flexible enough to be viable long-term but also defined enough to be standardized. They are a generic set of two standardized building blocks to be used in all forms of smart contracts. This standard consists of two sub-standards, a generic data key/value store (`ERC725Y`) and a generic execute function (`ERC725X`). Both of these in combination allow for a very flexible and long-lasting account system. The account version of `ERC725` is standardized under `LSP0-ERC725Account`. These standards (`ERC725` X and Y) can also be used separately as `ERC725Y` can be used to enhance NFTs and Token metadata or other types of smart contracts. `ERC725X` allows for a generic execution through a smart contract, functioning as an account or actor. ## Specification ### Ownership This contract is controlled by a single owner. The owner can be a smart contract or an external account. This standard requires [ERC-173](/EIPS/eip-173) and SHOULD implement the functions: - `owner() view` - `transferOwnership(address newOwner)` And the event: - `OwnershipTransferred(address indexed previousOwner, address indexed newOwner)` --- ### `ERC725X` **`ERC725X`** interface id according to [ERC-165](/EIPS/eip-165): `0x7545acac`. Smart contracts implementing the `ERC725X` standard MUST implement the [ERC-165](/EIPS/eip-165) `supportsInterface(..)` function and MUST support the `ERC165` and `ERC725X` interface ids. ### `ERC725X` Methods Smart contracts implementing the `ERC725X` standard SHOULD implement all of the functions listed below: #### execute ```solidity function execute(uint256 operationType, address target, uint256 value, bytes memory data) external payable returns(bytes memory) ``` Function Selector: `0x44c028fe` Executes a call on any other smart contracts or address, transfers the blockchains native token, or deploys a new smart contract. _Parameters:_ - `operationType`: the operation type used to execute. - `target`: the smart contract or address to call. `target` will be unused if a contract is created (operation types 1 and 2). - `value`: the amount of native tokens to transfer (in Wei). - `data`: the call data, or the creation bytecode of the contract to deploy. _Requirements:_ - MUST only be called by the current owner of the contract. - MUST revert when the execution or the contract creation fails. - `target` SHOULD be address(0) in case of contract creation with `CREATE` and `CREATE2` (operation types 1 and 2). - `value` SHOULD be zero in case of `STATICCALL` or `DELEGATECALL` (operation types 3 and 4). _Returns:_ `bytes` , the returned data of the called function, or the address of the contract deployed (operation types 1 and 2). **Triggers Event:** [ContractCreated](#contractcreated), [Executed](#executed) The following `operationType` COULD exist: - `0` for `CALL` - `1` for `CREATE` - `2` for `CREATE2` - `3` for `STATICCALL` - `4` for `DELEGATECALL` - **NOTE** This is a potentially dangerous operation type Others may be added in the future. #### data parameter - For operationType, `CALL`, `STATICCALL` and `DELEGATECALL` the data field can be random bytes or an abi-encoded function call. - For operationType, `CREATE` the `data` field is the creation bytecode of the contract to deploy appended with the constructor argument(s) abi-encoded. - For operationType, `CREATE2` the `data` field is the creation bytecode of the contract to deploy appended with: 1. the constructor argument(s) abi-encoded 2. a `bytes32` salt. ``` data = <contract-creation-code> + <abi-encoded-constructor-arguments> + <bytes32-salt> ``` > See [EIP-1014: Skinny CREATE2](/EIPS/eip-1014) for more information. #### executeBatch ```solidity function executeBatch(uint256[] memory operationsType, address[] memory targets, uint256[] memory values, bytes[] memory datas) external payable returns(bytes[] memory) ``` Function Selector: `0x31858452` Executes a batch of calls on any other smart contracts, transfers the blockchain native token, or deploys a new smart contract. _Parameters:_ - `operationsType`: the list of operations type used to execute. - `targets`: the list of addresses to call. `targets` will be unused if a contract is created (operation types 1 and 2). - `values`: the list of native token amounts to transfer (in Wei). - `datas`: the list of call data, or the creation bytecode of the contract to deploy. _Requirements:_ - Parameters array MUST have the same length. - MUST only be called by the current owner of the contract. - MUST revert when the execution or the contract creation fails. - `target` SHOULD be address(0) in case of contract creation with `CREATE` and `CREATE2` (operation types 1 and 2). - `value` SHOULD be zero in case of `STATICCALL` or `DELEGATECALL` (operation types 3 and 4). _Returns:_ `bytes[]` , array list of returned data of the called function, or the address(es) of the contract deployed (operation types 1 and 2). **Triggers Event:** [ContractCreated](#contractcreated), [Executed](#executed) on each call iteration ### `ERC725X` Events #### Executed ```solidity event Executed(uint256 indexed operationType, address indexed target, uint256 indexed value, bytes4 data); ``` MUST be triggered when `execute` creates a new call using the `operationType` `0`, `3`, `4`. #### ContractCreated ```solidity event ContractCreated(uint256 indexed operationType, address indexed contractAddress, uint256 indexed value, bytes32 salt); ``` MUST be triggered when `execute` creates a new contract using the `operationType` `1`, `2`. --- ### `ERC725Y` **`ERC725Y`** interface id according to [ERC-165](/EIPS/eip-165): `0x629aa694`. Smart contracts implementing the `ERC725Y` standard MUST implement the [ERC-165](/EIPS/eip-165) `supportsInterface(..)` function and MUST support the `ERC165` and `ERC725Y` interface ids. ### `ERC725Y` Methods Smart contracts implementing the `ERC725Y` standard MUST implement all of the functions listed below: #### getData ```solidity function getData(bytes32 dataKey) external view returns(bytes memory) ``` Function Selector: `0x54f6127f` Gets the data set for the given data key. _Parameters:_ - `dataKey`: the data key which value to retrieve. _Returns:_ `bytes` , The data for the requested data key. #### getDataBatch ```solidity function getDataBatch(bytes32[] memory dataKeys) external view returns(bytes[] memory) ``` Function Selector: `0xdedff9c6` Gets array of data at multiple given data keys. _Parameters:_ - `dataKeys`: the data keys which values to retrieve. _Returns:_ `bytes[]` , array of data values for the requested data keys. #### setData ```solidity function setData(bytes32 dataKey, bytes memory dataValue) external ``` Function Selector: `0x7f23690c` Sets data as bytes in the storage for a single data key. _Parameters:_ - `dataKey`: the data key which value to set. - `dataValue`: the data to store. _Requirements:_ - MUST only be called by the current owner of the contract. **Triggers Event:** [DataChanged](#datachanged) #### setDataBatch ```solidity function setDataBatch(bytes32[] memory dataKeys, bytes[] memory dataValues) external ``` Function Selector: `0x97902421` Sets array of data at multiple data keys. MUST only be called by the current owner of the contract. _Parameters:_ - `dataKeys`: the data keys which values to set. - `dataValues`: the array of bytes to set. _Requirements:_ - Array parameters MUST have the same length. - MUST only be called by the current owner of the contract. **Triggers Event:** [DataChanged](#datachanged) ### `ERC725Y` Events #### DataChanged ```solidity event DataChanged(bytes32 indexed dataKey, bytes dataValue) ``` MUST be triggered when a data key was successfully set. ### `ERC725Y` Data keys Data keys, are the way to retrieve values via `getData()`. These `bytes32` values can be freely chosen, or defined by a standard. A common way to define data keys is the hash of a word, e.g. `keccak256('ERCXXXMyNewKeyType')` which results in: `0x6935a24ea384927f250ee0b954ed498cd9203fc5d2bf95c735e52e6ca675e047` The `LSP2-ERC725JSONSchema` standard is a more explicit `ERC725Y` data key standard, that defines key types and value types, and their encoding and decoding. ## Rationale The generic way of storing data keys with values was chosen to allow upgradability over time. Stored data values can be changed over time. Other smart contract protocols can then interpret this data in new ways and react to interactions from a `ERC725` smart contract differently. The data stored in an `ERC725Y` smart contract is not only readable/writable by off-chain applications, but also by other smart contracts. Function overloading was used to allow for the retrievable of single and multiple keys, to keep gas costs minimal for both use cases. ## Backwards Compatibility All contracts since `ERC725v2` from 2018/19 should be compatible with the current version of the standard. Mainly interface ID and Event parameters have changed, while `getData(bytes32[])` and `setData(bytes32[], bytes[])` was added as an efficient way to set/get multiple keys at once. The same applies to execution, as `execute(..[])` was added as an efficient way to batch calls. From 2023 onward, overloading was removed from `ERC-725` (including `ERC725-X` and `ERC725-Y`). This is because, while overloading is accommodated in Solidity, it isn't broadly supported across most blockchain languages. In order to make the standard language-independent, it was decided to shift from overloading to simply attach the term "Batch" to the functions that accept an array as parameters. ## Reference Implementation Reference implementations can be found in [`ERC725.sol`](/assets/eip-725/ERC725.sol). ## Security Considerations This contract allows generic executions, therefore special care needs to be taken to prevent re-entrancy attacks and other forms of call chain attacks. When using the operation type `4` for `delegatecall`, it is important to consider that the called contracts can alter the state of the calling contract and also change owner variables and `ERC725Y` data storage entries at will. Additionally calls to `selfdestruct` are possible and other harmful state-changing operations. ### Solidity Interfaces ```solidity // SPDX-License-Identifier: CC0-1.0 pragma solidity >=0.5.0 <0.7.0; // ERC165 identifier: `0x7545acac` interface IERC725X /* is ERC165, ERC173 */ { event Executed(uint256 indexed operationType, address indexed target, uint256 indexed value, bytes4 data); event ContractCreated(uint256 indexed operationType, address indexed contractAddress, uint256 indexed value, bytes32 salt); function execute(uint256 operationType, address target, uint256 value, bytes memory data) external payable returns(bytes memory); function executeBatch(uint256[] memory operationsType, address[] memory targets, uint256[] memory values, bytes memory datas) external payable returns(bytes[] memory); } // ERC165 identifier: `0x629aa694` interface IERC725Y /* is ERC165, ERC173 */ { event DataChanged(bytes32 indexed dataKey, bytes dataValue); function getData(bytes32 dataKey) external view returns(bytes memory); function getDataBatch(bytes32[] memory dataKeys) external view returns(bytes[] memory); function setData(bytes32 dataKey, bytes memory dataValue) external; function setDataBatch(bytes32[] memory dataKeys, bytes[] memory dataValues) external; } interface IERC725 /* is IERC725X, IERC725Y */ { } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 02 Oct 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-725 https://eips.ethereum.org/EIPS/eip-725 wallet_watchAsset RPC Method Standards Track/Interface https://ethereum-magicians.org/t/eip-747-eth-watchtoken/1048 ## Abstract This EIP standardizes a new wallet-scoped RPC method, `wallet_watchAsset`, to allow a client to suggest a token for the user's wallet to track. ## Motivation Today, one of the major uses of Ethereum wallets is to track users' assets. Without this EIP, each wallet either needs to pre-load a list of approved assets, or users must manually add assets to their wallet. In the first case, wallets are burdened with both the security of managing this list, as well as the bandwidth of mass polling for known assets on their wallet. In the second case, the user experience is terrible. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. A new RPC method, `wallet_watchAsset` is added. `wallet_watchAsset` requests that a specified asset be listed to the user's wallet. It MUST immediately (i.e. before prompting the user) return `true` if the request was valid, or error if it was not. The meaning of "listed to the user's wallet" is dependent on the wallet implementation. A successful call to `wallet_watchAsset` MUST indicate that the wallet recognized the request and that it contained no issues, but doesn't indicate whether the user was prompted or whether the asset was actually added to the wallet. ### `wallet_watchAsset` Parameters The `wallet_watchAsset` method takes a single parameter, a `WatchAssetParameters` object, which is defined as follows: ```typescript interface WatchAssetParameters { type: string; // The asset's interface, e.g. 'ERC1046' options: any; } ``` The `type` string SHOULD be the commonly accepted name of the interface implemented by the asset's contract, e.g. `ERC1046`. Defining the global identifiers for different asset types is beyond the scope of this EIP. This interface SHOULD be extended or modified depending on the asset `type`. These changes MUST be specified in separate EIPs. ### `wallet_watchAsset` Returns `wallet_watchAsset` immediately (i.e. without waiting for user interaction) returns the boolean value `true` to indicate that the request was recognized (regardless of whether the user was prompted), or errors if the request is invalid. An error might occur in the following circumstances (not comprehensive): - The asset type is unrecognized/unsupported - The asset was blocked due to an allowlist or denylist (this makes the request 'invalid' since the root cause requires developer action) - Downloading the image failed to load - The wallet didn't load some of the metadata required to display the asset, in order to protect against a potential SSRF attack ### `ERC1046` type The format of the options field is: ```typescript interface ERC1046WatchAssetOptions { { address: string; // The hexadecimal address of the token contract chainId?: number; // The chain ID of the asset. If empty, defaults to the current chain ID. }; } ``` `address` is required, and the other fields are optional. `address` MUST be the `0x`-prefixed checksummed hexadecimal address of the token contract. `chainId` MUST be the chain ID to which the asset belongs. If the checksum fails, the request MUST be considered invalid. If the wallet does not recognize the `chainId`, or the `chainId` is blank and the wallet does not have a concept of "active" chain, the call MUST fail. `wallet_watchAsset` MUST fetch the [ERC-1046](/EIPS/eip-1046) `tokenURI` and check the `interop` field to determine the type of the token. If the parsing fails, or the type is unknown, the RPC call MUST error. `wallet_watchAsset` SHOULD check the `name` and `symbol` fields, and the contract `address` and `chainId` against a list of well-known tokens. If the name and/or symbol are similar to ones on the list but the `chainId`/`address` don't match, a warning SHOULD be presented to the user. The wallet SHOULD whitelist and/or blacklist specific ports and schemes to avoid SSRF attacks. ### Legacy `ERC20` type The format of the options field is: ```typescript interface ERC20WatchAssetOptions { { address: string; // The hexadecimal address of the token contract chainId?: number; // The chain ID of the asset. If empty, defaults to the current chain ID. }; } ``` `address` is required, and the other fields are optional. `address` MUST be the `0x`-prefixed checksummed hexadecimal address of the token contract. `chainId` MUST be the chain ID to which the asset belongs. If the checksum fails, the request MUST be considered invalid. If the wallet does not recognize the `chainId`, or the `chainId` is blank and the wallet does not have a concept of "active" chain, the call MUST fail. `wallet_watchAsset` SHOULD check the `name` and `symbol` fields, and the contract `address` and `chainId` against a list of well-known tokens. If the name and/or symbol are similar to ones on the list but the `chainId`/`address` don't match, a warning SHOULD be presented to the user. If possible, it is RECOMMENDED to instead use the `ERC1046` type, which supports images and custom metadata. ## Rationale Displaying a user's assets is a basic feature that every modern DApp user expects. Most wallets currently either manage their own asset lists, which they store client-side, or they query a centralized API for balances, which reduces decentralization and allows correlating account holders with IP addresses. Additionally, refreshing/polling an asset list from the network can be costly, especially on bandwidth-constrained devices. Also, maintaining an asset list becomes a political act, provoking harassment and inducing pressure to list obscure assets. Automatically listing assets makes assets into a sort of spam mail: Users suddenly see new assets that they don't care about in their wallet. This can be used to send unsolicited information, or even to conduct phishing scams. This phenomenon is already common with airdropped tokens, a major cause of network congestion, because spamming people with new tokens has, so far, been rewarded with increased user attention. When a user is manually adding an asset, they had likely previously learned about it from a website. At that moment, there was a natural alignment of interests, where both parties wanted the user to track the token. This is a natural point to introduce an API to easily allow these parties to collaborate. ## Security Considerations ### Server-Side Request Forgery Wallets should be careful about making arbitrary requests to URLs. As such, it is recommended for wallets to sanitize the URI by whitelisting specific schemes and ports. A vulnerable wallet could be tricked into, for example, modifying data on a locally-hosted redis database. ### Validation Wallets should warn users if the symbol or name matches or is similar to another token, to avoid phishing scams. ### Fingerprinting To avoid fingerprinting based on wallet behavior and/or listed assets, the RPC call must return as soon as the user is prompted or an error occurs, without waiting for the user to accept or deny the prompt. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 13 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-747 https://eips.ethereum.org/EIPS/eip-747 Subscriptions and filters for completed transactions Standards Track/Interface ## Simple Summary Provide a way for external callers to be notified of completed transactions, and access the return data of functions executed when a transaction is mined. ## Abstract When a new transaction is submitted successfully to an Ethereum node, the node responds with the transaction's hash. If the transaction involved the execution of a contract function that returns data, the data is discarded. If the return data is state-dependent, which is common, there is no straightforward way for the caller to access or compute the return data. This EIP proposes that callers should be able to subscribe to (or poll for) completed transactions. The Ethereum node sends the return data to the caller when the transactions are sealed. ## Motivation External callers presently have no way of accessing return data from Ethereum, if the function was executed via `eth_sendTransaction` or `eth_sendRawTransaction` RPC request. Access to function return data is in many cases a desirable feature. Making return data available to external callers also addresses the inconsistency between internal callers, which have access to return data within the context of the transaction, and external callers, which do not. Presently, a common workaround is to log the return data, which is bad for several reasons: it contributes to chain bloat, imposes additional gas costs on the caller, and can result in unused logs being written if the externally called function involves other (internal) function calls that log their return data. While implementing the original version of this EIP, it was decided to expand this functionality slightly to allow for external callers to be notified of their completed transactions even in the case where there is *no* return data. This could be either because the method called doesn't return a value, or because the transaction is a simple transfer of value. ## Specification ### Subscription A caller who wants to be notified when transactions of theirs complete sends an `eth_subscribe` RPC request with the first parameter `"completedTransaction"`: ```json {"jsonrpc": "2.0", "id": 1, "method": "eth_subscribe", "params": ["completedTransaction", filter]} ``` The `filter` parameter is a dictionary containing 3 optional named arguments: `from`, `to`, and `hasReturnData`. `from` and `to` can each either be single addresses, or a list of addresses. They are used to filter out any transactions not sent from an address in the `from` list and sent to an address in the to list. `hasReturnData` is a boolean--if it is specified and `true`, then notifications will be received only for completed transactions containing returnData. For example, to restrict results to contract creations originating from either of two addresses (0x3f7d39bDBf1f5cE649c194571aEd3D2BbB2F85ce or 0x7097f41F1C1847D52407C629d0E0ae0fDD24fd58): ```json filter = { "from" : ["0x3f7d39bDBf1f5cE649c194571aEd3D2BbB2F85ce", "0x7097f41F1C1847D52407C629d0E0ae0fDD24fd58"], "to" : "0x0" } ``` To restrict results to method calls on contract address 0xD9Cb531aB97A652c8fC60dcF6D263fcA2F5764e9: ```json filter = { "to" : "0xD9Cb531aB97A652c8fC60dcF6D263fcA2F5764e9", "hasReturnData" : true } ``` Or to be notified of any transactions submitted by this rpc client when they complete, with no further restrictions: ```json filter = {} ``` After the request is received, the Ethereum node responds with a subscription ID: ```json {"jsonrpc": "2.0", "id": 1, "result": "0x00000000000000000000000000000b0b"} ``` Suppose the caller then submits a transaction via `eth_sendTransaction` or `eth_sendRawTransaction` RPC request which has the transaction hash `"0x00000000000000000000000000000000000000000000000000000000deadbeef"`. When the transaction is sealed (mined), the Ethereum node pushes a notification to the caller. If the transaction is a method call on a contract, this will include the return value (eg. `"0x000000000000000000000000000000000000000000000000000000000000002a"`) of the called function: ```json { "jsonrpc": "2.0", "method": "eth_subscription", "params": { "result": { "transactionHash": "0x00000000000000000000000000000000000000000000000000000000deadbeef", "returnData": "0x000000000000000000000000000000000000000000000000000000000000002a" }, "subscription": "0x00000000000000000000000000000b0b" } } ``` The caller receives notifications about their transactions in two cases: first when a transaction is sealed, and again (with an extra `"removed": true` field) if a transaction is affected by a chain reorganization. Notifications are sent to the client for all transactions submitted from the client that are sealed _after_ subscribing. If `from`, `to`, or `hasReturnData` is specified, then only those matching the filter criteria will generate notifications. As with other subscriptions, the caller can send an `eth_unsubscribe` RPC request to stop receiving push notifications: ```json {"jsonrpc": "2.0", "id": 2, "method": "eth_unsubscribe", "params": ["0x00000000000000000000000000000b0b"]} ``` ### Polling Push notifications require full duplex connections (i.e., websocket or IPC). Instead of subscribing, callers using HTTP send an `eth_newCompletedTransactionFilter` request: ```json {"jsonrpc": "2.0", "id": 1, "method": "eth_newCompletedTransactionFilter", "params": [filter] } ``` The Ethereum node responds with a filter ID: ```json {"jsonrpc": "2.0", "id": 1, "result": "0x1"} ``` When a transaction is submitted, the Ethereum node pushes the transaction notification, including return value, into a queue which is emptied when the caller polls using `eth_getFilterChanges`: ```json {"jsonrpc": "2.0", "id": 2, "method": "eth_getFilterChanges", "params": ["0x1"]} ``` The node responds with an array of transaction hashes and their corresponding return data, in the order they were computed: ```json { "jsonrpc": "2.0", "id": 2, "result": [{ "transactionHash": "0x00000000000000000000000000000000000000000000000000000000deadbeef", "returnData": "0x000000000000000000000000000000000000000000000000000000000000002a" }] } ``` All transactions that were sealed _after_ the initial `eth_newCompletedTransactionFilter` request are included in this array. Again, if the `filter` param is a non-empty dictionary (contains either `from`, `to`, or `hasReturnData`) then only transactions matching the filter criteria generate notifications. Note that in the polling case, there is no way for the Ethereum node to be sure that an RPC client which submits a transaction was the same as the one who created the filter, so there is no restriction based on where the transaction was submitted. ## Rationale [EIP-658](/EIPS/eip-658) originally proposed adding return data to transaction receipts. However, return data is not charged for (as it is not stored on the blockchain), so adding it to transaction receipts could result in DoS and spam opportunities. Instead, a simple Boolean `status` field was added to transaction receipts. This modified version of EIP 658 was included in the Byzantium hard fork. While the `status` field is useful, applications often need the return data as well. The primary advantage of using the strategy outlined here is efficiency: no extra data needs to be stored on the blockchain, and minimal extra computational load is imposed on nodes. Although after-the-fact lookups of the return value would not be supported, this is consistent with the conventional use of return data, which are only accessible to the caller when the function returns, and are not stored for later use. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 09 Nov 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-758 https://eips.ethereum.org/EIPS/eip-758 Token Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/777 ## Simple Summary This EIP defines standard interfaces and behaviors for token contracts. ## Abstract This standard defines a new way to interact with a token contract while remaining backward compatible with [ERC-20]. It defines advanced features to interact with tokens. Namely, *operators* to send tokens on behalf of another address&mdash;contract or regular account&mdash;and send/receive *hooks* to offer token holders more control over their tokens. It takes advantage of [ERC-1820] to find out whether and where to notify contracts and regular addresses when they receive tokens as well as to allow compatibility with already-deployed contracts. ## Motivation This standard tries to improve upon the widely used [ERC-20] token standard. The main advantages of this standard are: 1. Uses the same philosophy as Ether in that tokens are sent with `send(dest, value, data)`. 2. Both contracts and regular addresses can control and reject which token they send by registering a `tokensToSend` hook. (Rejection is done by `revert`ing in the hook function.) 3. Both contracts and regular addresses can control and reject which token they receive by registering a `tokensReceived` hook. (Rejection is done by `revert`ing in the hook function.) 4. The `tokensReceived` hook allows to send tokens to a contract and notify it in a single transaction, unlike [ERC-20] which requires a double call (`approve`/`transferFrom`) to achieve this. 5. The holder can "authorize" and "revoke" operators which can send tokens on their behalf. These operators are intended to be verified contracts such as an exchange, a cheque processor or an automatic charging system. 6. Every token transaction contains `data` and `operatorData` bytes fields to be used freely to pass data from the holder and the operator, respectively. 7. It is backward compatible with wallets that do not contain the `tokensReceived` hook function by deploying a proxy contract implementing the `tokensReceived` hook for the wallet. ## Specification ### ERC777Token (Token Contract) ``` solidity interface ERC777Token { function name() external view returns (string memory); function symbol() external view returns (string memory); function totalSupply() external view returns (uint256); function balanceOf(address holder) external view returns (uint256); function granularity() external view returns (uint256); function defaultOperators() external view returns (address[] memory); function isOperatorFor( address operator, address holder ) external view returns (bool); function authorizeOperator(address operator) external; function revokeOperator(address operator) external; function send(address to, uint256 amount, bytes calldata data) external; function operatorSend( address from, address to, uint256 amount, bytes calldata data, bytes calldata operatorData ) external; function burn(uint256 amount, bytes calldata data) external; function operatorBurn( address from, uint256 amount, bytes calldata data, bytes calldata operatorData ) external; event Sent( address indexed operator, address indexed from, address indexed to, uint256 amount, bytes data, bytes operatorData ); event Minted( address indexed operator, address indexed to, uint256 amount, bytes data, bytes operatorData ); event Burned( address indexed operator, address indexed from, uint256 amount, bytes data, bytes operatorData ); event AuthorizedOperator( address indexed operator, address indexed holder ); event RevokedOperator(address indexed operator, address indexed holder); } ``` The token contract MUST implement the above interface. The implementation MUST follow the specifications described below. The token contract MUST register the `ERC777Token` interface with its own address via [ERC-1820]. > This is done by calling the `setInterfaceImplementer` function on the [ERC-1820] registry > with the token contract address as both the address and the implementer > and the `keccak256` hash of `ERC777Token` (`0xac7fbab5f54a3ca8194167523c6753bfeb96a445279294b6125b68cce2177054`) > as the interface hash. If the contract has a switch to enable or disable ERC-777 functions, every time the switch is triggered, the token MUST register or unregister the `ERC777Token` interface for its own address accordingly via ERC1820. Unregistering implies calling the `setInterfaceImplementer` with the token contract address as the address, the `keccak256` hash of `ERC777Token` as the interface hash and `0x0` as the implementer. (See [Set An Interface For An Address][erc1820-set] in [ERC-1820] for more details.) When interacting with the token contract, all amounts and balances MUST be unsigned integers. I.e. internally, all values are stored as a denomination of 1E-18 of a token. The display denomination&mdash;to display any amount to the end user&mdash;MUST be 10<sup>18</sup> of the internal denomination. In other words, the internal denomination is similar to a wei and the display denomination is similar to an ether. It is equivalent to an [ERC-20]'s `decimals` function returning `18`. E.g. if a token contract returns a balance of `500,000,000,000,000,000` (0.5&times;10<sup>18</sup>) for a user, the user interface MUST show `0.5` tokens to the user. If the user wishes to send `0.3` tokens, the contract MUST be called with an amount of `300,000,000,000,000,000` (0.3&times;10<sup>18</sup>). User Interfaces which are generated programmatically from the ABI of the token contract MAY use and display the internal denomination. But this MUST be made clear, for example by displaying the `uint256` type. #### **View Functions** The `view` functions detailed below MUST be implemented. **`name` function** ``` solidity function name() external view returns (string memory) ``` Get the name of the token, e.g., `"MyToken"`. > <small>**identifier:** `06fdde03`</small> > <small>**returns:** Name of the token.</small> **`symbol` function** ``` solidity function symbol() external view returns (string memory) ``` Get the symbol of the token, e.g., `"MYT"`. > <small>**identifier:** `95d89b41`</small> > <small>**returns:** Symbol of the token.</small> **`totalSupply` function** ``` solidity function totalSupply() external view returns (uint256) ``` Get the total number of minted tokens. *NOTE*: The total supply MUST be equal to the sum of the balances of all addresses&mdash;as returned by the `balanceOf` function. *NOTE*: The total supply MUST be equal to the sum of all the minted tokens as defined in all the `Minted` events minus the sum of all the burned tokens as defined in all the `Burned` events. > <small>**identifier:** `18160ddd`</small> > <small>**returns:** Total supply of tokens currently in circulation.</small> **`balanceOf` function** ``` solidity function balanceOf(address holder) external view returns (uint256) ``` Get the balance of the account with address `holder`. The balance MUST be zero (`0`) or higher. > <small>**identifier:** `70a08231`</small> > <small>**parameters**</small> > <small>`holder`: Address for which the balance is returned.</small> > > <small>**returns:** Amount of tokens held by `holder` in the token contract.</small> **`granularity` function** ``` solidity function granularity() external view returns (uint256) ``` Get the smallest part of the token that's not divisible. In other words, the granularity is the smallest amount of tokens (in the internal denomination) which MAY be minted, sent or burned at any time. The following rules MUST be applied regarding the *granularity*: - The *granularity* value MUST be set at creation time. - The *granularity* value MUST NOT be changed, ever. - The *granularity* value MUST be greater than or equal to `1`. - All balances MUST be a multiple of the granularity. - Any amount of tokens (in the internal denomination) minted, sent or burned MUST be a multiple of the *granularity* value. - Any operation that would result in a balance that's not a multiple of the *granularity* value MUST be considered invalid, and the transaction MUST `revert`. *NOTE*: Most tokens SHOULD be fully partition-able. I.e., this function SHOULD return `1` unless there is a good reason for not allowing any fraction of the token. > <small>**identifier:** `556f0dc7`</small> > <small>**returns:** The smallest non-divisible part of the token.</small> *NOTE*: [`defaultOperators`][defaultOperators] and [`isOperatorFor`][isOperatorFor] are also `view` functions, defined under the [operators] for consistency. *[ERC-20] compatibility requirement*: The decimals of the token MUST always be `18`. For a *pure* ERC-777 token the [ERC-20] `decimals` function is OPTIONAL, and its existence SHALL NOT be relied upon when interacting with the token contract. (The decimal value of `18` is implied.) For an [ERC-20] compatible token, the `decimals` function is REQUIRED and MUST return `18`. (In [ERC-20], the `decimals` function is OPTIONAL. If the function is not present, the `decimals` value is not clearly defined and may be assumed to be `0`. Hence for compatibility reasons, `decimals` MUST be implemented for [ERC-20] compatible tokens.) #### **Operators** An `operator` is an address which is allowed to send and burn tokens on behalf of some *holder*. When an address becomes an *operator* for a *holder*, an `AuthorizedOperator` event MUST be emitted. The `AuthorizedOperator`'s `operator` (topic 1) and `holder` (topic 2) MUST be the addresses of the *operator* and the *holder* respectively. When a *holder* revokes an *operator*, a `RevokedOperator` event MUST be emitted. The `RevokedOperator`'s `operator` (topic 1) and `holder` (topic 2) MUST be the addresses of the *operator* and the *holder* respectively. *NOTE*: A *holder* MAY have multiple *operators* at the same time. The token MAY define *default operators*. A *default operator* is an implicitly authorized *operator* for all *holders*. `AuthorizedOperator` events MUST NOT be emitted when defining the *default operators*. The rules below apply to *default operators*: - The token contract MUST define *default operators* at creation time. - The *default operators* MUST be invariants. I.e., the token contract MUST NOT add or remove *default operators* ever. - `AuthorizedOperator` events MUST NOT be emitted when defining *default operators*. - A *holder* MUST be allowed to revoke a *default operator* (unless the *holder* is the *default operator* in question). - A *holder* MUST be allowed to re-authorize a previously revoked *default operator*. - When a *default operator* is explicitly authorized or revoked for a specific *holder*, an `AuthorizedOperator` or `RevokedOperator` event (respectively) MUST be emitted. The following rules apply to any *operator*: - An address MUST always be an *operator* for itself. Hence an address MUST NOT ever be revoked as its own *operator*. - If an address is an *operator* for a *holder*, `isOperatorFor` MUST return `true`. - If an address is not an *operator* for a *holder*, `isOperatorFor` MUST return `false`. - The token contract MUST emit an `AuthorizedOperator` event with the correct values when a *holder* authorizes an address as its *operator* as defined in the [`AuthorizedOperator` Event][authorizedoperator]. - The token contract MUST emit a `RevokedOperator` event with the correct values when a *holder* revokes an address as its *operator* as defined in the [`RevokedOperator` Event][revokedoperator]. *NOTE*: A *holder* MAY authorize an already authorized *operator*. An `AuthorizedOperator` MUST be emitted each time. *NOTE*: A *holder* MAY revoke an already revoked *operator*. A `RevokedOperator` MUST be emitted each time. **`AuthorizedOperator` event** <a id="authorizedoperator"></a> ``` solidity event AuthorizedOperator(address indexed operator, address indexed holder) ``` Indicates the authorization of `operator` as an *operator* for `holder`. *NOTE*: This event MUST NOT be emitted outside of an *operator* authorization process. > <small>**parameters**</small> > <small>`operator`: Address which became an *operator* of `holder`.</small> > <small>`holder`: Address of a *holder* which authorized the `operator` address as an *operator*.</small> **`RevokedOperator` event** <a id="revokedoperator"></a> ``` solidity event RevokedOperator(address indexed operator, address indexed holder) ``` Indicates the revocation of `operator` as an *operator* for `holder`. *NOTE*: This event MUST NOT be emitted outside of an *operator* revocation process. > <small>**parameters**</small> > <small>`operator`: Address which was revoked as an *operator* of `holder`.</small> > <small>`holder`: Address of a *holder* which revoked the `operator` address as an *operator*.</small> The `defaultOperators`, `authorizeOperator`, `revokeOperator` and `isOperatorFor` functions described below MUST be implemented to manage *operators*. Token contracts MAY implement other functions to manage *operators*. **`defaultOperators` function** <a id="defaultOperators"></a> ``` solidity function defaultOperators() external view returns (address[] memory) ``` Get the list of *default operators* as defined by the token contract. *NOTE*: If the token contract does not have any *default operators*, this function MUST return an empty list. > <small>**identifier:** `06e48538`</small> > <small>**returns:** List of addresses of all the *default operators*.</small> **`authorizeOperator` function** ``` solidity function authorizeOperator(address operator) external ``` Set a third party `operator` address as an *operator* of `msg.sender` to send and burn tokens on its behalf. *NOTE*: The *holder* (`msg.sender`) is always an *operator* for itself. This right SHALL NOT be revoked. Hence this function MUST `revert` if it is called to authorize the holder (`msg.sender`) as an *operator* for itself (i.e. if `operator` is equal to `msg.sender`). > <small>**identifier:** `959b8c3f`</small> > <small>**parameters**</small> > <small>`operator`: Address to set as an *operator* for `msg.sender`.</small> **`revokeOperator` function** ``` solidity function revokeOperator(address operator) external ``` Remove the right of the `operator` address to be an *operator* for `msg.sender` and to send and burn tokens on its behalf. *NOTE*: The *holder* (`msg.sender`) is always an *operator* for itself. This right SHALL NOT be revoked. Hence this function MUST `revert` if it is called to revoke the holder (`msg.sender`) as an *operator* for itself (i.e., if `operator` is equal to `msg.sender`). > <small>**identifier:** `fad8b32a`</small> > <small>**parameters**</small> > <small>`operator`: Address to rescind as an *operator* for `msg.sender`.</small> **`isOperatorFor` function** <a id="isOperatorFor"></a> ``` solidity function isOperatorFor( address operator, address holder ) external view returns (bool) ``` Indicate whether the `operator` address is an *operator* of the `holder` address. > <small>**identifier:** `d95b6371`</small> > <small>**parameters**</small> > <small>`operator`: Address which may be an *operator* of `holder`.</small> > <small>`holder`: Address of a *holder* which may have the `operator` address as an *operator*.</small> > > <small>**returns:** `true` if `operator` is an *operator* of `holder` and `false` otherwise.</small> *NOTE*: To know which addresses are *operators* for a given *holder*, one MUST call `isOperatorFor` with the *holder* for each *default operator* and parse the `AuthorizedOperator`, and `RevokedOperator` events for the *holder* in question. #### **Sending Tokens** When an *operator* sends an `amount` of tokens from a *holder* to a *recipient* with the associated `data` and `operatorData`, the token contract MUST apply the following rules: - Any authorized *operator* MAY send tokens to any *recipient* (except to `0x0`). - The balance of the *holder* MUST be decreased by the `amount`. - The balance of the *recipient* MUST be increased by the `amount`. - The balance of the *holder* MUST be greater or equal to the `amount`&mdash;such that its resulting balance is greater or equal to zero (`0`) after the send. - The token contract MUST emit a `Sent` event with the correct values as defined in the [`Sent` Event][sent]. - The *operator* MAY include information in the `operatorData`. - The token contract MUST call the `tokensToSend` hook of the *holder* if the *holder* registers an `ERC777TokensSender` implementation via [ERC-1820]. - The token contract MUST call the `tokensReceived` hook of the *recipient* if the *recipient* registers an `ERC777TokensRecipient` implementation via [ERC-1820]. - The `data` and `operatorData` MUST be immutable during the entire send process&mdash;hence the same `data` and `operatorData` MUST be used to call both hooks and emit the `Sent` event. The token contract MUST `revert` when sending in any of the following cases: - The *operator* address is not an authorized operator for the *holder*. - The resulting *holder* balance or *recipient* balance after the send is not a multiple of the *granularity* defined by the token contract. - The *recipient* is a contract, and it does not implement the `ERC777TokensRecipient` interface via [ERC-1820]. - The address of the *holder* or the *recipient* is `0x0`. - Any of the resulting balances becomes negative, i.e. becomes less than zero (`0`). - The `tokensToSend` hook of the *holder* `revert`s. - The `tokensReceived` hook of the *recipient* `revert`s. The token contract MAY send tokens from many *holders*, to many *recipients*, or both. In this case: - The previous send rules MUST apply to all the *holders* and all the *recipients*. - The sum of all the balances incremented MUST be equal to the total sent `amount`. - The sum of all the balances decremented MUST be equal to the total sent `amount`. - A `Sent` event MUST be emitted for every *holder* and *recipient* pair with the corresponding amount for each pair. - The sum of all the amounts from the `Sent` event MUST be equal to the total sent `amount`. *NOTE*: Mechanisms such as applying a fee on a send is considered as a send to multiple *recipients*: the intended *recipient* and the fee *recipient*. *NOTE*: Movements of tokens MAY be chained. For example, if a contract upon receiving tokens sends them further to another address. In this case, the previous send rules apply to each send, in order. *NOTE*: Sending an amount of zero (`0`) tokens is valid and MUST be treated as a regular send. *Implementation Requirement*: - The token contract MUST call the `tokensToSend` hook *before* updating the state. - The token contract MUST call the `tokensReceived` hook *after* updating the state. I.e., `tokensToSend` MUST be called first, then the balances MUST be updated to reflect the send, and finally `tokensReceived` MUST be called *afterward*. Thus a `balanceOf` call within `tokensToSend` returns the balance of the address *before* the send and a `balanceOf` call within `tokensReceived` returns the balance of the address *after* the send. *NOTE*: The `data` field contains information provided by the *holder*&mdash;similar to the data field in a regular ether send transaction. The `tokensToSend()` hook, the `tokensReceived()`, or both MAY use the information to decide if they wish to reject the transaction. *NOTE*: The `operatorData` field is analogous to the `data` field except it SHALL be provided by the *operator*. The `operatorData` MUST only be provided by the *operator*. It is intended more for logging purposes and particular cases. (Examples include payment references, cheque numbers, countersignatures and more.) In most of the cases the recipient would ignore the `operatorData`, or at most, it would log the `operatorData`. **`Sent` event** <a id="sent"></a> ``` solidity event Sent( address indexed operator, address indexed from, address indexed to, uint256 amount, bytes data, bytes operatorData ) ``` Indicate a send of `amount` of tokens from the `from` address to the `to` address by the `operator` address. *NOTE*: This event MUST NOT be emitted outside of a send or an [ERC-20] transfer process. > <small>**parameters**</small> > <small>`operator`: Address which triggered the send.</small> > <small>`from`: *Holder* whose tokens were sent.</small> > <small>`to`: Recipient of the tokens.</small> > <small>`amount`: Number of tokens sent.</small> > <small>`data`: Information provided by the *holder*.</small> > <small>`operatorData`: Information provided by the *operator*.</small> The `send` and `operatorSend` functions described below MUST be implemented to send tokens. Token contracts MAY implement other functions to send tokens. **`send` function** ``` solidity function send(address to, uint256 amount, bytes calldata data) external ``` Send the `amount` of tokens from the address `msg.sender` to the address `to`. The *operator* and the *holder* MUST both be the `msg.sender`. > <small>**identifier:** `9bd9bbc6`</small> > <small>**parameters**</small> > <small>`to`: Recipient of the tokens.</small> > <small>`amount`: Number of tokens to send.</small> > <small>`data`: Information provided by the *holder*.</small> **`operatorSend` function** ``` solidity function operatorSend( address from, address to, uint256 amount, bytes calldata data, bytes calldata operatorData ) external ``` Send the `amount` of tokens on behalf of the address `from` to the address `to`. *Reminder*: If the *operator* address is not an authorized operator of the `from` address, then the send process MUST `revert`. *NOTE*: `from` and `msg.sender` MAY be the same address. I.e., an address MAY call `operatorSend` for itself. This call MUST be equivalent to `send` with the addition that the *operator* MAY specify an explicit value for `operatorData` (which cannot be done with the `send` function). > <small>**identifier:** `62ad1b83`</small> > <small>**parameters**</small> > <small>`from`: *Holder* whose tokens are being sent.</small> > <small>`to`: Recipient of the tokens.</small> > <small>`amount`: Number of tokens to send.</small> > <small>`data`: Information provided by the *holder*.</small> > <small>`operatorData`: Information provided by the *operator*.</small> #### **Minting Tokens** Minting tokens is the act of producing new tokens. [ERC-777] intentionally does not define specific functions to mint tokens. This intent comes from the wish not to limit the use of the [ERC-777] standard as the minting process is generally specific for every token. Nonetheless, the rules below MUST be respected when minting for a *recipient*: - Tokens MAY be minted for any *recipient* address (except `0x0`). - The total supply MUST be increased by the amount of tokens minted. - The balance of `0x0` MUST NOT be decreased. - The balance of the *recipient* MUST be increased by the amount of tokens minted. - The token contract MUST emit a `Minted` event with the correct values as defined in the [`Minted` Event][minted]. - The token contract MUST call the `tokensReceived` hook of the *recipient* if the *recipient* registers an `ERC777TokensRecipient` implementation via [ERC-1820]. - The `data` and `operatorData` MUST be immutable during the entire mint process&mdash;hence the same `data` and `operatorData` MUST be used to call the `tokensReceived` hook and emit the `Minted` event. The token contract MUST `revert` when minting in any of the following cases: - The resulting *recipient* balance after the mint is not a multiple of the *granularity* defined by the token contract. - The *recipient* is a contract, and it does not implement the `ERC777TokensRecipient` interface via [ERC-1820]. - The address of the *recipient* is `0x0`. - The `tokensReceived` hook of the *recipient* `revert`s. *NOTE*: The initial token supply at the creation of the token contract MUST be considered as minting for the amount of the initial supply to the address(es) receiving the initial supply. This means one or more `Minted` events must be emitted and the `tokensReceived` hook of the recipient(s) MUST be called. *[ERC-20] compatibility requirement*: While a `Sent` event MUST NOT be emitted when minting, if the token contract is [ERC-20] backward compatible, a `Transfer` event with the `from` parameter set to `0x0` SHOULD be emitted as defined in the [ERC-20] standard. The token contract MAY mint tokens for multiple *recipients* at once. In this case: - The previous mint rules MUST apply to all the *recipients*. - The sum of all the balances incremented MUST be equal to the total minted amount. - A `Minted` event MUST be emitted for every *recipient* with the corresponding amount for each *recipient*. - The sum of all the amounts from the `Minted` event MUST be equal to the total minted `amount`. *NOTE*: Minting an amount of zero (`0`) tokens is valid and MUST be treated as a regular mint. *NOTE*: While during a send or a burn, the data is provided by the *holder*, it is inapplicable for a mint. In this case the data MAY be provided by the token contract or the *operator*, for example to ensure a successful minting to a *holder* expecting specific data. *NOTE*: The `operatorData` field contains information provided by the *operator*&mdash;similar to the data field in a regular ether send transaction. The `tokensReceived()` hooks MAY use the information to decide if it wish to reject the transaction. **`Minted` event** <a id="minted"></a> ``` solidity event Minted( address indexed operator, address indexed to, uint256 amount, bytes data, bytes operatorData ) ``` Indicate the minting of `amount` of tokens to the `to` address by the `operator` address. *NOTE*: This event MUST NOT be emitted outside of a mint process. > <small>**parameters**</small> > <small>`operator`: Address which triggered the mint.</small> > <small>`to`: Recipient of the tokens.</small> > <small>`amount`: Number of tokens minted.</small> > <small>`data`: Information provided for the *recipient*.</small> > <small>`operatorData`: Information provided by the *operator*.</small> #### **Burning Tokens** Burning tokens is the act of destroying existing tokens. [ERC-777] explicitly defines two functions to burn tokens (`burn` and `operatorBurn`). These functions facilitate the integration of the burning process in wallets and dapps. However, the token contract MAY prevent some or all *holders* from burning tokens for any reason. The token contract MAY also define other functions to burn tokens. The rules below MUST be respected when burning the tokens of a *holder*: - Tokens MAY be burned from any *holder* address (except `0x0`). - The total supply MUST be decreased by the amount of tokens burned. - The balance of `0x0` MUST NOT be increased. - The balance of the *holder* MUST be decreased by amount of tokens burned. - The token contract MUST emit a `Burned` event with the correct values as defined in the [`Burned` Event][burned]. - The token contract MUST call the `tokensToSend` hook of the *holder* if the *holder* registers an `ERC777TokensSender` implementation via [ERC-1820]. - The `operatorData` MUST be immutable during the entire burn process&mdash;hence the same `operatorData` MUST be used to call the `tokensToSend` hook and emit the `Burned` event. The token contract MUST `revert` when burning in any of the following cases: - The *operator* address is not an authorized operator for the *holder*. - The resulting *holder* balance after the burn is not a multiple of the *granularity* defined by the token contract. - The balance of *holder* is inferior to the amount of tokens to burn (i.e., resulting in a negative balance for the *holder*). - The address of the *holder* is `0x0`. - The `tokensToSend` hook of the *holder* `revert`s. *[ERC-20] compatibility requirement*: While a `Sent` event MUST NOT be emitted when burning; if the token contract is [ERC-20] enabled, a `Transfer` event with the `to` parameter set to `0x0` SHOULD be emitted. The [ERC-20] standard does not define the concept of burning tokens, but this is a commonly accepted practice. The token contract MAY burn tokens for multiple *holders* at once. In this case: - The previous burn rules MUST apply to each *holders*. - The sum of all the balances decremented MUST be equal to the total burned amount. - A `Burned` event MUST be emitted for every *holder* with the corresponding amount for each *holder*. - The sum of all the amounts from the `Burned` event MUST be equal to the total burned `amount`. *NOTE*: Burning an amount of zero (`0`) tokens is valid and MUST be treated as a regular burn. *NOTE*: The `data` field contains information provided by the holder&mdash;similar to the data field in a regular ether send transaction. The `tokensToSend()` hook, the `tokensReceived()`, or both MAY use the information to decide if they wish to reject the transaction. *NOTE*: The `operatorData` field is analogous to the `data` field except it SHALL be provided by the *operator*. **`Burned` event** <a id="burned"></a> ``` solidity event Burned( address indexed operator, address indexed from, uint256 amount, bytes data, bytes operatorData ); ``` Indicate the burning of `amount` of tokens from the `from` address by the `operator` address. *NOTE*: This event MUST NOT be emitted outside of a burn process. > <small>**parameters**</small> > <small>`operator`: Address which triggered the burn.</small> > <small>`from`: *Holder* whose tokens were burned.</small> > <small>`amount`: Number of tokens burned.</small> > <small>`data`: Information provided by the *holder*.</small> > <small>`operatorData`: Information provided by the *operator*.</small> The `burn` and `operatorBurn` functions described below MUST be implemented to burn tokens. Token contracts MAY implement other functions to burn tokens. **`burn` function** ``` solidity function burn(uint256 amount, bytes calldata data) external ``` Burn the `amount` of tokens from the address `msg.sender`. The *operator* and the *holder* MUST both be the `msg.sender`. > <small>**identifier:** `fe9d9303`</small> > <small>**parameters**</small> > <small>`amount`: Number of tokens to burn.</small> > <small>`data`: Information provided by the *holder*.</small> **`operatorBurn` function** ``` solidity function operatorBurn( address from, uint256 amount, bytes calldata data, bytes calldata operatorData ) external ``` Burn the `amount` of tokens on behalf of the address `from`. *Reminder*: If the *operator* address is not an authorized operator of the `from` address, then the burn process MUST `revert`. > <small>**identifier:** `fc673c4f`</small> > <small>**parameters**</small> > <small>`from`: *Holder* whose tokens will be burned.</small> > <small>`amount`: Number of tokens to burn.</small> > <small>`data`: Information provided by the *holder*.</small> > <small>`operatorData`: Information provided by the *operator*.</small> *NOTE*: The *operator* MAY pass any information via `operatorData`. The `operatorData` MUST only be provided by the *operator*. *NOTE*: `from` and `msg.sender` MAY be the same address. I.e., an address MAY call `operatorBurn` for itself. This call MUST be equivalent to `burn` with the addition that the *operator* MAY specify an explicit value for `operatorData` (which cannot be done with the `burn` function). #### **`ERC777TokensSender` And The `tokensToSend` Hook** The `tokensToSend` hook notifies of any request to decrement the balance (send and burn) for a given *holder*. Any address (regular or contract) wishing to be notified of token debits from their address MAY register the address of a contract implementing the `ERC777TokensSender` interface described below via [ERC-1820]. > This is done by calling the `setInterfaceImplementer` function on the [ERC-1820] registry > with the *holder* address as the address, > the `keccak256` hash of `ERC777TokensSender` > (`0x29ddb589b1fb5fc7cf394961c1adf5f8c6454761adf795e67fe149f658abe895`) as the interface hash, > and the address of the contract implementing the `ERC777TokensSender` as the implementer. ``` solidity interface ERC777TokensSender { function tokensToSend( address operator, address from, address to, uint256 amount, bytes calldata userData, bytes calldata operatorData ) external; } ``` *NOTE*: A regular address MAY register a different address&mdash;the address of a contract&mdash;implementing the interface on its behalf. A contract MAY register either its address or the address of another contract but said address MUST implement the interface on its behalf. **`tokensToSend`** ``` solidity function tokensToSend( address operator, address from, address to, uint256 amount, bytes calldata userData, bytes calldata operatorData ) external ``` Notify a request to send or burn (if `to` is `0x0`) an `amount` tokens from the `from` address to the `to` address by the `operator` address. *NOTE*: This function MUST NOT be called outside of a burn, send or [ERC-20] transfer process. > <small>**identifier:** `75ab9782`</small> > <small>**parameters**</small> > <small>`operator`: Address which triggered the balance decrease (through sending or burning).</small> > <small>`from`: *Holder* whose tokens were sent.</small> > <small>`to`: Recipient of the tokens for a send (or `0x0` for a burn).</small> > <small>`amount`: Number of tokens the *holder* balance is decreased by.</small> > <small>`data`: Information provided by the *holder*.</small> > <small>`operatorData`: Information provided by the *operator*.</small> The following rules apply when calling the `tokensToSend` hook: - The `tokensToSend` hook MUST be called for every send and burn processes. - The `tokensToSend` hook MUST be called *before* the state is updated&mdash;i.e. *before* the balance is decremented. - `operator` MUST be the address which triggered the send or burn process. - `from` MUST be the address of the *holder* whose tokens are sent or burned. - `to` MUST be the address of the *recipient* which receives the tokens for a send. - `to` MUST be `0x0` for a burn. - `amount` MUST be the number of tokens the *holder* sent or burned. - `data` MUST contain the extra information (if any) provided to the send or the burn process. - `operatorData` MUST contain the extra information provided by the address which triggered the decrease of the balance (if any). - The *holder* MAY block a send or burn process by `revert`ing. (I.e., reject the withdrawal of tokens from its account.) *NOTE*: Multiple *holders* MAY use the same implementation of `ERC777TokensSender`. *NOTE*: An address can register at most one implementation at any given time for all [ERC-777] tokens. Hence the `ERC777TokensSender` MUST expect to be called by different token contracts. The `msg.sender` of the `tokensToSend` call is expected to be the address of the token contract. *[ERC-20] compatibility requirement*: This hook takes precedence over [ERC-20] and MUST be called (if registered) when calling [ERC-20]'s `transfer` and `transferFrom` event. When called from a `transfer`, `operator` MUST be the same value as the `from`. When called from a `transferFrom`, `operator` MUST be the address which issued the `transferFrom` call. #### **`ERC777TokensRecipient` And The `tokensReceived` Hook** The `tokensReceived` hook notifies of any increment of the balance (send and mint) for a given *recipient*. Any address (regular or contract) wishing to be notified of token credits to their address MAY register the address of a contract implementing the `ERC777TokensRecipient` interface described below via [ERC-1820]. > This is done by calling the `setInterfaceImplementer` function on the [ERC-1820] registry > with the *recipient* address as the address, > the `keccak256` hash of `ERC777TokensRecipient` > (`0xb281fc8c12954d22544db45de3159a39272895b169a852b314f9cc762e44c53b`) as the interface hash, > and the address of the contract implementing the `ERC777TokensRecipient` as the implementer. ``` solidity interface ERC777TokensRecipient { function tokensReceived( address operator, address from, address to, uint256 amount, bytes calldata data, bytes calldata operatorData ) external; } ``` If the *recipient* is a contract, which has not registered an `ERC777TokensRecipient` implementation; then the token contract: - MUST `revert` if the `tokensReceived` hook is called from a mint or send call. - SHOULD continue processing the transaction if the `tokensReceived` hook is called from an ERC-20 `transfer` or `transferFrom` call. *NOTE*: A regular address MAY register a different address&mdash;the address of a contract&mdash;implementing the interface on its behalf. A contract MUST register either its address or the address of another contract but said address MUST implement the interface on its behalf. **`tokensReceived`** ``` solidity function tokensReceived( address operator, address from, address to, uint256 amount, bytes calldata data, bytes calldata operatorData ) external ``` Notify a send or mint (if `from` is `0x0`) of `amount` tokens from the `from` address to the `to` address by the `operator` address. *NOTE*: This function MUST NOT be called outside of a mint, send or [ERC-20] transfer process. > <small>**identifier:** `0023de29`</small> > <small>**parameters**</small> > <small>`operator`: Address which triggered the balance increase (through sending or minting).</small> > <small>`from`: *Holder* whose tokens were sent (or `0x0` for a mint).</small> > <small>`to`: Recipient of the tokens.</small> > <small>`amount`: Number of tokens the *recipient* balance is increased by.</small> > <small>`data`: Information provided by the *holder*.</small> > <small>`operatorData`: Information provided by the *operator*.</small> The following rules apply when calling the `tokensReceived` hook: - The `tokensReceived` hook MUST be called for every send and mint processes. - The `tokensReceived` hook MUST be called *after* the state is updated&mdash;i.e. *after* the balance is incremented. - `operator` MUST be the address which triggered the send or mint process. - `from` MUST be the address of the *holder* whose tokens are sent for a send. - `from` MUST be `0x0` for a mint. - `to` MUST be the address of the *recipient* which receives the tokens. - `amount` MUST be the number of tokens the *recipient* sent or minted. - `data` MUST contain the extra information (if any) provided to the send or the mint process. - `operatorData` MUST contain the extra information provided by the address which triggered the increase of the balance (if any). - The *holder* MAY block a send or mint process by `revert`ing. (I.e., reject the reception of tokens.) *NOTE*: Multiple *holders* MAY use the same implementation of `ERC777TokensRecipient`. *NOTE*: An address can register at most one implementation at any given time for all [ERC-777] tokens. Hence the `ERC777TokensRecipient` MUST expect to be called by different token contracts. The `msg.sender` of the `tokensReceived` call is expected to be the address of the token contract. *[ERC-20] compatibility requirement*: This hook takes precedence over [ERC-20] and MUST be called (if registered) when calling [ERC-20]'s `transfer` and `transferFrom` event. When called from a `transfer`, `operator` MUST be the same value as the `from`. When called from a `transferFrom`, `operator` MUST be the address which issued the `transferFrom` call. #### **Note On Gas Consumption** Dapps and wallets SHOULD first estimate the gas required when sending, minting, or burning tokens&mdash;using [`eth_estimateGas`][eth_estimateGas]&mdash;to avoid running out of gas during the transaction. ### Logo | **Image** | ![beige logo] | ![white logo] | ![light grey logo] | ![dark grey logo] | ![black logo] | |----------:|:-------------:|:-------------:|:------------------:|:-----------------:|:-------------:| | **Color** | beige | white | light grey | dark grey | black | | **Hex** | `#C99D66` | `#FFFFFF` | `#EBEFF0` | `#3C3C3D` | `#000000` | The logo MAY be used, modified and adapted to promote valid [ERC-777] token implementations and [ERC-777] compliant technologies such as wallets and dapps. [ERC-777] token contract authors MAY create a specific logo for their token based on this logo. The logo MUST NOT be used to advertise, promote or associate in any way technology&mdash;such as tokens&mdash;which is not [ERC-777] compliant. The logo for the standard can be found in the [`/assets/eip-777/logo`][logos] folder in `SVG` and `PNG` formats. The `PNG` version of the logo offers a few sizes in pixels. If needed, other sizes MAY be created by converting from `SVG` into `PNG`. ## Rationale The principal intent for this standard is to solve some of the shortcomings of [ERC-20] while maintaining backward compatibility with [ERC-20], and avoiding the problems and vulnerabilities of [EIP-223]. Below are the rationales for the decisions regarding the main aspects of the standards. *NOTE*: Jacques Dafflon ([0xjac]), one of the authors of the standard, conjointly wrote his [master thesis] on the standard, which goes in more details than could reasonably fit directly within the standard, and can provide further clarifications regarding certain aspects or decisions. ### Lifecycle More than just sending tokens, [ERC-777] defines the entire lifecycle of a token, starting with the minting process, followed by the sending process and terminating with the burn process. Having a lifecycle clearly defined is important for consistency and accuracy, especially when value is derived from scarcity. In contrast when looking at some [ERC-20] tokens, a discrepancy can be observed between the value returned by the `totalSupply` and the actual circulating supply, as the standard does not clearly define a process to create and destroy tokens. ### Data The mint, send and burn processes can all make use of a `data` and `operatorData` fields which are passed to any movement (mint, send or burn). Those fields may be empty for simple use cases, or they may contain valuable information related to the movement of tokens, similar to information attached to a bank transfer by the sender or the bank itself. The use of a `data` field is equally present in other standard proposals such as [EIP-223], and was requested by multiple members of the community who reviewed this standard. ### Hooks In most cases, [ERC-20] requires two calls to safely transfer tokens to a contract without locking them. A call from the sender, using the `approve` function and a call from the recipient using `transferFrom`. Furthermore, this requires extra communication between the parties which is not clearly defined. Finally, holders can get confused between `transfer` and `approve`/`transferFrom`. Using the former to transfer tokens to a contract will most likely result in locked tokens. Hooks allow streamlining of the sending process and offer a single way to send tokens to any recipient. Thanks to the `tokensReceived` hook, contracts are able to react and prevent locking tokens upon reception. #### **Greater Control For Holders** The `tokensReceived` hook also allows holders to reject the reception of some tokens. This gives greater control to holders who can accept or reject incoming tokens based on some parameters, for example located in the `data` or `operatorData` fields. Following the same intentions and based on suggestions from the community, the `tokensToSend` hook was added to give control over and prevent the movement of outgoing tokens. #### **[ERC-1820] Registry** The [ERC-1820] Registry allows holders to register their hooks. Other alternatives were examined beforehand to link hooks and holders. The first was for hooks to be defined at the sender's or recipient's address. This approach is similar to [EIP-223] which proposes a `tokenFallback` function on recipient contracts to be called when receiving tokens, but improves on it by relying on [ERC-165] for interface detection. While straightforward to implement, this approach imposes several limitations. In particular, the sender and recipient must be contracts in order to provide their implementation of the hooks. Preventing externally owned addresses to benefit from hooks. Existing contracts have a strong probability not to be compatible, as they undoubtedly were unaware and do not define the new hooks. Consequently existing smart contract infrastructure such as multisig wallets which potentially hold large amounts of ether and tokens would need to be migrated to new updated contracts. The second approach considered was to use [ERC-672] which offered pseudo-introspection for addresses using reverse-ENS. However, this approach relied heavily on ENS, on top of which reverse lookup would need to be implemented. Analysis of this approach promptly revealed a certain degree of complexity and security concerns which would transcend the benefits of approach. The third solution&mdash;used in this standard&mdash;is to rely on a unique registry where any address can register the addresses of contracts implementing the hooks on its behalf. This approach has the advantage that externally owned accounts and contracts can benefit from hooks, including existing contracts which can rely on hooks deployed on proxy contracts. The decision was made to keep this registry in a separate EIP, as to not over complicate this standard. More importantly, the registry is designed in a flexible fashion, such that other EIPs and smart contract infrastructures can benefit from it for their own use cases, outside the realm of [ERC-777] and tokens. The first proposal for this registry was [ERC-820]. Unfortunately, issues emanating from upgrades in the Solidity language to versions 0.5 and above resulted in a bug in a separated part of the registry, which required changes. This was discovered right after the last call period. Attempts made to avoid creating a separate EIP, such as [ERC-820a], were rejected. Hence the standard for the registry used for [ERC-777] became [ERC-1820]. [ERC-1820] and [ERC-820] are functionally equivalent. [ERC-1820] simply contains the fix for newer versions of Solidity. ### Operators The standard defines the concept of operators as any address which moves tokens. While intuitively every address moves its own tokens, separating the concepts of holder and operator allows for greater flexibility. Primarily, this originates from the fact that the standard defines a mechanism for holders to let other addresses become their operators. Moreover, unlike the approve calls in [ERC-20] where the role of an approved address is not clearly defined, [ERC-777] details the intent of and interactions with operators, including an obligation for operators to be approved, and an irrevocable right for any holder to revoke operators. #### **Default Operators** Default operators were added based on community demand for pre-approved operators. That is operators which are approved for all holders by default. For obvious security reasons, the list of default operators is defined at the token contract creation time, and cannot be changed. Any holder still has the right to revoke default operators. One of the obvious advantages of default operators is to allow ether-less movements of tokens. Default operators offer other usability advantages, such as allowing token providers to offer functionality in a modular way, and to reduce the complexity for holders to use features provided through operators. ## Backward Compatibility This EIP does not introduce backward incompatibilities and is backward compatible with the older [ERC-20] token standard. This EIP does not use `transfer` and `transferFrom` and uses `send` and `operatorSend` to avoid confusion and mistakes when deciphering which token standard is being used. This standard allows the implementation of [ERC-20] functions `transfer`, `transferFrom`, `approve` and `allowance` alongside to make a token fully compatible with [ERC-20]. The token MAY implement `decimals()` for backward compatibility with [ERC-20]. If implemented, it MUST always return `18`. Therefore a token contract MAY implement both [ERC-20] and [ERC-777] in parallel. The specification of the `view` functions (such as `name`, `symbol`, `balanceOf`, `totalSupply`) and internal data (such as the mapping of balances) overlap without problems. Note however that the following functions are mandatory in [ERC-777] and MUST be implemented: `name`, `symbol` `balanceOf` and `totalSupply` (`decimals` is not part of the [ERC-777] standard). The state-modifying functions from both standards are decoupled and can operate independently from each other. Note that [ERC-20] functions SHOULD be limited to only being called from old contracts. If the token implements [ERC-20], it MUST register the `ERC20Token` interface with its own address via [ERC-1820]. This is done by calling the `setInterfaceImplementer` function on the ERC-1820 registry with the token contract address as both the address and the implementer and the `keccak256` hash of `ERC20Token` (`0xaea199e31a596269b42cdafd93407f14436db6e4cad65417994c2eb37381e05a`) as the interface hash. If the contract has a switch to enable or disable ERC-20 functions, every time the switch is triggered, the token MUST register or unregister the `ERC20Token` interface for its own address accordingly via ERC1820. Unregistering implies calling the `setInterfaceImplementer` with the token contract address as the address, the `keccak256` hash of `ERC20Token` as the interface hash and `0x0` as the implementer. (See [Set An Interface For An Address][erc1820-set] in [ERC-1820] for more details.) The difference for new contracts implementing [ERC-20] is that `tokensToSend` and `tokensReceived` hooks take precedence over [ERC-20]. Even with an [ERC-20] `transfer` and `transferFrom` call, the token contract MUST check via [ERC-1820] if the `from` and the `to` address implement `tokensToSend` and `tokensReceived` hook respectively. If any hook is implemented, it MUST be called. Note that when calling [ERC-20] `transfer` on a contract, if the contract does not implement `tokensReceived`, the `transfer` call SHOULD still be accepted even if this means the tokens will probably be locked. The table below summarizes the different actions the token contract MUST take when sending, minting and transferring token via [ERC-777] and [ERC-20]: <table> <tr> <th align="right">ERC1820</th> <th><code>to</code> address</th> <th align="center">ERC777 Sending And Minting</th> <th align="center">ERC20 <code>transfer</code>/<code>transferFrom</code></th> </tr> <tr> <td rowspan="2" align="right"> <code>ERC777TokensRecipient</code><br/>registered </td> <td>regular address</td> <td colspan="2" rowspan="2" align="center"> MUST call <code>tokensReceived</code> </td> </tr> <tr> <td>contract</td> </tr> <tr> <td rowspan="2" align="right"> <code>ERC777TokensRecipient</code><br/>not registered </td> <td>regular address</td> <td colspan="2" align="center">continue</td> </tr> <tr> <td>contract</td> <td align="center">MUST <code>revert</code></td> <td align="center">SHOULD continue<sup><a id="continue-footnote-backlink" href="#continue-footnote">1</a></sup></td> </tr> </table> > <a href="#continue-footnote-backlink"><small id="continue-footnote">1.</small></a> > <small>The transaction SHOULD continue for clarity as ERC20 is not aware of hooks.</small> > <small>However, this can result in accidentally locked tokens.</small> > <small>If avoiding accidentally locked tokens is paramount, the transaction MAY <code>revert</code>.</small> There is no particular action to take if `tokensToSend` is not implemented. The movement MUST proceed and only be canceled if another condition is not respected such as lack of funds or a `revert` in `tokensReceived` (if present). During a send, mint and burn, the respective `Sent`, `Minted` and `Burned` events MUST be emitted. Furthermore, if the token contract declares that it implements `ERC20Token` via [ERC-1820], the token contract SHOULD emit a `Transfer` event for minting and burning and MUST emit a `Transfer` event for sending (as specified in the [ERC-20] standard). During an [ERC-20]'s `transfer` or `transferFrom` functions, a valid `Sent` event MUST be emitted. Hence for any movement of tokens, two events MAY be emitted: an [ERC-20] `Transfer` and an [ERC-777] `Sent`, `Minted` or `Burned` (depending on the type of movement). Third-party developers MUST be careful not to consider both events as separate movements. As a general rule, if an application considers the token as an ERC20 token, then only the `Transfer` event MUST be taken into account. If the application considers the token as an ERC777 token, then only the `Sent`, `Minted` and `Burned` events MUST be considered. ## Test Cases The [repository with the reference implementation][0xjac/ERC777] contains all the [tests][ref tests]. ## Implementation The GitHub repository [0xjac/ERC777] contains the [reference implementation]. The reference implementation is also available via [npm][npm/erc777] and can be installed with `npm install erc777`. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [operators]: #operators [ERC-20]: /EIPS/eip-20 [ERC-165]: /EIPS/eip-165 [ERC-672]: https://github.com/ethereum/EIPs/issues/672 [ERC-777]: /EIPS/eip-777 [ERC-820]: /EIPS/eip-820 [ERC-820a]: https://github.com/ethereum/EIPs/pull/1758 [ERC-1820]: /EIPS/eip-1820 [erc1820-set]: /EIPS/eip-1820#set-an-interface-for-an-address [0xjac]: https://github.com/0xjac [0xjac/ERC777]: https://github.com/0xjac/ERC777 [master thesis]: https://github.com/0xjac/master-thesis [npm/erc777]: https://www.npmjs.com/package/erc777 [ref tests]: https://github.com/0xjac/ERC777/blob/master/test/ReferenceToken.test.js [reference implementation]: https://github.com/0xjac/ERC777/blob/master/contracts/examples/ReferenceToken.sol [EIP-223]: https://github.com/ethereum/EIPs/issues/223 [eth_estimateGas]: https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_estimategas [authorizedoperator]: #authorizedoperator [revokedoperator]: #revokedoperator [isOperatorFor]: #isOperatorFor [defaultOperators]: #defaultOperators [sent]: #sent [minted]: #minted [burned]: #burned [logos]: https://github.com/ethereum/EIPs/tree/master/assets/eip-777/logo [beige logo]: /assets/eip-777/logo/png/ERC-777-logo-beige-48px.png [white logo]: /assets/eip-777/logo/png/ERC-777-logo-white-48px.png [light grey logo]: /assets/eip-777/logo/png/ERC-777-logo-light_grey-48px.png [dark grey logo]: /assets/eip-777/logo/png/ERC-777-logo-dark_grey-48px.png [black logo]: /assets/eip-777/logo/png/ERC-777-logo-black-48px.png Mon, 20 Nov 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-777 https://eips.ethereum.org/EIPS/eip-777 Ethereum Node Records (ENR) Standards Track/Networking https://github.com/ethereum/devp2p/issues/43 # Abstract This EIP defines Ethereum Node Records, an open format for p2p connectivity information. # Motivation Ethereum nodes discover each other through the node discovery protocol. The purpose of that protocol is relaying node identity public keys (on the secp256k1 curve), their IP address and two port numbers. No other information can be relayed. This specification seeks to lift the restrictions of the discovery v4 protocol by defining a flexible format, the *node record*, for connectivity-related information. Node records can be relayed through a future version of the node discovery protocol. They can also be relayed through arbitrary other mechanisms such as DNS, ENS, a devp2p subprotocol, etc. Node records improve cryptographic agility and handling of protocol upgrades. A record can contain information about arbitrary transport protocols and public key material associated with them. Another goal of the new format is to provide authoritative updates of connectivity information. If a node changes its endpoint and publishes a new record, other nodes should be able to determine which record is newer. # Specification The components of a node record are: - `signature`: cryptographic signature of record contents - `seq`: The sequence number, a 64-bit unsigned integer. Nodes should increase the number whenever the record changes and republish the record. - The remainder of the record consists of arbitrary key/value pairs A record's signature is made and validated according to an *identity scheme*. The identity scheme is also responsible for deriving a node's address in the DHT. The key/value pairs must be sorted by key and must be unique, i.e. any key may be present only once. The keys can technically be any byte sequence, but ASCII text is preferred. Key names in the table below have pre-defined meaning. | Key | Value | |:------------|:-------------------------------------------| | `id` | name of identity scheme, e.g. "v4" | | `secp256k1` | compressed secp256k1 public key, 33 bytes | | `ip` | IPv4 address, 4 bytes | | `tcp` | TCP port, big endian integer | | `udp` | UDP port, big endian integer | | `ip6` | IPv6 address, 16 bytes | | `tcp6` | IPv6-specific TCP port, big endian integer | | `udp6` | IPv6-specific UDP port, big endian integer | All keys except `id` are optional, including IP addresses and ports. A record without endpoint information is still valid as long as its signature is valid. If no `tcp6` / `udp6` port is provided, the `tcp` / `udp` port applies to both IP addresses. Declaring the same port number in both `tcp`, `tcp6` or `udp`, `udp6` should be avoided but doesn't render the record invalid. ### RLP Encoding The canonical encoding of a node record is an RLP list of `[signature, seq, k, v, ...]`. The maximum encoded size of a node record is 300 bytes. Implementations should reject records larger than this size. Records are signed and encoded as follows: content = [seq, k, v, ...] signature = sign(content) record = [signature, seq, k, v, ...] ### Text Encoding The textual form of a node record is the base64 encoding of its RLP representation, prefixed by `enr:`. Implementations should use the [URL-safe base64 alphabet][base64url] and omit padding characters. ### "v4" Identity Scheme This specification defines a single identity scheme to be used as the default until other schemes are defined by further EIPs. The "v4" scheme is backwards-compatible with the cryptosystem used by Node Discovery v4. - To sign record `content` with this scheme, apply the keccak256 hash function (as used by the EVM) to `content`, then create a signature of the hash. The resulting 64-byte signature is encoded as the concatenation of the `r` and `s` signature values (the recovery ID `v` is omitted). - To verify a record, check that the signature was made by the public key in the "secp256k1" key/value pair of the record. - To derive a node address, take the keccak256 hash of the uncompressed public key. # Rationale The format is meant to suit future needs in two ways: - Adding new key/value pairs: This is always possible and doesn't require implementation consensus. Existing clients will accept any key/value pairs regardless of whether they can interpret their content. - Adding identity schemes: these need implementation consensus because the network won't accept the signature otherwise. To introduce a new identity scheme, propose an EIP and get it implemented. The scheme can be used as soon as most clients accept it. The size of a record is limited because records are relayed frequently and may be included in size-constrained protocols such as DNS. A record containing a IPv4 address, when signed using the "v4" scheme occupies roughly 120 bytes, leaving plenty of room for additional metadata. You might wonder about the need for so many pre-defined keys related to IP addresses and ports. This need arises because residential and mobile network setups often put IPv4 behind NAT while IPv6 traffic—if supported—is directly routed to the same host. Declaring both address types ensures a node is reachable from IPv4-only locations and those supporting both protocols. # Test Vectors This is an example record containing the IPv4 address `127.0.0.1` and UDP port `30303`. The node ID is `a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7`. ```text enr:-IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2_oxVtw0RW_QAdpzBQA8yWM0xOIN1ZHCCdl8 ``` The record is signed using the "v4" identity scheme using sequence number `1` and this private key: ```text b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291 ``` The RLP structure of the record is: ```text [ 7098ad865b00a582051940cb9cf36836572411a47278783077011599ed5cd16b76f2635f4e234738f30813a89eb9137e3e3df5266e3a1f11df72ecf1145ccb9c, 01, "id", "v4", "ip", 7f000001, "secp256k1", 03ca634cae0d49acb401d8a4c6b6fe8c55b70d115bf400769cc1400f3258cd3138, "udp", 765f, ] ``` # Copyright Copyright and related rights waived via [CC0](/LICENSE). [base64url]: https://tools.ietf.org/html/rfc4648#section-5 Thu, 23 Nov 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-778 https://eips.ethereum.org/EIPS/eip-778 Hardfork Meta: DAO Fork Meta/ ## Abstract This documents the changes included in the hard fork named "DAO Fork". Unlike other hard forks, the DAO Fork did not change the protocol; all EVM opcodes, transaction format, block structure, and so on remained the same. Rather, the DAO Fork was an "irregular state change" that transferred ether balances from a list of accounts ("child DAO" contracts) into a specified account (the "WithdrawDAO" contract). ## Specification - Codename: DAO Fork - Activation: - Block == 1,920,000 on Mainnet See references [1] and [2] for the original, full specification. It is summarized here for convenience. At block 1880000, the following accounts are encoded into a list `L`: * The DAO (`0xbb9bc244d798123fde783fcc1c72d3bb8c189413`) * its extraBalance (`0x807640a13483f8ac783c557fcdf27be11ea4ac7a`) * all children of the DAO creator (`0x4a574510c7014e4ae985403536074abe582adfc8`) * and the extraBalance of each child <details> <summary>Reference list L</summary> ``` 0xd4fe7bc31cedb7bfb8a345f31e668033056b2728, 0xb3fb0e5aba0e20e5c49d252dfd30e102b171a425, 0x2c19c7f9ae8b751e37aeb2d93a699722395ae18f, 0xecd135fa4f61a655311e86238c92adcd779555d2, 0x1975bd06d486162d5dc297798dfc41edd5d160a7, 0xa3acf3a1e16b1d7c315e23510fdd7847b48234f6, 0x319f70bab6845585f412ec7724b744fec6095c85, 0x06706dd3f2c9abf0a21ddcc6941d9b86f0596936, 0x5c8536898fbb74fc7445814902fd08422eac56d0, 0x6966ab0d485353095148a2155858910e0965b6f9, 0x779543a0491a837ca36ce8c635d6154e3c4911a6, 0x2a5ed960395e2a49b1c758cef4aa15213cfd874c, 0x5c6e67ccd5849c0d29219c4f95f1a7a93b3f5dc5, 0x9c50426be05db97f5d64fc54bf89eff947f0a321, 0x200450f06520bdd6c527622a273333384d870efb, 0xbe8539bfe837b67d1282b2b1d61c3f723966f049, 0x6b0c4d41ba9ab8d8cfb5d379c69a612f2ced8ecb, 0xf1385fb24aad0cd7432824085e42aff90886fef5, 0xd1ac8b1ef1b69ff51d1d401a476e7e612414f091, 0x8163e7fb499e90f8544ea62bbf80d21cd26d9efd, 0x51e0ddd9998364a2eb38588679f0d2c42653e4a6, 0x627a0a960c079c21c34f7612d5d230e01b4ad4c7, 0xf0b1aa0eb660754448a7937c022e30aa692fe0c5, 0x24c4d950dfd4dd1902bbed3508144a54542bba94, 0x9f27daea7aca0aa0446220b98d028715e3bc803d, 0xa5dc5acd6a7968a4554d89d65e59b7fd3bff0f90, 0xd9aef3a1e38a39c16b31d1ace71bca8ef58d315b, 0x63ed5a272de2f6d968408b4acb9024f4cc208ebf, 0x6f6704e5a10332af6672e50b3d9754dc460dfa4d, 0x77ca7b50b6cd7e2f3fa008e24ab793fd56cb15f6, 0x492ea3bb0f3315521c31f273e565b868fc090f17, 0x0ff30d6de14a8224aa97b78aea5388d1c51c1f00, 0x9ea779f907f0b315b364b0cfc39a0fde5b02a416, 0xceaeb481747ca6c540a000c1f3641f8cef161fa7, 0xcc34673c6c40e791051898567a1222daf90be287, 0x579a80d909f346fbfb1189493f521d7f48d52238, 0xe308bd1ac5fda103967359b2712dd89deffb7973, 0x4cb31628079fb14e4bc3cd5e30c2f7489b00960c, 0xac1ecab32727358dba8962a0f3b261731aad9723, 0x4fd6ace747f06ece9c49699c7cabc62d02211f75, 0x440c59b325d2997a134c2c7c60a8c61611212bad, 0x4486a3d68fac6967006d7a517b889fd3f98c102b, 0x9c15b54878ba618f494b38f0ae7443db6af648ba, 0x27b137a85656544b1ccb5a0f2e561a5703c6a68f, 0x21c7fdb9ed8d291d79ffd82eb2c4356ec0d81241, 0x23b75c2f6791eef49c69684db4c6c1f93bf49a50, 0x1ca6abd14d30affe533b24d7a21bff4c2d5e1f3b, 0xb9637156d330c0d605a791f1c31ba5890582fe1c, 0x6131c42fa982e56929107413a9d526fd99405560, 0x1591fc0f688c81fbeb17f5426a162a7024d430c2, 0x542a9515200d14b68e934e9830d91645a980dd7a, 0xc4bbd073882dd2add2424cf47d35213405b01324, 0x782495b7b3355efb2833d56ecb34dc22ad7dfcc4, 0x58b95c9a9d5d26825e70a82b6adb139d3fd829eb, 0x3ba4d81db016dc2890c81f3acec2454bff5aada5, 0xb52042c8ca3f8aa246fa79c3feaa3d959347c0ab, 0xe4ae1efdfc53b73893af49113d8694a057b9c0d1, 0x3c02a7bc0391e86d91b7d144e61c2c01a25a79c5, 0x0737a6b837f97f46ebade41b9bc3e1c509c85c53, 0x97f43a37f595ab5dd318fb46e7a155eae057317a, 0x52c5317c848ba20c7504cb2c8052abd1fde29d03, 0x4863226780fe7c0356454236d3b1c8792785748d, 0x5d2b2e6fcbe3b11d26b525e085ff818dae332479, 0x5f9f3392e9f62f63b8eac0beb55541fc8627f42c, 0x057b56736d32b86616a10f619859c6cd6f59092a, 0x9aa008f65de0b923a2a4f02012ad034a5e2e2192, 0x304a554a310c7e546dfe434669c62820b7d83490, 0x914d1b8b43e92723e64fd0a06f5bdb8dd9b10c79, 0x4deb0033bb26bc534b197e61d19e0733e5679784, 0x07f5c1e1bc2c93e0402f23341973a0e043f7bf8a, 0x35a051a0010aba705c9008d7a7eff6fb88f6ea7b, 0x4fa802324e929786dbda3b8820dc7834e9134a2a, 0x9da397b9e80755301a3b32173283a91c0ef6c87e, 0x8d9edb3054ce5c5774a420ac37ebae0ac02343c6, 0x0101f3be8ebb4bbd39a2e3b9a3639d4259832fd9, 0x5dc28b15dffed94048d73806ce4b7a4612a1d48f, 0xbcf899e6c7d9d5a215ab1e3444c86806fa854c76, 0x12e626b0eebfe86a56d633b9864e389b45dcb260, 0xa2f1ccba9395d7fcb155bba8bc92db9bafaeade7, 0xec8e57756626fdc07c63ad2eafbd28d08e7b0ca5, 0xd164b088bd9108b60d0ca3751da4bceb207b0782, 0x6231b6d0d5e77fe001c2a460bd9584fee60d409b, 0x1cba23d343a983e9b5cfd19496b9a9701ada385f, 0xa82f360a8d3455c5c41366975bde739c37bfeb8a, 0x9fcd2deaff372a39cc679d5c5e4de7bafb0b1339, 0x005f5cee7a43331d5a3d3eec71305925a62f34b6, 0x0e0da70933f4c7849fc0d203f5d1d43b9ae4532d, 0xd131637d5275fd1a68a3200f4ad25c71a2a9522e, 0xbc07118b9ac290e4622f5e77a0853539789effbe, 0x47e7aa56d6bdf3f36be34619660de61275420af8, 0xacd87e28b0c9d1254e868b81cba4cc20d9a32225, 0xadf80daec7ba8dcf15392f1ac611fff65d94f880, 0x5524c55fb03cf21f549444ccbecb664d0acad706, 0x40b803a9abce16f50f36a77ba41180eb90023925, 0xfe24cdd8648121a43a7c86d289be4dd2951ed49f, 0x17802f43a0137c506ba92291391a8a8f207f487d, 0x253488078a4edf4d6f42f113d1e62836a942cf1a, 0x86af3e9626fce1957c82e88cbf04ddf3a2ed7915, 0xb136707642a4ea12fb4bae820f03d2562ebff487, 0xdbe9b615a3ae8709af8b93336ce9b477e4ac0940, 0xf14c14075d6c4ed84b86798af0956deef67365b5, 0xca544e5c4687d109611d0f8f928b53a25af72448, 0xaeeb8ff27288bdabc0fa5ebb731b6f409507516c, 0xcbb9d3703e651b0d496cdefb8b92c25aeb2171f7, 0x6d87578288b6cb5549d5076a207456a1f6a63dc0, 0xb2c6f0dfbb716ac562e2d85d6cb2f8d5ee87603e, 0xaccc230e8a6e5be9160b8cdf2864dd2a001c28b6, 0x2b3455ec7fedf16e646268bf88846bd7a2319bb2, 0x4613f3bca5c44ea06337a9e439fbc6d42e501d0a, 0xd343b217de44030afaa275f54d31a9317c7f441e, 0x84ef4b2357079cd7a7c69fd7a37cd0609a679106, 0xda2fef9e4a3230988ff17df2165440f37e8b1708, 0xf4c64518ea10f995918a454158c6b61407ea345c, 0x7602b46df5390e432ef1c307d4f2c9ff6d65cc97, 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, 0x807640a13483f8ac783c557fcdf27be11ea4ac7a ``` </details> At the beginning of block 1920000, all ether throughout all accounts in `L` will be transferred to a contract deployed at `0xbf4ed7b27f1d666546e30d74d50d173d20bca754`. The contract was created from the following Solidity code (compiler version `v0.3.5-2016-07-01-48238c9`): ```solidity // Deployed on mainnet at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754 contract DAO { function balanceOf(address addr) returns (uint); function transferFrom(address from, address to, uint balance) returns (bool); uint public totalSupply; } contract WithdrawDAO { DAO constant public mainDAO = DAO(0xbb9bc244d798123fde783fcc1c72d3bb8c189413); address public trustee = 0xda4a4626d3e16e094de3225a751aab7128e96526; function withdraw(){ uint balance = mainDAO.balanceOf(msg.sender); if (!mainDAO.transferFrom(msg.sender, this, balance) || !msg.sender.send(balance)) throw; } function trusteeWithdraw() { trustee.send((this.balance + mainDAO.balanceOf(this)) - mainDAO.totalSupply()); } } ``` This contract is deployed on Mainnet in block 1883496 in transaction hash `0xfeae1ff3cf9b6927d607744e3883ea105fb16042d4639857d9cfce3eba644286`. The deployment code of the contract is: ``` 0x606060405273da4a4626d3e16e094de3225a751aab7128e96526600060006101000a81548173ffffffffffffffffffffffffffffffffffffffff02191690830217905550610462806100516000396000f360606040526000357c0100000000000000000000000000000000000000000000000000000000900480632e6e504a1461005a5780633ccfd60b14610069578063eedcf50a14610078578063fdf97cb2146100b157610058565b005b61006760048050506100ea565b005b6100766004805050610277565b005b6100856004805050610424565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6100be600480505061043c565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166318160ddd604051817c01000000000000000000000000000000000000000000000000000000000281526004018090506020604051808303816000876161da5a03f115610002575050506040518051906020015073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823130604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f11561000257505050604051805190602001503073ffffffffffffffffffffffffffffffffffffffff16310103604051809050600060405180830381858888f19350505050505b565b600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823133604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f1156100025750505060405180519060200150905073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166323b872dd333084604051847c0100000000000000000000000000000000000000000000000000000000028152600401808473ffffffffffffffffffffffffffffffffffffffff1681526020018373ffffffffffffffffffffffffffffffffffffffff16815260200182815260200193505050506020604051808303816000876161da5a03f1156100025750505060405180519060200150158061041657503373ffffffffffffffffffffffffffffffffffffffff16600082604051809050600060405180830381858888f19350505050155b1561042057610002565b5b50565b73bb9bc244d798123fde783fcc1c72d3bb8c18941381565b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156 ``` This deployment results in the runtime bytecode: ``` 0x60606040526000357c0100000000000000000000000000000000000000000000000000000000900480632e6e504a1461005a5780633ccfd60b14610069578063eedcf50a14610078578063fdf97cb2146100b157610058565b005b61006760048050506100ea565b005b6100766004805050610277565b005b6100856004805050610424565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6100be600480505061043c565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166318160ddd604051817c01000000000000000000000000000000000000000000000000000000000281526004018090506020604051808303816000876161da5a03f115610002575050506040518051906020015073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823130604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f11561000257505050604051805190602001503073ffffffffffffffffffffffffffffffffffffffff16310103604051809050600060405180830381858888f19350505050505b565b600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823133604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f1156100025750505060405180519060200150905073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166323b872dd333084604051847c0100000000000000000000000000000000000000000000000000000000028152600401808473ffffffffffffffffffffffffffffffffffffffff1681526020018373ffffffffffffffffffffffffffffffffffffffff16815260200182815260200193505050506020604051808303816000876161da5a03f1156100025750505060405180519060200150158061041657503373ffffffffffffffffffffffffffffffffffffffff16600082604051809050600060405180830381858888f19350505050155b1561042057610002565b5b50565b73bb9bc244d798123fde783fcc1c72d3bb8c18941381565b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156 ``` Blocks with block numbers in the range [1_920_000, 1_920_009] **MUST** have `0x64616f2d686172642d666f726b` (hex encoded ASCII string `dao-hard-fork`) in the `extraData` field of the block. ## References 1. https://blog.slock.it/hard-fork-specification-24b889e70703 2. https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork/ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 26 Nov 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-779 https://eips.ethereum.org/EIPS/eip-779 Canary Standard Standards Track/ERC ## Simple Summary A standard interface for canary contracts. ## Abstract The following standard allows the implementation of canaries within contracts. This standard provides basic functionality to check if a canary is alive, keeping the canary alive and optionally manage feeders. ## Motivation The canary can e.g. be used as a [warrant canary](https://en.wikipedia.org/wiki/Warrant_canary). A standard interface allows other applications to easily interface with canaries on Ethereum - e.g. for visualizing the state, automated alarms, applications to feed the canary or contracts (e.g. insurance) that use the state. ## Specification ### Methods #### isAlive() Returns if the canary was fed properly to signal e.g. that no warrant was received. ``` js function isAlive() constant returns (bool alive) ``` #### getBlockOfDeath() Returns the block the canary died. Throws if the canary is alive. ``` js function getBlockOfDeath() constant returns (uint256 block) ``` #### getType() Returns the type of the canary: * `1` = Simple (just the pure interface as defined in this ERC) * `2` = Single feeder (as defined in ERC-TBD) * `3` = Single feeder with bad food (as defined in ERC-TBD) * `4` = Multiple feeders (as defined in ERC-TBD) * `5` = Multiple mandatory feeders (as defined in ERC-TBD) * `6` = IOT (as defined in ERC-TBD) `1` might also be used for a special purpose contract that does not need a special type but still wants to expose the functions and provide events as defined in this ERC. ``` js function getType() constant returns (uint8 type) ``` ### Events #### RIP MUST trigger when the contract is called the first time after the canary died. ``` js event RIP() ``` ## Implementation TODO ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 16 Dec 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-801 https://eips.ethereum.org/EIPS/eip-801 Pseudo-introspection Registry Contract Standards Track/ERC https://github.com/ethereum/EIPs/issues/820 > :information_source: **[ERC-1820] has superseded [ERC-820].** :information_source: > [ERC-1820] fixes the incompatibility in the [ERC-165] logic which was introduced by the Solidty 0.5 update. > Have a look at the [official announcement][erc1820-annoucement], and the comments about the [bug][erc820-bug] and the [fix][erc820-fix]. > Apart from this fix, [ERC-1820] is functionally equivalent to [ERC-820]. > > :warning: [ERC-1820] MUST be used in lieu of [ERC-820]. :warning: ## Simple Summary This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation. This standard keeps backward compatibility with [ERC-165]. ## Abstract This standard defines a registry where smart contracts and regular accounts can publish which functionalities they implement---either directly or through a proxy contract. Anyone can query this registry to ask if a specific address implements a given interface and which smart contract handles its implementation. This registry MAY be deployed on any chain and shares the same address on all chains. Interfaces with zeroes (`0`) as the last 28 bytes are considered [ERC-165] interfaces, and this registry SHALL forward the call to the contract to see if it implements the interface. This contract also acts as an [ERC-165] cache to reduce gas consumption. ## Motivation There have been different approaches to define pseudo-introspection in Ethereum. The first is [ERC-165] which has the limitation that it cannot be used by regular accounts. The second attempt is [ERC-672] which uses reverse [ENS]. Using reverse [ENS] has two issues. First, it is unnecessarily complicated, and second, [ENS] is still a centralized contract controlled by a multisig. This multisig theoretically would be able to modify the system. This standard is much simpler than [ERC-672], and it is *fully* decentralized. This standard also provides a *unique* address for all chains. Thus solving the problem of resolving the correct registry address for different chains. ## Specification ### [ERC-820] Registry Smart Contract > This is an exact copy of the code of the [ERC820 registry smart contract]. ``` solidity /* ERC820 Pseudo-introspection Registry Contract * This standard defines a universal registry smart contract where any address * (contract or regular account) can register which interface it supports and * which smart contract is responsible for its implementation. * * Written in 2018 by Jordi Baylina and Jacques Dafflon * * To the extent possible under law, the author(s) have dedicated all copyright * and related and neighboring rights to this software to the public domain * worldwide. This software is distributed without any warranty. * * You should have received a copy of the CC0 Public Domain Dedication along * with this software. If not, see * <https://creativecommons.org/publicdomain/zero/1.0/>. * * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗ * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗ * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║ * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║ * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝ * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝ * * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗ * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝ * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝ * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝ * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║ * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝ * */ pragma solidity 0.4.24; // IV is value needed to have a vanity address starting with `0x820`. // IV: 9513 /// @dev The interface a contract MUST implement if it is the implementer of /// some (other) interface for any address other than itself. interface ERC820ImplementerInterface { /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not. /// @param interfaceHash keccak256 hash of the name of the interface /// @param addr Address for which the contract will implement the interface /// @return ERC820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`. function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32); } /// @title ERC820 Pseudo-introspection Registry Contract /// @author Jordi Baylina and Jacques Dafflon /// @notice This contract is the official implementation of the ERC820 Registry. /// @notice For more details, see https://eips.ethereum.org/EIPS/eip-820 contract ERC820Registry { /// @notice ERC165 Invalid ID. bytes4 constant INVALID_ID = 0xffffffff; /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`). bytes4 constant ERC165ID = 0x01ffc9a7; /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address. bytes32 constant ERC820_ACCEPT_MAGIC = keccak256(abi.encodePacked("ERC820_ACCEPT_MAGIC")); mapping (address => mapping(bytes32 => address)) interfaces; mapping (address => address) managers; mapping (address => mapping(bytes4 => bool)) erc165Cached; /// @notice Indicates a contract is the `implementer` of `interfaceHash` for `addr`. event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer); /// @notice Indicates `newManager` is the address of the new manager for `addr`. event ManagerChanged(address indexed addr, address indexed newManager); /// @notice Query if an address implements an interface and through which contract. /// @param _addr Address being queried for the implementer of an interface. /// (If `_addr == 0` then `msg.sender` is assumed.) /// @param _interfaceHash keccak256 hash of the name of the interface as a string. /// E.g., `web3.utils.keccak256('ERC777Token')`. /// @return The address of the contract which implements the interface `_interfaceHash` for `_addr` /// or `0x0` if `_addr` did not register an implementer for this interface. function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) { address addr = _addr == 0 ? msg.sender : _addr; if (isERC165Interface(_interfaceHash)) { bytes4 erc165InterfaceHash = bytes4(_interfaceHash); return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : 0; } return interfaces[addr][_interfaceHash]; } /// @notice Sets the contract which implements a specific interface for an address. /// Only the manager defined for that address can set it. /// (Each address is the manager for itself until it sets a new manager.) /// @param _addr Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.) /// @param _interfaceHash keccak256 hash of the name of the interface as a string. /// For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface. /// @param _implementer Contract address implementing _interfaceHash for _addr. function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external { address addr = _addr == 0 ? msg.sender : _addr; require(getManager(addr) == msg.sender, "Not the manager"); require(!isERC165Interface(_interfaceHash), "Must not be a ERC165 hash"); if (_implementer != 0 && _implementer != msg.sender) { require( ERC820ImplementerInterface(_implementer) .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC820_ACCEPT_MAGIC, "Does not implement the interface" ); } interfaces[addr][_interfaceHash] = _implementer; emit InterfaceImplementerSet(addr, _interfaceHash, _implementer); } /// @notice Sets the `_newManager` as manager for the `_addr` address. /// The new manager will be able to call `setInterfaceImplementer` for `_addr`. /// @param _addr Address for which to set the new manager. /// @param _newManager Address of the new manager for `addr`. function setManager(address _addr, address _newManager) external { require(getManager(_addr) == msg.sender, "Not the manager"); managers[_addr] = _newManager == _addr ? 0 : _newManager; emit ManagerChanged(_addr, _newManager); } /// @notice Get the manager of an address. /// @param _addr Address for which to return the manager. /// @return Address of the manager for a given address. function getManager(address _addr) public view returns(address) { // By default the manager of an address is the same address if (managers[_addr] == 0) { return _addr; } else { return managers[_addr]; } } /// @notice Compute the keccak256 hash of an interface given its name. /// @param _interfaceName Name of the interface. /// @return The keccak256 hash of an interface name. function interfaceHash(string _interfaceName) external pure returns(bytes32) { return keccak256(abi.encodePacked(_interfaceName)); } /* --- ERC165 Related Functions --- */ /* --- Developed in collaboration with William Entriken. --- */ /// @notice Updates the cache with whether the contract implements an ERC165 interface or not. /// @param _contract Address of the contract for which to update the cache. /// @param _interfaceId ERC165 interface for which to update the cache. function updateERC165Cache(address _contract, bytes4 _interfaceId) external { interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(_contract, _interfaceId) ? _contract : 0; erc165Cached[_contract][_interfaceId] = true; } /// @notice Checks whether a contract implements an ERC165 interface or not. /// The result may be cached, if not a direct lookup is performed. /// @param _contract Address of the contract to check. /// @param _interfaceId ERC165 interface to check. /// @return `true` if `_contract` implements `_interfaceId`, false otherwise. function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) { if (!erc165Cached[_contract][_interfaceId]) { return implementsERC165InterfaceNoCache(_contract, _interfaceId); } return interfaces[_contract][_interfaceId] == _contract; } /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache. /// @param _contract Address of the contract to check. /// @param _interfaceId ERC165 interface to check. /// @return `true` if `_contract` implements `_interfaceId`, false otherwise. function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) { uint256 success; uint256 result; (success, result) = noThrowCall(_contract, ERC165ID); if (success == 0 || result == 0) { return false; } (success, result) = noThrowCall(_contract, INVALID_ID); if (success == 0 || result != 0) { return false; } (success, result) = noThrowCall(_contract, _interfaceId); if (success == 1 && result == 1) { return true; } return false; } /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not. /// @param _interfaceHash The hash to check. /// @return `true` if the hash is a ERC165 interface (ending with 28 zeroes), `false` otherwise. function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) { return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0; } /// @dev Make a call on a contract without throwing if the function does not exist. function noThrowCall(address _contract, bytes4 _interfaceId) internal view returns (uint256 success, uint256 result) { bytes4 erc165ID = ERC165ID; assembly { let x := mload(0x40) // Find empty storage location using "free memory pointer" mstore(x, erc165ID) // Place signature at beginning of empty storage mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature success := staticcall( 30000, // 30k gas _contract, // To addr x, // Inputs are stored at location x 0x08, // Inputs are 8 bytes long x, // Store output over input (saves space) 0x20 // Outputs are 32 bytes long ) result := mload(x) // Load the result } } } ``` ### Deployment Transaction Below is the raw transaction which MUST be used to deploy the smart contract on any chain. ``` 0xf90a2a8085174876e800830c35008080b909d7608060405234801561001057600080fd5b506109b7806100206000396000f30060806040526004361061008d5763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166329965a1d81146100925780633d584063146100bf5780635df8122f146100fc57806365ba36c114610123578063a41e7d5114610155578063aabbb8ca14610183578063b7056765146101a7578063f712f3e8146101e9575b600080fd5b34801561009e57600080fd5b506100bd600160a060020a036004358116906024359060443516610217565b005b3480156100cb57600080fd5b506100e0600160a060020a0360043516610512565b60408051600160a060020a039092168252519081900360200190f35b34801561010857600080fd5b506100bd600160a060020a036004358116906024351661055e565b34801561012f57600080fd5b506101436004803560248101910135610655565b60408051918252519081900360200190f35b34801561016157600080fd5b506100bd600160a060020a0360043516600160e060020a0319602435166106e3565b34801561018f57600080fd5b506100e0600160a060020a036004351660243561076d565b3480156101b357600080fd5b506101d5600160a060020a0360043516600160e060020a0319602435166107e7565b604080519115158252519081900360200190f35b3480156101f557600080fd5b506101d5600160a060020a0360043516600160e060020a03196024351661089c565b6000600160a060020a0384161561022e5783610230565b335b90503361023c82610512565b600160a060020a03161461029a576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b6102a38361091c565b156102f8576040805160e560020a62461bcd02815260206004820152601960248201527f4d757374206e6f74206265206120455243313635206861736800000000000000604482015290519081900360640190fd5b600160a060020a038216158015906103195750600160a060020a0382163314155b156104a15760405160200180807f4552433832305f4143434550545f4d414749430000000000000000000000000081525060130190506040516020818303038152906040526040518082805190602001908083835b6020831061038d5780518252601f19909201916020918201910161036e565b51815160209384036101000a6000190180199092169116179052604080519290940182900382207f249cb3fa000000000000000000000000000000000000000000000000000000008352600483018a9052600160a060020a0388811660248501529451909650938816945063249cb3fa936044808401945091929091908290030181600087803b15801561042057600080fd5b505af1158015610434573d6000803e3d6000fd5b505050506040513d602081101561044a57600080fd5b5051146104a1576040805160e560020a62461bcd02815260206004820181905260248201527f446f6573206e6f7420696d706c656d656e742074686520696e74657266616365604482015290519081900360640190fd5b600160a060020a03818116600081815260208181526040808320888452909152808220805473ffffffffffffffffffffffffffffffffffffffff19169487169485179055518692917f93baa6efbd2244243bfee6ce4cfdd1d04fc4c0e9a786abd3a41313bd352db15391a450505050565b600160a060020a03808216600090815260016020526040812054909116151561053c575080610559565b50600160a060020a03808216600090815260016020526040902054165b919050565b3361056883610512565b600160a060020a0316146105c6576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b81600160a060020a031681600160a060020a0316146105e557806105e8565b60005b600160a060020a03838116600081815260016020526040808220805473ffffffffffffffffffffffffffffffffffffffff19169585169590951790945592519184169290917f605c2dbf762e5f7d60a546d42e7205dcb1b011ebc62a61736a57c9089d3a43509190a35050565b60008282604051602001808383808284378201915050925050506040516020818303038152906040526040518082805190602001908083835b602083106106ad5780518252601f19909201916020918201910161068e565b6001836020036101000a038019825116818451168082178552505050505050905001915050604051809103902090505b92915050565b6106ed82826107e7565b6106f85760006106fa565b815b600160a060020a03928316600081815260208181526040808320600160e060020a031996909616808452958252808320805473ffffffffffffffffffffffffffffffffffffffff19169590971694909417909555908152600284528181209281529190925220805460ff19166001179055565b60008080600160a060020a038516156107865784610788565b335b91506107938461091c565b156107b85750826107a4828261089c565b6107af5760006107b1565b815b92506107df565b600160a060020a038083166000908152602081815260408083208884529091529020541692505b505092915050565b60008080610815857f01ffc9a70000000000000000000000000000000000000000000000000000000061093e565b9092509050811580610825575080155b1561083357600092506107df565b61084585600160e060020a031961093e565b909250905081158061085657508015155b1561086457600092506107df565b61086e858561093e565b90925090506001821480156108835750806001145b1561089157600192506107df565b506000949350505050565b600160a060020a0382166000908152600260209081526040808320600160e060020a03198516845290915281205460ff1615156108e4576108dd83836107e7565b90506106dd565b50600160a060020a03808316600081815260208181526040808320600160e060020a0319871684529091529020549091161492915050565b7bffffffffffffffffffffffffffffffffffffffffffffffffffffffff161590565b6040517f01ffc9a7000000000000000000000000000000000000000000000000000000008082526004820183905260009182919060208160088189617530fa9051909690955093505050505600a165627a7a723058204fc4461c9d5a247b0eafe0f9c508057bc0ad72bc24668cb2a35ea65850e10d3100291ba08208208208208208208208208208208208208208208208208208208208208200a00820820820820820820820820820820820820820820820820820820820820820 ``` The strings of `820`'s at the end of the transaction are the `r` and `s` of the signature. From this deterministic pattern (generated by a human), anyone can deduce that no one knows the private key for the deployment account. ### Deployment Method This contract is going to be deployed using the keyless deployment method---also known as [Nick]'s method---which relies on a single-use address. (See [Nick's article] for more details). This method works as follows: 1. Generate a transaction which deploys the contract from a new random account. - This transaction MUST NOT use [EIP-155] in order to work on any chain. - This transaction MUST have a relatively high gas price to be deployed on any chain. In this case, it is going to be 100 Gwei. 2. Set the `v`, `r`, `s` of the transaction signature to the following values: ``` v: 27 r: 0x8208208208208208208208208208208208208208208208208208208208208200 s: 0x0820820820820820820820820820820820820820820820820820820820820820 ``` Those `r` and `s` values---made of a repeating pattern of `820`'s---are predictable "random numbers" generated deterministically by a human. > The values of `r` and `s` must be 32 bytes long each---or 64 characters in hexadecimal. Since `820` is 3 characters long and 3 is not a divisor of 64, but it is a divisor of 63, the `r` and `s` values are padded with one extra character. > The `s` value is prefixed with a single zero (`0`). The `0` prefix also guarantees that `s < secp256k1n ÷ 2 + 1`. > The `r` value, cannot be prefixed with a zero, as the transaction becomes invalid. Instead it is suffixed with a zero (`0`) which still respects the condition `s < secp256k1n`. 3. We recover the sender of this transaction, i.e., the single-use deployment account. > Thus we obtain an account that can broadcast that transaction, but we also have the warranty that nobody knows the private key of that account. 4. Send exactly 0.08 ethers to this single-use deployment account. 5. Broadcast the deployment transaction. This operation can be done on any chain, guaranteeing that the contract address is always the same and nobody can use that address with a different contract. ### Single-use Registry Deployment Account ``` 0xE6C244a1C10Aa0085b0cf92f04cdaD947C2988b8 ``` This account is generated by reverse engineering it from its signature for the transaction. This way no one knows the private key, but it is known that it is the valid signer of the deployment transaction. > To deploy the registry, 0.08 ethers MUST be sent to this account *first*. ### Registry Contract Address ``` 0x820b586C8C28125366C998641B09DCbE7d4cBF06 ``` The contract has the address above for every chain on which it is deployed. <details> <summary>Raw metadata of <code>./contracts/ERC820Registry.sol</code></summary> ```json { "compiler": { "version": "0.4.24+commit.e67f0147" }, "language": "Solidity", "output": { "abi": [ { "constant": false, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_interfaceHash", "type": "bytes32" }, { "name": "_implementer", "type": "address" } ], "name": "setInterfaceImplementer", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_addr", "type": "address" } ], "name": "getManager", "outputs": [ { "name": "", "type": "address" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": false, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_newManager", "type": "address" } ], "name": "setManager", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_interfaceName", "type": "string" } ], "name": "interfaceHash", "outputs": [ { "name": "", "type": "bytes32" } ], "payable": false, "stateMutability": "pure", "type": "function" }, { "constant": false, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceId", "type": "bytes4" } ], "name": "updateERC165Cache", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_interfaceHash", "type": "bytes32" } ], "name": "getInterfaceImplementer", "outputs": [ { "name": "", "type": "address" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": true, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceId", "type": "bytes4" } ], "name": "implementsERC165InterfaceNoCache", "outputs": [ { "name": "", "type": "bool" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": true, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceId", "type": "bytes4" } ], "name": "implementsERC165Interface", "outputs": [ { "name": "", "type": "bool" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "addr", "type": "address" }, { "indexed": true, "name": "interfaceHash", "type": "bytes32" }, { "indexed": true, "name": "implementer", "type": "address" } ], "name": "InterfaceImplementerSet", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "addr", "type": "address" }, { "indexed": true, "name": "newManager", "type": "address" } ], "name": "ManagerChanged", "type": "event" } ], "devdoc": { "author": "Jordi Baylina and Jacques Dafflon", "methods": { "getInterfaceImplementer(address,bytes32)": { "params": { "_addr": "Address being queried for the implementer of an interface. (If `_addr == 0` then `msg.sender` is assumed.)", "_interfaceHash": "keccak256 hash of the name of the interface as a string. E.g., `web3.utils.keccak256('ERC777Token')`." }, "return": "The address of the contract which implements the interface `_interfaceHash` for `_addr` or `0x0` if `_addr` did not register an implementer for this interface." }, "getManager(address)": { "params": { "_addr": "Address for which to return the manager." }, "return": "Address of the manager for a given address." }, "implementsERC165Interface(address,bytes4)": { "params": { "_contract": "Address of the contract to check.", "_interfaceId": "ERC165 interface to check." }, "return": "`true` if `_contract` implements `_interfaceId`, false otherwise." }, "implementsERC165InterfaceNoCache(address,bytes4)": { "params": { "_contract": "Address of the contract to check.", "_interfaceId": "ERC165 interface to check." }, "return": "`true` if `_contract` implements `_interfaceId`, false otherwise." }, "interfaceHash(string)": { "params": { "_interfaceName": "Name of the interface." }, "return": "The keccak256 hash of an interface name." }, "setInterfaceImplementer(address,bytes32,address)": { "params": { "_addr": "Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.)", "_implementer": "Contract address implementing _interfaceHash for _addr.", "_interfaceHash": "keccak256 hash of the name of the interface as a string. For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface." } }, "setManager(address,address)": { "params": { "_addr": "Address for which to set the new manager.", "_newManager": "Address of the new manager for `addr`." } }, "updateERC165Cache(address,bytes4)": { "params": { "_contract": "Address of the contract for which to update the cache.", "_interfaceId": "ERC165 interface for which to update the cache." } } }, "title": "ERC820 Pseudo-introspection Registry Contract" }, "userdoc": { "methods": { "getInterfaceImplementer(address,bytes32)": { "notice": "Query if an address implements an interface and through which contract." }, "getManager(address)": { "notice": "Get the manager of an address." }, "implementsERC165Interface(address,bytes4)": { "notice": "Checks whether a contract implements an ERC165 interface or not. The result may be cached, if not a direct lookup is performed." }, "implementsERC165InterfaceNoCache(address,bytes4)": { "notice": "Checks whether a contract implements an ERC165 interface or not without using nor updating the cache." }, "interfaceHash(string)": { "notice": "Compute the keccak256 hash of an interface given its name." }, "setInterfaceImplementer(address,bytes32,address)": { "notice": "Sets the contract which implements a specific interface for an address. Only the manager defined for that address can set it. (Each address is the manager for itself until it sets a new manager.)" }, "setManager(address,address)": { "notice": "Sets the `_newManager` as manager for the `_addr` address. The new manager will be able to call `setInterfaceImplementer` for `_addr`." }, "updateERC165Cache(address,bytes4)": { "notice": "Updates the cache with whether the contract implements an ERC165 interface or not." } } } }, "settings": { "compilationTarget": { "./contracts/ERC820Registry.sol": "ERC820Registry" }, "evmVersion": "byzantium", "libraries": {}, "optimizer": { "enabled": true, "runs": 200 }, "remappings": [] }, "sources": { "./contracts/ERC820Registry.sol": { "content": "/* ERC820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address\n * (contract or regular account) can register which interface it supports and\n * which smart contract is responsible for its implementation.\n *\n * Written in 2018 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright\n * and related and neighboring rights to this software to the public domain\n * worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along\n * with this software. If not, see\n * <https://creativecommons.org/publicdomain/zero/1.0/>.\n *\n * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.4.24;\n// IV is value needed to have a vanity address starting with `0x820`.\n// IV: 9513\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n\n/// @title ERC820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC820 Registry.\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-820\ncontract ERC820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant ERC820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC820_ACCEPT_MAGIC\"));\n\n mapping (address => mapping(bytes32 => address)) interfaces;\n mapping (address => address) managers;\n mapping (address => mapping(bytes4 => bool)) erc165Cached;\n\n /// @notice Indicates a contract is the `implementer` of `interfaceHash` for `addr`.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates `newManager` is the address of the new manager for `addr`.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// E.g., `web3.utils.keccak256('ERC777Token')`.\n /// @return The address of the contract which implements the interface `_interfaceHash` for `_addr`\n /// or `0x0` if `_addr` did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == 0 ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : 0;\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface.\n /// @param _implementer Contract address implementing _interfaceHash for _addr.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == 0 ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be a ERC165 hash\");\n if (_implementer != 0 && _implementer != msg.sender) {\n require(\n ERC820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets the `_newManager` as manager for the `_addr` address.\n /// The new manager will be able to call `setInterfaceImplementer` for `_addr`.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for `addr`.\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? 0 : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == 0) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(_contract, _interfaceId) ? _contract : 0;\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n /// The result may be cached, if not a direct lookup is performed.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = noThrowCall(_contract, ERC165ID);\n if (success == 0 || result == 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, INVALID_ID);\n if (success == 0 || result != 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, _interfaceId);\n if (success == 1 && result == 1) {\n return true;\n }\n return false;\n }\n\n /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return `true` if the hash is a ERC165 interface (ending with 28 zeroes), `false` otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\n bytes4 erc165ID = ERC165ID;\n\n assembly {\n let x := mload(0x40) // Find empty storage location using \"free memory pointer\"\n mstore(x, erc165ID) // Place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // To addr\n x, // Inputs are stored at location x\n 0x08, // Inputs are 8 bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n", "keccak256": "0x8eecce3912a15087b3f5845d5a74af7712c93d0a8fcd6f2d40f07ed5032022ab" } }, "version": 1 } ``` </details> ### Interface Name Any interface name is hashed using `keccak256` and sent to `getInterfaceImplementer()`. If the interface is part of a standard, it is best practice to explicitly state the interface name and link to this published [ERC-820] such that other people don't have to come here to look up these rules. For convenience, the registry provides a function to compute the hash on-chain: ``` solidity function interfaceHash(string _interfaceName) public pure returns(bytes32) ``` Compute the keccak256 hash of an interface given its name. > <small>**identifier:** `65ba36c1`</small> > <small>**parameters**</small> > <small>`_interfaceName`: Name of the interface.</small> > <small>**returns:** The `keccak256` hash of an interface name.</small> #### **Approved ERCs** If the interface is part of an approved ERC, it MUST be named `ERC###XXXXX` where `###` is the number of the ERC and XXXXX should be the name of the interface in CamelCase. The meaning of this interface SHOULD be defined in the specified ERC. Examples: - `keccak256("ERC20Token")` - `keccak256("ERC777Token")` - `keccak256("ERC777TokensSender")` - `keccak256("ERC777TokensRecipient")` #### **[ERC-165] Compatible Interfaces** > The compatibility with [ERC-165], including the [ERC165 Cache], has been designed and developed with [William Entriken]. Any interface where the last 28 bytes are zeroes (`0`) SHALL be considered an [ERC-165] interface. **[ERC-165] Lookup** Anyone can explicitly check if a contract implements an [ERC-165] interface using the registry by calling one of the two functions below: ``` solidity function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) ``` Checks whether a contract implements an [ERC-165] interface or not. *NOTE*: The result is cached. If the cache is out of date, it MUST be updated by calling `updateERC165Cache`. (See [ERC165 Cache] for more details.) > <small>**identifier:** `f712f3e8`</small> > <small>**parameters**</small> > <small>`_contract`: Address of the contract to check.</small> > <small>`_interfaceId`: [ERC-165] interface to check.</small> > <small>**returns:** `true` if `_contract` implements `_interfaceId`, false otherwise.</small> ``` solidity function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) ``` Checks whether a contract implements an [ERC-165] interface or not without using nor updating the cache. > <small>**identifier:** `b7056765`</small> > <small>**parameters**</small> > <small>`_contract`: Address of the contract to check.</small> > <small>`_interfaceId`: [ERC-165] interface to check.</small> > <small>**returns:** `true` if `_contract` implements `_interfaceId`, false otherwise.</small> **[ERC-165] Cache** <a id="erc165-cache"></a> Whether a contract implements an [ERC-165] interface or not can be cached manually to save gas. If a contract dynamically changes its interface and relies on the [ERC-165] cache of the [ERC-820] registry, the cache MUST be updated manually---there is no automatic cache invalidation or cache update. Ideally the contract SHOULD automatically update the cache when changing its interface. However anyone MAY update the cache on the contract's behalf. The cache update MUST be done using the `updateERC165Cache` function: ``` solidity function updateERC165Cache(address _contract, bytes4 _interfaceId) public ``` > <small>**identifier:** `a41e7d51`</small> > <small>**parameters**</small> > <small>`_contract`: Address of the contract for which to update the cache.</small> > <small>`_interfaceId`: [ERC-165] interface for which to update the cache.</small> #### **Private User-defined Interfaces** This scheme is extensible. You MAY make up your own interface name and raise awareness to get other people to implement it and then check for those implementations. Have fun but please, you MUST not conflict with the reserved designations above. ### Set An Interface For An Address For any address to set a contract as the interface implementation, it must call the following function of the [ERC-820] registry: ``` solidity function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) public ``` Sets the contract which implements a specific interface for an address. Only the `manager` defined for that address can set it. (Each address is the manager for itself, see the [manager] section for more details.) *NOTE*: If `_addr` and `_implementer` are two different addresses, then: - The `_implementer` MUST implement the `ERC820ImplementerInterface` (detailed below). - Calling `canImplementInterfaceForAddress` on `_implementer` with the given `_addr` and `_interfaceHash` MUST return the `ERC820_ACCEPT_MAGIC` value. *NOTE*: The `_interfaceHash` MUST NOT be an [ERC-165] interface---it MUST NOT end with 28 zeroes (`0`). *NOTE*: The `_addr` MAY be `0`, then `msg.sender` is assumed. This default value simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance. > <small>**identifier:** `29965a1d`</small> > <small>**parameters**</small> > <small>`_addr`: Address to define the interface for (if `_addr == 0` them `msg.sender`: is assumed)</small> > <small>`_interfaceHash`: `keccak256` hash of the name of the interface as a string, for example `web3.utils.keccak256('ERC777TokensRecipient')` for the ERC777TokensRecipient interface.</small> > <small>`_implementer`: Contract implementing `_interfaceHash` for `_addr`.</small> ### Get An Implementation Of An Interface For An Address Anyone MAY query the [ERC-820] Registry to obtain the address of a contract implementing an interface on behalf of some address using the `getInterfaceImplementer` function. ``` solidity function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) public view returns (address) ``` Query if an address implements an interface and through which contract. *NOTE*: If the last 28 bytes of the `_interfaceHash` are zeroes (`0`), then the first 4 bytes are considered an [ERC-165] interface and the registry SHALL forward the call to the contract at `_addr` to see if it implements the [ERC-165] interface (the first 4 bytes of `_interfaceHash`). The registry SHALL also cache [ERC-165] queries to reduce gas consumption. Anyone MAY call the `erc165UpdateCache` function to update whether a contract implements an interface or not. *NOTE*: The `_addr` MAY be `0`, then `msg.sender` is assumed. This default value is consistent with the behavior of the `setInterfaceImplementer` function and simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance. > <small>**identifier:** `aabbb8ca`</small> > <small>**parameters**</small> > <small>`_addr`: Address being queried for the implementer of an interface. (If `_addr == 0` them `msg.sender` is assumed.)</small> > <small>`_interfaceHash`: keccak256 hash of the name of the interface as a string. E.g. `web3.utils.keccak256('ERC777Token')`</small> > <small>**returns:** The address of the contract which implements the interface `_interfaceHash` for `_addr` or `0x0` if `_addr` did not register an implementer for this interface.</small> ### Interface Implementation (`ERC820ImplementerInterface`) ``` solidity interface ERC820ImplementerInterface { /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr`. /// @param addr Address for which the contract will implement the interface /// @param interfaceHash keccak256 hash of the name of the interface /// @return ERC820_ACCEPT_MAGIC only if the contract implements `ìnterfaceHash` for the address `addr`. function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) public view returns(bytes32); } ``` Any contract being registered as the implementation of an interface for a given address MUST implement said interface. In addition if it implements an interface on behalf of a different address, the contract MUST implement the `ERC820ImplementerInterface` shown above. ``` solidity function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) view public returns(bytes32); ``` Indicates whether a contract implements an interface (`interfaceHash`) for a given address (`addr`). If a contract implements the interface (`interfaceHash`) for a given address (`addr`), it MUST return `ERC820_ACCEPT_MAGIC` when called with the `addr` and the `interfaceHash`. If it does not implement the `interfaceHash` for a given address (`addr`), it MUST NOT return `ERC820_ACCEPT_MAGIC`. > <small>**identifier:** `f0083250`</small> > <small>**parameters**</small> > <small>`interfaceHash`: Hash of the interface which is implemented</small> > <small>`addr`: Address for which the interface is implemented</small> > <small>**returns:** `ERC820_ACCEPT_MAGIC` only if the contract implements `ìnterfaceHash` for the address `addr`.</small> The special value `ERC820_ACCEPT_MAGIC` is defined as the `keccka256` hash of the string `"ERC820_ACCEPT_MAGIC"`. ``` solidity bytes32 constant ERC820_ACCEPT_MAGIC = keccak256("ERC820_ACCEPT_MAGIC"); ``` > The reason to return `ERC820_ACCEPT_MAGIC` instead of a boolean is to prevent cases where a contract fails to implement the `canImplementInterfaceForAddress` but implements a fallback function which does not throw. In this case, since `canImplementInterfaceForAddress` does not exist, the fallback function is called instead, executed without throwing and returns `1`. Thus making it appear as if `canImplementInterfaceForAddress` returned `true`. ### Manager The manager of an address (regular account or a contract) is the only entity allowed to register implementations of interfaces for the address. By default, any address is its own manager. The manager can transfer its role to another address by calling `setManager` on the registry contract with the address for which to transfer the manager and the address of the new manager. **`setManager` Function** ``` solidity function setManager(address _addr, address _newManager) public ``` Sets the `_newManager` as manager for the `_addr` address. The new manager will be able to call `setInterfaceImplementer` for `_addr`. If `_newManager` is `0x0`, the manager is reset to `_addr` itself as the manager. > <small>**identifier:** `5df8122f`</small> > <small>**parameters**</small> > <small>`_addr`: Address for which to set the new manager.</small> > <small>`_newManager`: The address of the new manager for `_addr`. (Pass `0x0` to reset the manager to `_addr`.)</small> **`getManager` Function** ``` solidity function getManager(address _addr) public view returns(address) ``` Get the manager of an address. > <small>**identifier:** `3d584063`</small> > <small>**parameters**</small> > <small>`_addr`: Address for which to return the manager.</small> > <small>**returns:** Address of the manager for a given address.</small> ## Rationale This standards offers a way for any type of address (externally owned and contracts) to implement an interface and potentially delegate the implementation of the interface to a proxy contract. This delegation to a proxy contract is necessary for externally owned accounts and useful to avoid redeploying existing contracts such as multisigs and DAOs. The registry can also act as a [ERC-165] cache in order to save gas when looking up if a contract implements a specific [ERC-165] interface. This cache is intentionally kept simple, without automatic cache update or invalidation. Anyone can easily and safely update the cache for any interface and any contract by calling the `updateERC165Cache` function. The registry is deployed using a keyless deployment method relying on a single-use deployment address to ensure no one controls the registry, thereby ensuring trust. ## Backward Compatibility This standard is backward compatible with [ERC-165], as both methods MAY be implemented without conflicting with each other. ## Test Cases Please check the [jbaylina/ERC820] repository for the full test suite. ## Implementation The implementation is available in the repo: [jbaylina/ERC820]. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [EIP-155]: /EIPS/eip-155 [ERC-165]: /EIPS/eip-165 [ERC-672]: https://github.com/ethereum/EIPs/issues/672 [ERC-820]: /EIPS/eip-820 [ERC820 registry smart contract]: https://github.com/jbaylina/ERC820/blob/master/contracts/ERC820Registry.sol [manager]: #manager [lookup]: #get-an-implementation-of-an-interface-for-an-address [ERC165 Cache]: #erc165-cache [Nick's article]: https://medium.com/@weka/how-to-send-ether-to-11-440-people-187e332566b7 [jbaylina/ERC820]: https://github.com/jbaylina/ERC820 [Nick]: https://github.com/Arachnid/ [William Entriken]: https://github.com/fulldecent [ENS]: https://ens.domains/ [ERC-1820]: /EIPS/eip-1820 [erc1820-annoucement]: https://github.com/ethereum/EIPs/issues/820#issuecomment-464109166 [erc820-bug]: https://github.com/ethereum/EIPs/issues/820#issuecomment-452465748 [erc820-fix]: https://github.com/ethereum/EIPs/issues/820#issuecomment-454021564 Fri, 05 Jan 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-820 https://eips.ethereum.org/EIPS/eip-820 Token Exchange Standard Standards Track/ERC ## Simple Summary A standard for token contracts, providing token exchange services thereby facilitating cross token payments. ## Abstract The following standard provides functionally to make payments in the form of any other registered tokens, as well as allow token contracts to store any other tokens in an existing token contract. This standard allows ERC20 token holders to exchange their token with another ERC20 token and use the exchanged tokens to make payments. After a successful payment, the former specified ERC20 tokens, will be stored within the ERC20 token contract they are exchanged with. This proposal uses the term target contract which is used to denote the contract to the token with whom we want to exchange our tokens. ## Motivation Existing token standards do not provide functionality to exchange tokens. Existing token converters reduce the total supply of an existing token, which in the sense destroys the currency. Token converters do not solve this problem and hence discourages creation of new tokens. This solution does not destroy the existing token but in essence preserve them in the token contract that they are exchanged with, which in turn increases the market value of the latter. ## Specification ### Sender Interface This interface must be inherited by a ERC20 token contract that wants to exchange its tokens with another token. #### Storage Variables ##### exchnagedWith This mapping stores the number of tokens exchanged with another token, along with the latter’s address. Every time more tokens are exchanged the integer value is incremented consequently. This mapping acts as a record to denote which target contract holds our tokens. ```solidity mapping ( address => uint ) private exchangedWith; ``` ##### exchangedBy This mapping stores the address of the person who initiated the exchange and the amount of tokens exchanged. ```solidity mapping ( address => uint ) private exhangedBy; ``` #### Methods NOTE: Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned! ##### exchangeToken This function calls the intermediate exchange service contract that handles the exchanges. This function takes the address of the target contract and the amount we want to exchange as parameters and returns boolean `success` and `creditedAmount`. ```solidity function exchangeToken(address _targetContract, uint _amount) public returns(bool success, uint creditedAmount) ``` ##### exchangeAndSpend This function calls an intermediate exchange service contract that handles exchange and expenditure. This function takes the address of the target contract, the amount we want to spend in terms of target contract tokens and address of the receiver as parameters and returns boolean `success`. ```solidity function exchangeAndSpend(address _targetContract, uint _amount,address _to) public returns(bool success) ``` ##### __exchangerCallback This function is called by the exchange service contract to our token contract to deduct calculated amount from our balance. It takes the address of the targert contract , the address of the person who exchanged the tokens and amount to be deducted from exchangers account as parameters and returns boolean `success`. NOTE: It is required that only the exchange service contract has the authority to call this function. ```solidity function __exchangerCallback(address _targetContract,address _exchanger, uint _amount) public returns(bool success) ``` #### Events ##### Exchange This event logs any new exchanges that have taken place. ```solidity event Exchange(address _from, address _ targetContract, uint _amount) ``` ##### ExchangeSpent This event logs any new exchange that have taken place and have been spent immediately. ```solidity event ExchangeSpent(address _from, address _targetContract, address _to, uint _amount) ``` ### Receiver Interface This interface must be inherited by a ERC20 token contract that wants to receive exchanged tokens. #### Storage Variables ##### exchangesRecieved This mapping stores the number of tokens received in terms of another token, along with its address. Every time more tokens are exchanged the integer value is incremented consequently. This mapping acts as a record to denote which tokens do this contract holds apart from its own. ```solidity mapping ( address => uint ) private exchnagesReceived; ``` #### Methods NOTE: Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned! ##### __targetExchangeCallback This function is called by the intermediate exchange service contract. This function should add `_amount` tokens of the target contract to the exchangers address for exchange to be completed successfully. NOTE: It is required that only the exchange service contract has the authority to call this function. ```solidity function __targetExchangeCallback (uint _to, uint _amount) public returns(bool success) ``` ##### __targetExchangeAndSpendCallback This function is called by the intermediate exchange service contract. This function should add `_amount` tokens of the target contract to the exchangers address and transfer it to the `_to` address for the exchange and expenditure to be completed successfully. NOTE: It is required that only the exchange service contract has the authority to call this function. ```solidity function __targetExchangeAndSpendCallback (address _from, address _to, uint _amount) public returns(bool success) ``` #### Events ##### Exchange This event logs any new exchanges that have taken place. ```solidity event Exchange(address _from, address _with, uint _amount) ``` ##### ExchangeSpent This event logs any new exchange that have taken place and have been spent immediately. ```solidity event ExchangeSpent(address _from, address _ targetContract, address _to, uint _amount) ``` ### Exchange Service Contract This is an intermediate contract that provides a gateway for exchanges and expenditure. This contract uses oracles to get the authenticated exchange rates. #### Storage Variables ##### registeredTokens This array stores all the tokens that are registered for exchange. Only register tokens can participate in exchanges. ```solidity address[] private registeredTokens; ``` #### Methods ##### registerToken This function is called by the owner of the token contract to get it’s tokens registered. It takes the address of the token as the parameter and return boolean `success`. NOTE: Before any exchange it must be ensured that the token is registered. ```solidity function registerToken(address _token) public returns(bool success) ``` ##### exchangeToken This function is called by the token holder who wants to exchange his token with the `_targetContract` tokens. This function queries the exchange rate, calculates the converted amount, calls `__exchangerCallback` and calls the `__targetExchangeCallback`. It takes address of the target contract and amount to exchange as parameter and returns boolean `success` and amount credited. ```solidity function exchangeToken(address _targetContract, uint _amount, address _from) public returns(bool success, uint creditedAmount) ``` ##### exchangeAndSpend This function is called by the token holder who wants to exchange his token with the `_targetContract` tokens. This function queries the exchange rate, calculates the converted amount, calls `__exchangerCallback` and calls the `__targetExchangeAndSpendCallback`. It takes address of the target contract and amount to exchange as parameter and returns boolean `success` and amount credited. ```solidity function exchangeAndSpend(address _targetContract, uint _amount, address _from, address _to) public returns(bool success) ``` #### Events ##### Exchanges This event logs any new exchanges that have taken place. ```solidity event Exchange( address _from, address _by, uint _value ,address _target ) ``` ##### ExchangeAndSpent This event logs any new exchange that have taken place and have been spent immediately. ```solidity event ExchangeAndSpent ( address _from, address _by, uint _value ,address _target ,address _to) ``` ### Diagramatic Explanation #### Exchanging Tokens ![token-exchange-standard-visual-representation-1](/assets/eip-823/eip-823-token-exchange-standard-visual-representation-1.png) NOTE: After the successful exchange the contract on right owns some tokens of the contract on the left. #### Exchanging And Spending Tokens ![token-exchange-standard-visual-representation-2](/assets/eip-823/eip-823-token-exchange-standard-visual-representation-2.png) NOTE: After the successful exchange the contract on right owns some tokens of the contract on the left. ## Rationale Such a design provides a consistent exchange standard applicable to all ERC20 tokens that follow it. The primary advantage for of this strategy is that the exchanged tokens will not be lost. They can either be spent or preserved. Token convert face a major drawback of destroying tokens after conversion. This mechanism treats tokens like conventional currency where tokens are not destroyed but are stored. ## Backward Compatibility This proposal is fully backward compatible. Tokens extended by this proposal should also be following ERC20 standard. The functionality of ERC20 standard should not be affected by this proposal but will provide additional functionality to it. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 06 Jan 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-823 https://eips.ethereum.org/EIPS/eip-823 URI Format for Ethereum Standards Track/ERC https://ethereum-magicians.org/t/eip-831-uri-format-for-ethereum/10105 ## Abstract URIs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URI format allows for instant invocation of the user's preferred wallet application. ## Specification ### Syntax Ethereum URIs contain "ethereum" or "eth" in their schema (protocol) part and are constructed as follows: request = "eth" [ "ereum" ] ":" [ prefix "-" ] payload prefix = STRING payload = STRING ### Semantics `prefix` is optional and defines the use-case for this URI. If no prefix is given: "pay-" is assumed to be concise and ensure backward compatibility to [EIP-67](/EIPS/eip-67). When the prefix is omitted, the payload must start with `0x`. Also prefixes must not start with `0x`. So starting with `0x` can be used as a clear signal that there is no prefix. `payload` is mandatory and the content depends on the prefix. Structuring of the content is defined in the ERC for the specific use-case and not in the scope of this document. One example is [EIP-681](./eip-681) for the pay- prefix. ## Rationale The need for this ERC emerged when refining EIP-681. We need a container that does not carry the weight of the use-cases. EIP-67 was the first attempt on defining Ethereum-URIs. This ERC tries to keep backward compatibility and not break existing things. This means EIP-67 URIs should still be valid and readable. Only if the prefix feature is used, EIP-67 parsers might break. No way was seen to avoid this and innovate on the same time. This is also the reason this open prefix approach was chosen to being able to adopt to future use-cases and not block the whole "ethereum:" scheme for a limited set of use-cases that existed at the time of writing this. ## Security Considerations There are no known security considerations at this time. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 15 Jan 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-831 https://eips.ethereum.org/EIPS/eip-831 ABI specification for REVERT reason string Standards Track/ERC https://ethereum-magicians.org/t/eip-838-what-is-the-current-status/14671 ## Abstract This proposal specifies how to encode potential error conditions in the JSON ABI of a smart contract. A high-level language could then provide a syntax for declaring and throwing these errors. The compiler will encode these errors in the reason parameter of the REVERT opcode in a way that can be easily reconstructed by libraries such as web3. ## Motivation It's important to provide clear feedback to users (and developers) about what went wrong with their Ethereum transactions. The REVERT opcode is a step in the right direction, as it allows smart contract developers to encode a message describing the failure in the reason parameter. There is an implementation under review in Solidity that accepts a string, thus providing a low-level interface to this parameter. However, standardizing a method for passing errors from this parameter back to clients will bring many benefits to both users and developers. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ## Specification To conform to this specification, compilers producing JSON ABIs SHOULD include error declarations alongside functions and events. Each error object MUST contain the keys name (string) and arguments (same types as the function’s inputs list). The value of type MUST be "error". Example: ``` { "type": "error", "name": "InsufficientBalance", "arguments": [ { "name": "amount", "type": "uint256" } ] } ``` A selector for this error can be computed from its signature (InsufficientBalance() for the example above) in the same way that it's currently done for public functions and events. This selector MUST be included in the reason string so that clients can perform a lookup. Any arguments for the error are RLP encoded in the same way as return values from functions. The exact format in which both the selector and the arguments are encoded is to be defined. The Solidity implementation mentioned above leaves room for expansion by prefixing the free-form string with uint256(0). A high-level language like Solidity can then implement a syntax like this: ``` contract MyToken { error InsufficientFunds(uint256 amount); function transfer(address _to, uint256 _amount) { if (balances[msg.sender] <= _amount) throw InsufficientFunds(_amount); ... } ... } ``` ### Possible extensions 1. A NatSpec comment above the error declaration can be used to provide a default error message. Arguments to the error can be interpolated in the message string with familiar NatSpec syntax. ``` /// @notice You don't have enough funds to transfer `amount`. error InsufficientFunds(uint256 amount); ``` 2. A function may declare to its callers which errors it can throw. A list of these errors must be included in the JSON ABI item for that function, under the `errors` key. Example: ``` function transfer(address _to, uint256 _amount) throws(InsufficientFunds); ``` Special consideration should be given to error overloading if we want to support a similar syntax in the future, as errors with same name but different arguments will produce a different selector. ## Rationale Needs discussion. <!-- TODO --> ## Backwards Compatibility Apps and tools that have not implemented this spec can ignore the encoded reason string when it's not prefixed by zero. ## Security Considerations Needs discussion. <!-- TODO --> ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 20 Aug 2020 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-838 https://eips.ethereum.org/EIPS/eip-838 Reduce block reward and delay difficulty bomb Standards Track/Core ## Simple Summary Reduce the block reward to 1 ETH and delay the difficulty bomb. ## Abstract The current public Ethereum network has a hashrate that corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint. Recent research developments also now time the switch to POS as sometime in 2019 and as a result there is need to further delay the difficulty bomb so the network doesn't grind to a halt. ## Motivation The current public Ethereum network has a hashrate of 296 TH/s. This hashrate corresponds to a power usage of roughly [1 TW](/assets/eip-858/calculations) and yearly energy consumption of 8.8 TWh (roughly 0.04% of [total](https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption) global electricity consumption). A future switch to full Proof of Stake will solve this issue entirely. Yet that switch remains enough in the future that action should be taken in the interim to limit excess harmful side affects of the present network. ## Specification Delay difficulty bomb by 2,000,000 blocks Adjust block, uncle, and nephew rewards to reflect a new block reward of 1 ETH. ## Rationale This will delay the difficulty bomb by roughly a year. The difficulty bomb remains a community supported mechanism to aid a future transition to POS. The network hashrate provides security by reducing the likelihood that an adversary could mount a 51% attack. A static block reward means that factors (price) may be such that participation in mining grows unchecked. This growth may be counterproductive and work to also grow and potential pool of adversaries. The means we have to arrest this growth is to reduce the appeal of mining and the most direct way to do that is to reduce the block reward. ## Backwards Compatibility This EIP is consensus incompatible with the current public Ethereum chain and would cause a hard fork when enacted. The resulting fork would allow users to chose between two chains: a chain with a block reward of 1 ETH/block and another with a block reward of 3 ETH/block. This is a good choice to allow users to make. In addition, the difficulty bomb would be delayed - ensuring the network would not grind to a halt. ## Test Cases Tests have, as yet, not been completed. ## Implementation No implementation including both block reward and difficulty adjustment is currently available. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 29 Jan 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-858 https://eips.ethereum.org/EIPS/eip-858 Standardized Ethereum Recovery Proposals Meta/ https://ethereum-magicians.org/t/eip-867-standardized-ethereum-recovery-proposals-erps/139 ## Simple Summary Provide a standardized format for Ethereum Recovery Proposals (ERPs), which relate to recovery of certain classes of lost funds. Individual ERPs will follow the same process as any EIP, but will be formatted and evaluated in a standard way to ensure consistency and transparency. **This EIP does not advocate for or against the acceptance of any particular recovery proposals, nor would its acceptance alone result in any state changes to the blockchain.** ## Abstract This proposal identifies a common solution method that can be used to address certain classes of lost funds on the Ethereum blockchain. In particular, it is intended to address cases where there is no disagreement about the right outcome between directly affected parties, enabling timely and low-risk solutions to many issues that have already occurred or are likely to occur again as Ethereum grows. The solution method is divided into three parts: 1. Standards that will need to be met by any follow-on ERP in order to be considered for approval. 2. Recommendations for a common format for ERPs to use to specify a set of corrective actions that can be interpreted by clients. 3. Guidelines for client teams to implement code that can read, interpret, and apply the corrective actions at a specific block. The set of possible corrective actions is intentionally limited to minimize risk associated with any ERP. ## Motivation The issue of fund recovery on the Ethereum blockchain is often controversial. Frozen fund recovery proposals are almost never successful due to the relatively ad-hoc nature of such requests and the subjectivity that is often required to evaluate the merits. This EIP attempts to remove these barriers by providing both a standardized format for fund recovery EIPs and an objective standard by which to measure future proposals. ## Specification This EIP describes a common format to be used for a subclass of EIPs, referred to as ethereum recovery proposals (ERPs), that propose an irregular state change required to address a fund recovery scenario that cannot be addressed using the standard protocol. Each ERP will reference this EIP will follow the guidelines set out here. The purpose of each ERP is (a) to clearly describe the issue to be corrected, (b) to describe why an irregular state change is both necessary and justified, and (c) to demonstrate that the proposed actions will achieve the ERP's objectives. Each ERP will be required to use a standard format to represent the set of proposed state changes and must include a verification script that can reliably generate those changes. ERPs that do not meet (at least) these requirements will not be considered for approval. Each ERP should contain the following items: - **Preamble**: EIP (RFC 822) header containing metadata about the ERP, including the EIP number, a short title (44 character maximum), and the real names (and optional contact information) for each author. - **Simple Summary**: A simplified and layman-accessible explanation of the ERP. - **Detailed description**: A human-readable description of the proposed corrective actions and the criteria used to determine the proposed actions. - **Justification**: A concise description of why the corrective actions are both reasonable and unlikely to be challenged by any directly affected party. - **Verification script**: A machine-readable script that outputs one State Change Object. The script should clearly implement the selection and action generating logic outlined in the description such that reviewers can independently re-generate an identical State Change Object. - **State Change Object**: The output of the verification script and the input to the ethereum clients. Primarily, it specifies the complete set of proposed state change actions. - **Appendix (optional)**: with supporting evidence. Attachments in the appendix may include documents verifying details specified as part of the recovery proposal description. The following sections give more detailed descriptions of the expectations for the Justification, Verification Script, and the format of the State Change Object. ### Justification A concise description of why this action is both reasonable (cannot be accomplished without an irregular state change) and unlikely to be challenged by a *directly* affected party. **Considerable example** (concise, includes supporting evidence, no negative impact): *A crowdsale run by XYZ incorrectly published the testnet address of their crowdsale contract to their public website at the start of their crowdsale on Jan 19, 2018. 501 ETH was sent by 328 users on the mainnet to the incorrect address between block 4,235,987 and 4,236,050. See here for the testnet contract, and see here for the transactions to the same address on the mainnet. See here for a statement made by XYZ on their website. Because there is a contract at this address on the testnet and the corresponding nonce for the creator address has already been used on the mainnet, it is considered effectively impossible that anyone coincidentally holds the private key. We have verified that all transactions came from addresses with no associated code, so there should be no issue returning eth to the senders.* **Insufficient example** (not enough detail, no supporting evidence): *We accidentally put the wrong contract address up on our website. Can you please refund any eth sent to 0x1234 back to the senders. Thanks.* **Unacceptable example** (not objective, one person’s word against another): *I sent tokens to X for services and he did a lousy job. I want my money back, but he won’t refund me. Please help!!* ### Verification Script A machine-readable script that outputs a single State Change Object. This script should be implemented so that it is easily audited by a reviewer. Verification scripts should be javascript files that may use the [web3.js](https://github.com/ethereum/web3.js/) library. There are a few guidelines for verification scripts: - Scripts should always be written to be as concise as reasonably possible, and anyone executing the verification script should review it first to verify that it does not contain any unsafe operations. - No verification script should ever require an unlocked ethereum wallet - The script should hardcode the highest block included during execution (otherwise the results may differ between runs). The purpose of the ERP Verification script is to unambiguously specify (through code) the criteria used to compute the set of State Change Actions. The script’s output, as described above, will be the input used by all Ethereum clients. Client teams should avoid manually pre-processing the artifact or using the artifact to simply guide changes in the code. Instead, the artifact should be bundled with the client and processed directly by the client at the specified block. This will minimize the amount of client effort required for each ERP and help to ensure compatibility between clients. We anticipate that some ERP Verification scripts may be trivial, but we recommend their inclusion for consistency. ### State Change Object The State Change Object is a standard format that will be interpretable by all Ethereum clients. It is a single JSON object containing the following fields: - **erpId**: A string identifier for this ERP (likely the associated EIP number, e.g. “EIP-1234”). This will be converted from ascii to a hex string, then added as extra data on the target block. - **targetBlock**: The block at which the stateChange should be applied. Clients would use this to determine when a set of state changes should occur - **actions**: An array of State Change Actions. - **metadata** - **sourceBlock**: The highest block considered by the script when it was run. - **version**: The version of the verification script when it was run. ### State Change Actions A State Change action is a JSON object that includes a “type” field and a set of “data” fields, where the contents of the data fields are dependent on the type and must follow the schema defined for that type. This allows clients to support a limited set of operations initially and add more based on a subsequent EIP if needed. Support for the following action types should be implemented by clients upon adoption of this EIP: #### weiTransfer The `weiTransfer` action transfers ETH from one address to another. *Data fields* - **type** (*string*): `weiTransfer` - **fromAddress** (*hex string*): The address from which ETH should be transferred - **toAddress** (*hex string*): The address to which ETH should be sent - **value** (*decimal string*): The amount of ETH to be transferred, in units of wei. The value must be a whole number greater than zero. #### storeCode The `storeCode` action stores the given code at the given address. *Data fields* - **type** (*string*): `storeCode` - **toAddress** (*hex string*): The address to which the contract should be restored. - **expectedCodeHash** (*hex string*): the expected hash of the code already at the toAddress.The empty string should be used if no code is expected at the toAddress. In all other cases, the “0x” prefix is optional. - **code** (*hex string*): the new bytecode associated with the contract ### Appendix (Optional) The appendix can include additional supporting evidence or attachments that will help reviewers understand or verify the claims made in the ERP. For the storeCode operation, it should include the proposed contract source (e.g. Solidity) as well as the other details required such that a reviewer can compile the source and generate the same bytecode. It should also include the source that was originally stored at that address, if possible/applicable. If the two contracts are not identical, changes should be noted. If they are identical, the author should indicate why no changes are necessary (this is unlikely). Additionally, any relevant reviews, audits, and test cases should be included to the extent that they address the issues encountered with the original contract. If accepted, an ERP could easily compile the block at while the changes are to take place, and the source of the actions (which would be the output of the script, in a standardized object output). These can be bundled with the client for seamless execution. ## ERP Approval Process ERPs are a subclass of EIPs and will, therefore, follow the same approval process. ### Testing *The ERP authors are currently seeking feedback from client teams about the proper testing procedures* ## Ethereum Client Implementation Clients that choose to adopt the proposal outlined in this EIP will implement a module that scans a designated directory for SCO files (each time the client process launches) to construct a mapping between target blocks and SCO file names. When starting work on a new block, clients should first consult the set of SCO target blocks discovered and determine if there are any recovery actions required for the current block. E.g. in this example, `erpsByTargetBlock` is the mapping between the target block number associated with each ERP's State Change Object and a reference (i.e. file name) to the resource with the actual data. ``` if (erpsByTargetBlock.get(currentBlock) != null) { try { applyRecoveryActions(erpsByTargetBlock.get(currentBlock)); } catch (e) { // recovery actions should be treated as a batch. // If one fails, they all fail. } } // continue with normal block processing... ``` The `applyRecoveryActions` method must apply the recovery actions in the same order as they are stored in the SCO file. Clients are responsible for ensuring that no State Change Action will result in an account transferring an amount that is greater than its current balance. The `toAddress` for both `weiTransfer` and `storeCode` should always be a valid address (i.e. never `0x0`). Additionally, each block affected by an ERP should include extra data to indicate that the state change occurred. The extra data included in the block should be the erpId found in the SCO file, converted to hex (i.e. `hexStringToBytes(asciiToHex(erpId))`). Clients should also validate that the expected header appears in the target block if the block is received from a peer. The ERP should link to pull requests for each client repository, and these pull requests should link back to the ERP and also contain its EIP preamble and summary. Each PR associated with an ERP should consist of a single file (the SCO file) added to the client’s designated SCO directory. No additional client code should be required. ### Limitations of this EIP This EIP is focused on standardizing how recovery proposals can be formatted, to optimize readability and eliminate or minimize as much as possible the potential for mistakes or intentional abuses. The following are considered out of scope from this EIP: - Which fund recovery proposals, if any, should be accepted for implementation. - How common classes of recovery proposal plaintiff may organize ERPs representing a collective group of individual parties ## Rationale The primary consideration for the approach described above was to minimize the amount of risk associated with recovery actions that would otherwise not have a viable solution. A secondary consideration was to standardize the format used in the proposals for recovery actions. First, including a verification script guarantees that the way in which the recovery actions were determined is unambiguous. This does not mean that the recovery actions are necessarily correct, only that the logic used to determine them is fully specified and auditable. Second, requiring that the output of the verification script is directly interpretable by client programs minimizes the work necessary for each client to adopt a particular ERP. It also reduces the risk that two clients will make different decisions about the implementation of a particular ERP. Third, action types are intentionally limited and inflexible, which reduces the likelihood of unintended consequences or maliciously constructed files affecting the blockchain state. The format is easily extensible with new actions types if needed but that would require a separate EIP. ## Implementation A reference implementation has been written for the EthereumJ platform. See the pull request [here](https://github.com/ethereum/ethereumj/pull/1004#commits-pushed-1105610). ## ERP Examples This section will include examples and SCO resource files, as well as a brief tutorial on how to test using a private testnet. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 02 Feb 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-867 https://eips.ethereum.org/EIPS/eip-867 Node Discovery v4 ENR Extension Standards Track/Networking https://github.com/ethereum/devp2p/issues/44 # Abstract This EIP defines an extension to Node Discovery Protocol v4 to enable authoritative resolution of [Ethereum Node Records (ENR)](/EIPS/eip-778). # Motivation To bridge current and future discovery networks and to aid the implementation of other relay mechanisms for ENR such as DNS, we need a way to request the most up-to-date version of a node record. This EIP provides a way to request it using the existing discovery protocol. # Specification Implementations of Node Discovery Protocol v4 should support two new packet types, a request and reply of the node record. The existing ping and pong packets are extended with a new field containing the sequence number of the ENR. ### Ping Packet (0x01) ```text packet-data = [version, from, to, expiration, enr-seq] ``` `enr-seq` is the current sequence number of the sending node's record. All other fields retain their existing meaning. ### Pong Packet (0x02) ```text packet-data = [to, ping-hash, expiration, enr-seq] ``` `enr-seq` is the current sequence number of the sending node's record. All other fields retain their existing meaning. ### ENRRequest Packet (0x05) ```text packet-data = [ expiration ] ``` When a packet of this type is received, the node should reply with an ENRResponse packet containing the current version of its record. To guard against amplification attacks, the sender of ENRRequest should have replied to a ping packet recently (just like for FindNode). The `expiration` field, a UNIX timestamp, should be handled as for all other existing packets i.e. no reply should be sent if it refers to a time in the past. ### ENRResponse Packet (0x06) ```text packet-data = [ request-hash, ENR ] ``` This packet is the response to ENRRequest. - `request-hash` is the hash of the entire ENRRequest packet being replied to. - `ENR` is the node record. The recipient of the packet should verify that the node record is signed by node who sent ENRResponse. ## Resolving Records To resolve the current record of a node public key, perform a recursive Kademlia lookup using the FindNode, Neighbors packets. When the node is found, send ENRRequest to it and return the record from the response. # Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 02 Feb 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-868 https://eips.ethereum.org/EIPS/eip-868 Simpler NFT standard with batching and native atomic swaps Standards Track/ERC https://github.com/ethereum/EIPs/issues/875 ## Summary A simple non fungible token standard that allows batching tokens into lots and settling p2p atomic transfers in one transaction. You can test out an example implementation on rinkeby here: https://rinkeby.etherscan.io/address/0xffab5ce7c012bc942f5ca0cd42c3c2e1ae5f0005 and view the repo here: https://github.com/alpha-wallet/ERC-Example ## Purpose While other standards allow the user to transfer a non-fungible token, they require one transaction per token, this is heavy on gas and partially responsible for clogging the ethereum network. There are also few definitions for how to do a simple atomic swap. ## Rinkeby example This standard has been implemented in an example contract on rinkeby: https://rinkeby.etherscan.io/address/0xffab5ce7c012bc942f5ca0cd42c3c2e1ae5f0005 ## Specification ### function name() constant returns (string name) returns the name of the contract e.g. CarLotContract ### function symbol() constant returns (string symbol) Returns a short string of the symbol of the in-fungible token, this should be short and generic as each token is non-fungible. ### function balanceOf(address _owner) public view returns (uint256[] balance) Returns an array of the users balance. ### function transfer(address _to, uint256[] _tokens) public; Transfer your unique tokens to an address by adding an array of the token indices. This compares favourable to ERC721 as you can transfer a bulk of tokens in one go rather than one at a time. This has a big gas saving as well as being more convenient. ### function transferFrom(address _from, address _to, uint256[] _tokens) public; Transfer a variable amount of tokens from one user to another. This can be done from an authorised party with a specified key e.g. contract owner. ## Optional functions ### function totalSupply() constant returns (uint256 totalSupply); Returns the total amount of tokens in the given contract, this should be optional as assets might be allocated and issued on the fly. This means that supply is not always fixed. ### function ownerOf(uint256 _tokenId) public view returns (address _owner); Returns the owner of a particular token, I think this should be optional as not every token contract will need to track the owner of a unique token and it costs gas to loop and map the token id owners each time the balances change. ### function trade(uint256 expiryTimeStamp, uint256[] tokenIndices, uint8 v, bytes32 r, bytes32 s) public payable A function which allows a user to sell a batch of non-fungible tokens without paying for the gas fee (only the buyer has to) in a p2p atomic swap. This is achieved by signing an attestation containing the amount of tokens to sell, the contract address, an expiry timestamp, the price and a prefix containing the ERC spec name and chain id. A buyer can then pay for the deal in one transaction by attaching the appropriate ether to satisfy the deal. This design is also more efficient as it allows orders to be done offline until settlement as opposed to creating orders in a smart contract and updating them. The expiry timestamp protects the seller against people using old orders. This opens up the gates for a p2p atomic swap but should be optional to this standard as some may not have use for it. Some protections need to be added to the message such as encoding the chain id, contract address and the ERC spec name to prevent replays and spoofing people into signing message that allow a trade. ## Interface ```solidity contract ERC165 { /// @notice Query if a contract implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 /// @dev Interface identification is specified in ERC-165. This function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceID` and /// `interfaceID` is not 0xffffffff, `false` otherwise function supportsInterface(bytes4 interfaceID) external view returns (bool); } interface ERC875 /* is ERC165 */ { event Transfer(address indexed _from, address indexed _to, uint256[] tokenIndices); function name() constant public returns (string name); function symbol() constant public returns (string symbol); function balanceOf(address _owner) public view returns (uint256[] _balances); function transfer(address _to, uint256[] _tokens) public; function transferFrom(address _from, address _to, uint256[] _tokens) public; } //If you want the standard functions with atomic swap trading added interface ERC875WithAtomicSwapTrading is ERC875 { function trade( uint256 expiryTimeStamp, uint256[] tokenIndices, uint8 v, bytes32 r, bytes32 s ) public payable; } ``` ## Example implementation Please visit this [repo](https://github.com/alpha-wallet/ERC875) to see an example implementation ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 08 Feb 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-875 https://eips.ethereum.org/EIPS/eip-875 DGCL Token Standards Track/ERC # Delaware General Corporations Law (DGCL) compatible share token Ref: [proposing-an-eip-for-DGCL-tokens](https://forum.ethereum.org/discussion/17200/proposing-an-eip-for-regulation-a-Tokens) ## Simple Summary An `ERC-20` compatible token that conforms to [Delaware State Senate, 149th General Assembly, Senate Bill No. 69: An act to Amend Title 8 of the Delaware Code Relating to the General Corporation Law](https://legis.delaware.gov/json/BillDetail/GenerateHtmlDocument?legislationId=25730&legislationTypeId=1&docTypeId=2&legislationName=SB69), henceforth referred to as 'The Act'. ## Abstract The recently amended 'Title 8 of the Delaware Code Relating to the General Corporation Law' now explicitly allows for the use of blockchains to maintain corporate share registries. This means it is now possible to create a tradable `ERC-20` token where each token represents a share issued by a Delaware corporation. Such a token must conform to the following principles over and above the `ERC-20` standard. 1. Token owners must have their identity verified. 2. The token contract must provide the following three functions of a `Corporations Stock ledger` (Ref: Section 224 of The Act): 1. Reporting: It must enable the corporation to prepare the list of shareholders specified in Sections 219 and 220 of The Act. 2. It must record the information specified in Sections 156, 159, 217(a) and 218 of The Act: - Partly paid shares - Total amount paid - Total amount to be paid 3. Transfers of shares as per section 159 of The Act: It must record transfers of shares as governed by Article 8 of subtitle I of Title 6. 3. Each token MUST correspond to a single share, each of which would be paid for in full, so there is no need to record information concerning partly paid shares, and there are no partial tokens. 4. There must be a mechanism to allow a shareholder who has lost their private key, or otherwise lost access to their tokens to have their address `cancelled` and the tokens re-issued to a new address. ## Motivation 1. Delaware General Corporation Law requires that shares issued by a Delaware corporation be recorded in a share registry. 2. The share registry can be represented by an `ERC-20` token contract that is compliant with Delaware General Corporation Law. 3. This standard can cover equity issued by any Delaware corporation, whether private or public. By using a `DGCL` compatible token, a firm may be able to raise funds via IPO, conforming to Delaware Corporations Law, but bypassing the need for involvement of a traditional Stock Exchange. There are currently no token standards that conform to the `DGCL` rules. `ERC-20` tokens do not support KYC/AML rules required by the General Corporation Law, and do not provide facilities for the exporting of lists of shareholders. ### What about ERC-721? The proposed standard could easily be used to enhance `ERC-721`, adding features for associating tokens with assets such as share certificates. While the `ERC-721` token proposal allows for some association of metadata with an Ethereum address, its uses are _not completely aligned_ with The Act, and it is not, in its current form, fully `ERC-20` compatible. ## Specification The `ERC-20` token provides the following basic features: contract ERC20 { function totalSupply() public view returns (uint256); function balanceOf(address who) public view returns (uint256); function transfer(address to, uint256 value) public returns (bool); function allowance(address owner, address spender) public view returns (uint256); function transferFrom(address from, address to, uint256 value) public returns (bool); function approve(address spender, uint256 value) public returns (bool); event Approval(address indexed owner, address indexed spender, uint256 value); event Transfer(address indexed from, address indexed to, uint256 value); } This will be extended as follows: /** * An `ERC20` compatible token that conforms to Delaware State Senate, * 149th General Assembly, Senate Bill No. 69: An act to Amend Title 8 * of the Delaware Code Relating to the General Corporation Law. * * Implementation Details. * * An implementation of this token standard SHOULD provide the following: * * `name` - for use by wallets and exchanges. * `symbol` - for use by wallets and exchanges. * * The implementation MUST take care not to allow unauthorised access to * share-transfer functions. * * In addition to the above the following optional `ERC20` function MUST be defined. * * `decimals` — MUST return `0` as each token represents a single share and shares are non-divisible. * * @dev Ref https://github.com/ethereum/EIPs/pull/884 */ contract ERC884 is ERC20 { /** * This event is emitted when a verified address and associated identity hash are * added to the contract. * @param addr The address that was added. * @param hash The identity hash associated with the address. * @param sender The address that caused the address to be added. */ event VerifiedAddressAdded( address indexed addr, bytes32 hash, address indexed sender ); /** * This event is emitted when a verified address and associated identity hash are * removed from the contract. * @param addr The address that was removed. * @param sender The address that caused the address to be removed. */ event VerifiedAddressRemoved(address indexed addr, address indexed sender); /** * This event is emitted when the identity hash associated with a verified address is updated. * @param addr The address whose hash was updated. * @param oldHash The identity hash that was associated with the address. * @param hash The hash now associated with the address. * @param sender The address that caused the hash to be updated. */ event VerifiedAddressUpdated( address indexed addr, bytes32 oldHash, bytes32 hash, address indexed sender ); /** * This event is emitted when an address is cancelled and replaced with * a new address. This happens in the case where a shareholder has * lost access to their original address and needs to have their share * reissued to a new address. This is the equivalent of issuing replacement * share certificates. * @param original The address being superseded. * @param replacement The new address. * @param sender The address that caused the address to be superseded. */ event VerifiedAddressSuperseded( address indexed original, address indexed replacement, address indexed sender ); /** * Add a verified address, along with an associated verification hash to the contract. * Upon successful addition of a verified address, the contract must emit * `VerifiedAddressAdded(addr, hash, msg.sender)`. * It MUST throw if the supplied address or hash are zero, or if the address has already been supplied. * @param addr The address of the person represented by the supplied hash. * @param hash A cryptographic hash of the address holder's verified information. */ function addVerified(address addr, bytes32 hash) public; /** * Remove a verified address, and the associated verification hash. If the address is * unknown to the contract then this does nothing. If the address is successfully removed, this * function must emit `VerifiedAddressRemoved(addr, msg.sender)`. * It MUST throw if an attempt is made to remove a verifiedAddress that owns tokens. * @param addr The verified address to be removed. */ function removeVerified(address addr) public; /** * Update the hash for a verified address known to the contract. * Upon successful update of a verified address the contract must emit * `VerifiedAddressUpdated(addr, oldHash, hash, msg.sender)`. * If the hash is the same as the value already stored then * no `VerifiedAddressUpdated` event is to be emitted. * It MUST throw if the hash is zero, or if the address is unverified. * @param addr The verified address of the person represented by the supplied hash. * @param hash A new cryptographic hash of the address holder's updated verified information. */ function updateVerified(address addr, bytes32 hash) public; /** * Cancel the original address and reissue the tokens to the replacement address. * Access to this function MUST be strictly controlled. * The `original` address MUST be removed from the set of verified addresses. * Throw if the `original` address supplied is not a shareholder. * Throw if the `replacement` address is not a verified address. * Throw if the `replacement` address already holds tokens. * This function MUST emit the `VerifiedAddressSuperseded` event. * @param original The address to be superseded. This address MUST NOT be reused. */ function cancelAndReissue(address original, address replacement) public; /** * The `transfer` function MUST NOT allow transfers to addresses that * have not been verified and added to the contract. * If the `to` address is not currently a shareholder then it MUST become one. * If the transfer will reduce `msg.sender`'s balance to 0 then that address * MUST be removed from the list of shareholders. */ function transfer(address to, uint256 value) public returns (bool); /** * The `transferFrom` function MUST NOT allow transfers to addresses that * have not been verified and added to the contract. * If the `to` address is not currently a shareholder then it MUST become one. * If the transfer will reduce `from`'s balance to 0 then that address * MUST be removed from the list of shareholders. */ function transferFrom(address from, address to, uint256 value) public returns (bool); /** * Tests that the supplied address is known to the contract. * @param addr The address to test. * @return true if the address is known to the contract. */ function isVerified(address addr) public view returns (bool); /** * Checks to see if the supplied address is a shareholder. * @param addr The address to check. * @return true if the supplied address owns a token. */ function isHolder(address addr) public view returns (bool); /** * Checks that the supplied hash is associated with the given address. * @param addr The address to test. * @param hash The hash to test. * @return true if the hash matches the one supplied with the address in `addVerified`, or `updateVerified`. */ function hasHash(address addr, bytes32 hash) public view returns (bool); /** * The number of addresses that hold tokens. * @return the number of unique addresses that hold tokens. */ function holderCount() public view returns (uint); /** * By counting the number of token holders using `holderCount` * you can retrieve the complete list of token holders, one at a time. * It MUST throw if `index >= holderCount()`. * @param index The zero-based index of the holder. * @return the address of the token holder with the given index. */ function holderAt(uint256 index) public view returns (address); /** * Checks to see if the supplied address was superseded. * @param addr The address to check. * @return true if the supplied address was superseded by another address. */ function isSuperseded(address addr) public view returns (bool); /** * Gets the most recent address, given a superseded one. * Addresses may be superseded multiple times, so this function needs to * follow the chain of addresses until it reaches the final, verified address. * @param addr The superseded address. * @return the verified address that ultimately holds the share. */ function getCurrentFor(address addr) public view returns (address); } ### Securities Exchange Commission Requirements The Securities Exchange Commission (SEC) has additional requirements as to how a crowdsale ought to be run and what information must be made available to the general public. This information is however out of scope from this standard, though the standard does support the requirements. For example: The SEC requires a crowdsale's website display the amount of money raised in US Dollars. To support this a crowdsale contract minting these tokens must maintain a USD to ETH conversion rate (via Oracle or some other mechanism) and must record the conversion rate used at time of minting. Also, depending on the type of raise, the SEC (or other statutory body) can apply limits to the number of shareholders allowed. To support this the standard provides the `holderCount` and `isHolder` functions which a crowdsale can invoke to check that limits have not been exceeded. ### Use of the Identity `hash` value Implementers of a crowdsale, in order to comply with The Act, must be able to produce an up-to-date list of the names and addresses of all shareholders. It is not desirable to include those details in a public blockchain, both for reasons of privacy, and also for reasons of economy. Storing arbitrary string data on the blockchain is strongly discouraged. Implementers should maintain an off-chain private database that records the owner's name, residential address, and Ethereum address. The implementer must then be able to extract the name and address for any address, and hash the name + address data and compare that hash to the hash recorded in the contract using the `hasHash` function. The specific details of this system are left to the implementer. It is also desirable that the implementers offer a REST API endpoint along the lines of GET https://<host>/<pathPrefix>/:ethereumAddress -> [true|false] to enable third party auditors to verify that a given Ethereum address is known to the implementers as a verified address. How the implementers verify a person's identity is up to them and beyond the scope of this standard. ### Handling users who have lost access to their addresses A traditional share register is typically managed by a Transfer Agent who is authorised to maintain the register accurately, and to handle shareholder enquiries. A common request is for share certificates to be reissued in the case where the shareholder has lost or destroyed their original. Token implementers can handle that via the `cancelAndReissue` function, which must perform the various changes to ensure that the old address now points to the new one, and that cancelled addresses are not then reused. ### Permissions management It is not desirable that anyone can add, remove, update, or supersede verified addresses. How access to these functions is controlled is outside of the scope of this standard. ## Rationale The proposed standard offers as minimal an extension as possible over the existing `ERC-20` standard in order to conform to the requirements of The Act. Rather than return a `bool` for successful or unsuccessful completion of state-changing functions such as `addVerified`, `removeVerified`, and `updateVerified`, we have opted to require that implementations `throw` (preferably by using the [forthcoming `require(condition, 'fail message')` syntax](https://github.com/ethereum/solidity/issues/1686#issuecomment-328181514)). ## Backwards Compatibility The proposed standard is designed to maintain compatibility with `ERC-20` tokens with the following provisos: 1. The `decimals` function MUST return `0` as the tokens MUST NOT be divisible, 2. The `transfer` and `transferFrom` functions MUST NOT allow transfers to non-verified addresses, and MUST maintain a list of shareholders. 3. Shareholders who transfer away their remaining tokens must be pruned from the list of shareholders. Proviso 1 will not break compatibility with modern wallets or exchanges as they all appear to use that information if available. Proviso 2 will cause transfers to fail if an attempt is made to transfer tokens to a non-verified address. This is implicit in the design and implementers are encouraged to make this abundantly clear to market participants. We appreciate that this will make the standard unpalatable to some exchanges, but it is an SEC requirement that shareholders of a corporation provide verified names and addresses. Proviso 3 is an implementation detail. ## Test Cases and Reference Implementation Test cases and a reference implementation are available at [github.com/davesag/ERC884-reference-implementation](https://github.com/davesag/ERC884-reference-implementation). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 14 Feb 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-884 https://eips.ethereum.org/EIPS/eip-884 DelegateProxy Standards Track/ERC https://github.com/ethereum/EIPs/pull/897 ## Simple Summary Proxy contracts are being increasingly used as both as an upgradeability mechanism and a way to save gas when deploying many instances of a particular contract. This standard proposes a set of interfaces for proxies to signal how they work and what their main implementation is. ## Abstract Using proxies that delegate their own logic to another contract is becoming an increasingly popular technique for both smart contract upgradeability and creating cheap clone contracts. We don't believe there is value in standardizing any particular implementation of a DelegateProxy, given its simplicity, but we believe there is a lot of value in agreeing on an interface all proxies use that allows for a standard way to operate with proxies. ## Implementations - **aragonOS**: [AppProxyUpgradeable](https://github.com/aragon/aragonOS/blob/master/contracts/apps/AppProxyUpgradeable.sol), [AppProxyPinned](https://github.com/aragon/aragonOS/blob/master/contracts/apps/AppProxyPinned.sol) and [KernelProxy](https://github.com/aragon/aragonOS/blob/master/contracts/kernel/KernelProxy.sol) - **zeppelinOS**: [Proxy](https://github.com/zeppelinos/labs/blob/2da9e859db81a61f2449d188e7193788ca721c65/upgradeability_ownership/contracts/Proxy.sol) ## Standardized interface ```solidity interface ERCProxy { function proxyType() public pure returns (uint256 proxyTypeId); function implementation() public view returns (address codeAddr); } ``` ### Code address (`implementation()`) The returned code address is the address the proxy would delegate calls to at that moment in time, for that message. ### Proxy Type (`proxyType()`) Checking the proxy type is the way to check whether a contract is a proxy at all. When a contract fails to return to this method or it returns 0, it can be assumed that the contract is not a proxy. It also allows for communicating a bit more of information about how the proxy operates. It is a pure function, therefore making it effectively constant as it cannot return a different value depending on state changes. - **Forwarding proxy** (`id = 1`): The proxy will always forward to the same code address. The following invariant should always be true: once the proxy returns a non-zero code address, that code address should never change. - **Upgradeable proxy** (`id = 2`): The proxy code address can be changed depending on some arbitrary logic implemented either at the proxy level or in its forwarded logic. ## Benefits - **Source code verification**: right now when checking the code of a proxy in explorers like Etherscan, it just shows the code in the proxy itself but not the actual code of the contract. By standardizing this construct, they will be able to show both the actual ABI and code for the contract. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 21 Feb 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-897 https://eips.ethereum.org/EIPS/eip-897 Simple Staking Interface Standards Track/ERC https://github.com/ethereum/EIPs/issues/900 ## Abstract The following standard describes a common staking interface allowing for easy to use staking systems. The interface is kept simple allowing for various use cases to be implemented. This standard describes the common functionality for staking as well as providing information on stakes. ## Motivation As we move to more token models, having a common staking interface which is familiar to users can be useful. The common interface can be used by a variety of applications, this common interface could be beneficial especially to things like Token curated registries which have recently gained popularity. ## Specification ```solidity interface Staking { event Staked(address indexed user, uint256 amount, uint256 total, bytes data); event Unstaked(address indexed user, uint256 amount, uint256 total, bytes data); function stake(uint256 amount, bytes data) public; function stakeFor(address user, uint256 amount, bytes data) public; function unstake(uint256 amount, bytes data) public; function totalStakedFor(address addr) public view returns (uint256); function totalStaked() public view returns (uint256); function token() public view returns (address); function supportsHistory() public pure returns (bool); // optional function lastStakedFor(address addr) public view returns (uint256); function totalStakedForAt(address addr, uint256 blockNumber) public view returns (uint256); function totalStakedAt(uint256 blockNumber) public view returns (uint256); } ``` ### stake Stakes a certain amount of tokens, this MUST transfer the given amount from the user. *The data field can be used to add signalling information in more complex staking applications* MUST trigger ```Staked``` event. ### stakeFor Stakes a certain amount of tokens, this MUST transfer the given amount from the caller. *The data field can be used to add signalling information in more complex staking applications* MUST trigger ```Staked``` event. ### unstake Unstakes a certain amount of tokens, this SHOULD return the given amount of tokens to the user, if unstaking is currently not possible the function MUST revert. *The data field can be used to remove signalling information in more complex staking applications* MUST trigger ```Unstaked``` event. ### totalStakedFor Returns the current total of tokens staked for an address. ### totalStaked Returns the current total of tokens staked. ### token Address of the token being used by the staking interface. ### supportsHistory MUST return true if the optional history functions are implemented, otherwise false. ### lastStakedFor ***OPTIONAL:** As not all staking systems require a complete history, this function is optional.* Returns last block address staked at. ### totalStakedForAt ***OPTIONAL:** As not all staking systems require a complete history, this function is optional.* Returns total amount of tokens staked at block for address. ### totalStakedAt ***OPTIONAL:** As not all staking systems require a complete history, this function is optional.* Returns the total tokens staked at block. ## Implementation - [Stakebank](https://github.com/HarbourProject/stakebank) - [Aragon](https://github.com/aragon/aragon-apps/pull/101) - [PoS Staking](https://github.com/maticnetwork/contracts/blob/master/contracts/StakeManager.sol) - [BasicStakeContract](https://github.com/codex-protocol/contract.erc-900) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 22 Feb 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-900 https://eips.ethereum.org/EIPS/eip-900 Token Validation Standards Track/ERC https://ethereum-magicians.org/t/update-on-erc902-validated-token/1639 # Simple Summary A protocol for services providing token ownership and transfer validation. # Abstract This standard provides a registry contract method for authorizing token transfers. By nature, this covers both initially issuing tokens to users (ie: transfer from contract to owner), transferring tokens between users, and token spends. # Motivation The tokenization of assets has wide application, not least of which is financial instruments such as securities and security tokens. Most jurisdictions have placed legal constraints on what may be traded, and who can hold such tokens which are regarded as securities. Broadly this includes KYC and AML validation, but may also include time-based spend limits, total volume of transactions, and so on. Regulators and sanctioned third-party compliance agencies need some way to link off-chain compliance information such as identity and residency to an on-chain service. The application of this design is broader than legal regulation, encompassing all manner of business logic permissions for the creation, management, and trading of tokens. Rather than each token maintaining its own whitelist (or other mechanism), it is preferable to share on-chain resources, rules, lists, and so on. There is also a desire to aggregate data and rules spread across multiple validators, or to apply complex behaviours (ex. switching logic, gates, state machines) to apply distributed data to an application. # Specification ## `TokenValidator` ```solidity interface TokenValidator { function check( address _token, address _subject ) public returns(byte statusCode) function check( address _token, address _from, address _to, uint256 _amount ) public returns (byte statusCode) } ``` ### Methods #### `check`/2 `function check(address _token, address _subject) public returns (byte _resultCode)` > parameters > * `_token`: the token under review > * `_subject`: the user or contract to check > > *returns* an ERC1066 status code #### `check`/4 `function check(address token, address from, address to, uint256 amount) public returns (byte resultCode)` > parameters > * `_token`: the token under review > * `_from`: in the case of a transfer, who is relinquishing token ownership > * `_to`: in the case of a transfer, who is accepting token ownership > * `_amount`: The number of tokens being transferred > > *returns* an ERC1066 status code ## `ValidatedToken` ```solidity interface ValidatedToken { event Validation( address indexed subject, byte indexed result ) event Validation( address indexed from, address indexed to, uint256 value, byte indexed statusCode ) } ``` ### Events #### `Validation`/2 `event Validation(address indexed subject, byte indexed resultCode)` This event MUST be fired on return from a call to a `TokenValidator.check/2`. > parameters > * `subject`: the user or contract that was checked > * `statusCode`: an ERC1066 status code #### `Validation`/4 ```solidity event Validation( address indexed from, address indexed to, uint256 amount, byte indexed statusCode ) ``` This event MUST be fired on return from a call to a `TokenValidator.check/4`. > parameters > * `from`: in the case of a transfer, who is relinquishing token ownership > * `to`: in the case of a transfer, who is accepting token ownership > * `amount`: The number of tokens being transferred > * `statusCode`: an ERC1066 status code # Rationale This proposal includes a financial permissions system on top of any financial token. This design is not a general roles/permission system. In any system, the more you know about the context where a function will be called, the more powerful your function can be. By restricting ourselves to token transfers (ex. ERC20 or EIP-777), we can make assumptions about the use cases our validators will need to handle, and can make the API both small, useful, and extensible. The events are fired by the calling token. Since `Validator`s may aggregate or delegate to other `Validator`s, it would generate a lot of useless events were it the `Validator`'s responsibility. This is also the reason why we include the `token` in the `call/4` arguments: a `Validator` cannot rely on `msg.sender` to determine the token that the call is concerning. We have also seen a similar design from [R-Token](https://github.com/harborhq/r-token) that uses an additional field: `spender`. While there are potential use cases for this, it's not widely used enough to justify passing a dummy value along with every call. Instead, such a call would look more like this: ```solidity function approve(address spender, uint amount) public returns (bool success) { if (validator.check(this, msg.sender, spender, amount) == okStatusCode) { allowed[msg.sender][spender] = amount; Approval(msg.sender, spender, amount); return true; } else { return false; } } ``` A second `check/2` function is also required, that is more general-purpose, and does not specify a transfer amount or recipient. This is intended for general checks, such as checking roles (admin, owner, &c), or if a user is on a simple whitelist. We have left the decision to make associated `Validator` addresses public, private, or hardcoded up to the implementer. The proposed design does not include a centralized registry. It also does not include an interface for a `Validated` contract. A token may require one or many `Validator`s for different purposes, requiring different validations for different, or just a single `Validator`. The potential use cases are too varied to provide a single unified set of methods. We have provided a set of example contracts [here](https://github.com/Finhaven/ValidatedToken/) that may be inherited from for common use cases. The status codes in the `byte` returns are unspecified. Any status code scheme may be used, though a general status code proposal is fortcoming. By only defining the validation check, this standard is widely compatible with ERC-20, EIP-721, EIP-777, future token standards, centralized and decentralized exchanges, and so on. # Implementation [Reference implementation](https://github.com/expede/validated-token/) # Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 14 Feb 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-902 https://eips.ethereum.org/EIPS/eip-902 Reward clients for a sustainable network Standards Track/Core https://ethereum-magicians.org/t/eip-908-reward-full-nodes-and-clients/241 ## A reward for running a full node is deprecated, but the proposal for a reward for clients remains While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). This paper is more a high-level analysis and discussion rather than attempting to provide a concrete solution. [Pocket Network](https://www.pokt.network/) is a separate blockchain being designed as of Sept 2018 that incentivises relaying transactions, that is intended to be compatible with other blockchains. Note also that [Rocket Pool](https://github.com/rocket-pool/rocketpool) is under development and is planned to be a pool for Casper, which will help to incentivise running a full node. Another alternative is [VIPnode](https://github.com/vipnode/vipnode.org) which charges fees to light clients for full nodes that serve them. In light of these solutions being developed, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Outdated (Casper FFG will be implemented with Ethereum 2.0 with sharding: [shasper](https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#)): given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile. For a previous version of the proposal containing a proposal for rewarding a full node, refer to [here](https://github.com/ethereum/EIPs/commit/97e235d0ba4a88b4ce29834aa2b94107b8d91e12#diff-9a43a8739b5a9e1dec427324cb264921). ## Simple Summary When each transaction is validated, give a reward to clients for developing the client. ## Abstract The tragedy of the commons is a phenomenon that is well known in many sectors, most notably in regard to sustainability. It involves the over-utilization of shared finite resources, which detriments all participants and stakeholders involved (which in the case of a global public good can be everyone, including future generations). Without proper management of public resources, a tragedy of the commons can occur. Internalizing externalities (where externalities can be broadly defined as effects that are not accounted for in the intrinsic price of a good, service or resource) is one way of incentivizing the proper management of resources, although other methods that actually properly manage them are necessary. This EIP proposes to make a change to the protocol to provide a reward to clients for providing the software that enables Ethereum to function, where the reward can include a proportion of transaction fees (reducing the full proportion that the miner currently receives), and some newly minted ETH. Thus, clients are incentivized to maintain and improve the security and health of the Ethereum protocol and ecosystem. To summarize the mechanism in the proposal, a user agent is attached to a transaction, where this user agent contains a vector with the index of a client address in an access list. The client address could be inserted by the client and verified that it is the same as a read-only constant in the client's storage. Reward mechanisms that are external to being built in to the protocol are beyond the scope of this EIP. Such extra-protocol reward methods include state channel payments for extra services such as light client servers providing faster information such as receipts; state channel payments for buying state reads from full nodes; archival services (which is only applicable to future proposed versions of Ethereum with stateless clients); and tokens for the client and running full nodes. ## Motivation Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake with [Casper FFG](/EIPS/eip-1011), then full PoS with [CBC Casper](https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.pdf). Additionally, providing a reward for clients gives a revenue stream that is independent of state channels or other layer 2 mechanisms, which are less secure, although this insecurity can be offset by mechanisms such as insurance, bonded payments and time locks. Rationalising that investors may invest in a client because it is an enabler for the Ethereum ecosystem (and thus opening up investment opportunities) may not scale very well, and it seems that it is more sustainable to monetize the client as part of the service(s) that it provides. While it may be argued that the funds raised by the Ethereum pre-mine (the pre-ICO and the ICO) can be used to fund client development, that argument is questionable, since Parity is VC-funded, and other clients such as Prysmatic Labs [1](https://medium.com/@XYOracleNetwork?source=search_post), [2](https://twitter.com/prylabs/status/996391036753666050), [3](https://medium.com/prysmatic-labs/biweekly-development-update-2-d29d0c91e7d0) and [exthereum](https://medium.com/compound-finance/introducing-exthereum-the-newest-ethereum-client-7a5e30d4d6aa) have received funding from other parties, whereas perhaps they would not have needed to do so if there was sufficient funding from the Ethereum pre-mine funds. [Drops of Diamond](https://github.com/Drops-of-Diamond/diamond_drops) is yet to receive any funding. Incentivizing client development would more directly incentivize resource provision in the protocol, preventing a tragedy of the commons, where there is an extreme lack of supply and excess demand, leading to the protocol being unusable. See [here](https://eprint.iacr.org/2014/452.pdf#subsection.2.1) for an analysis in the context of Bitcoin, PoW, and a hybrid PoW/PoS protocol. While Ethereum has a gas limit, the section points out that this is not enough as the market cap increases and the incentive to attack the network increases, while the ratio of security costs to transaction fees does not, while PoS will further alleviate the problem. However, the section points out that PoS is not enough, since the costs of propagating, verifying and storing transactions are not incentivised. Note that the "Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake" paper also contains a scheme for incentivizing a target participation level. > The word “activity” in the phrase Proof of Activity emphasizes the point that only active stakeholders who maintain a full online node get rewarded, in exchange for the vital services that they provide for the network. This stands in contrast to earlier Proof of Stake schemes in which offline stake can accumulate weight over time, and may ultimately be utilized in double-spending attacks. We can also incentivize full nodes to propagate transactions and to store transactions or state, in addition to verifying them. While these first two incentivizations are outside the scope of this EIP, there are proposals [here](https://ethresear.ch/t/incentivizing-a-robust-p2p-network-relay-layer/1438) and [here](https://ethresear.ch/t/incentivizing-full-state-nodes/1640), respectively. Implementing this as a layer 2 solution may not ensure the sustainability of the protocol, since not everyone would use it; if the protocol doesn't have any cost for full nodes to validate transactions, then people will take advantage of that and not use the layer 2 solution. It seems that you should at least have the part where the reward is provided in protocol, but then that and the user agent signature doesn't really add anything else to the protocol, so doing some part in-protocol and some part e.g. the verification or a verification-game off-protocol could be done, but it's already done in protocol. Note also that some computationally expensive tasks are too challenging to feasibly do in protocol, e.g. due to not fitting in the gas limit, could be done with Truebit, where verifiers have an incentive. Not providing incentives for clients is an issue now as there is less incentive to build a client that aligns with the needs of users, funds need to be raised externally to the protocol to fund client development, which is not as decentralized. If only a smaller subset is able to fund client development, such as VCs, angel investors and institutional investors, that may not align well with the interests of all current and potential stakeholders of Ethereum (which includes future stakeholders). Ostensibly, one of the goals of Ethereum is to decentralize everything, including wealth, or in other words, to improve wealth equality. Not providing incentives for full nodes validating transactions may not seem like as much of an issue now, but not doing so could hinder the growth of the protocol. Of course, incentives aren't enough, it also needs to be technically decentralized so that it is ideally possible for a low-end mainstream computer or perhaps even a mobile or embedded IoT device to be a verifying full node, or at least to be able to help with securing the network if it is deemed impractical for them to be a full node. Note that with a supply cap (as in [EIP-960](https://github.com/ethereum/EIPs/issues/960), the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per [EIP-1015](/EIPS/eip-1015), an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders. ## Specification Add a new field to each block called `PrevBlockVerifications`, which is an arbitrary, unlimited size byte array. When a client verifies that a previous block is [valid](https://ethereum.github.io/yellowpaper/paper.pdf#subsubsection.4.3.2), the client appends a user agent to PrevBlockVerifications via an opcode in a transaction, PREV_BLOCK_VERIF. The user agent is a vector with the immutable fields: the blockhash of the block that is validated, and the index of a client address in an access list (details are below). A miner validates a transaction before including it in a block, however they are not able to change these fields of the vector because they're immutable. Send 0.15 ETH to the client (see the rationale below), when the block is processed. The amounts could include a proportion of transaction fees (while the miner would then receive less), which would reduce newly issued ETH. These amounts are specified in new `ClientReward` fields in the block. In order to only incentivize verifying recent blocks, assert that the block number corresponding to a blockhash is less than 400 blocks ago. ### Attacks and added specifications to prevent them A miner could create a client and fill their block with transactions that only contain the PREV_BLOCK_VERIF opcode (or alternatively, arbitrarily complex transactions, still with the opcode), with previous blockhashes that they have validated and the address of their client. To prevent this, state would have to store a list containing lists, with each sublist listing the blockhashes up to 400 blocks ago that correspond to a miner, then a miner (or a proposer under Casper CBC) could have to put down a deposit, and be slashed if the proposer inserts such a transaction (that contains a blockhash which they have already proposed, not just in a block but at any time previously). Updating the state to remove blockhashes more than 400 blocks ago would add additional overhead, although you could add an extra window for older blocks, say 120,000 blocks (roughly every 3 weeks), still ignore blocks that are older than 400 blocks ago, and remove these older 120,000 blocks every 120,000 blocks. An attacker could bribe a miner/proposer to include transactions like above that contain an address of a client in the access list which they own. However, the above slashing condition should disincentivize this. ### More details on the access list The access list prevents anyone inserting any address to the first element of the vector, where there may be a way to prevent censorship and centralization of authority of who decides to register new addresses in the list, e.g. on-chain governance with signalling (possibly similar to [EIP-1015](/EIPS/eip-1015), which also specifies an alternative way of sending funds) or a layer 2 proof of authority network where new addresses can be added via a smart contract. Note that there may be serious drawbacks to implementing either of these listed examples. There is a refutation of [on-chain governance](https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca) as well as of [plutocracy](https://vitalik.ca/general/2018/03/28/plutocracy.html). [Proof of Authority](https://en.wikipedia.org/wiki/Proof-of-authority) isn't suitable for a public network since it doesn't distribute trust well. However, using signalling in layer 2 contracts is more acceptable, but Vlad Zamfir argues that using that to influence outcomes in the protocol can disenfranchise miners from being necessary participants in the governance process. Thus, in light of these counterpoints, having an access list may not be suitable until a decentralized, trustless way of maintaining it is implemented and ideally accepted by the majority of a random sample that represents the population of Ethereum users. However, another alternative to managing the access list would be to have decentralized verification that the address produced from querying an index in the access list does correspond to that of a "legitimate" client. Part of this verification would involve checking that there is a client that claims that this address is owned by them, that they are happy to receive funds in this manner and agree or arranged to putting the address in the access list, and that the client passes all tests in the [Ethereum test suite](https://github.com/ethereum/tests). However, this last proviso would then preclude new clients being funded from the start of development, although such would-be clients would not be able to receive funds in-protocol until they implement the client anyway (as an aside, they could raise funds in various ways—a DAII, pronounced die-yee, is recommended, while a platform for DAIIs is under development by [Dogezer](https://dogezer.com/)). All of this could be done off-chain, and if anyone found that some address in the access list was not legitimate, then they could challenge that address with a proof of illegitimacy, and the participant that submitted the address to the access list could be slashed (while they must hold a deposit in order to register and keep an address in the access list). Additionally, it should help with being only able to read the client's address from the client, and the whole transaction could revert if the address is not in the access list. You could provide the index of the address in the access list, and then you could `assert` that the address found at that index matches that which can be read by the client (where the latter would be a read-only address). ## Rationale ### A rough qualitative analysis of fees As of May 4 2018, there are [16428 nodes](https://web.archive.org/web/20180504051128/https://ethernodes.org/network/1). Assume that an annual cost for an average client developer organisation is $1 million per annum. Projecting forward (and noting that the number of nodes should increase substantially if this EIP was implemented, thus aiding Ethereum's goal of decentralizing everything) assume that there are 10 clients. Thus let us assume that the number of nodes doubles to 30000 nodes within 5 years (this assumption is probably conservative, even if it is forward looking). Assume for simplicity that the costs of a client are entirely covered by this block reward. Average cost per client = number of nodes * Block reward per client / number of clients Block reward per client (worse case for ETH price) = Average revenue per client * number of clients / (ETH exchange rate * number of nodes) = $2,000,000 * 10 / (500 * 30,000) = 1.333333333 ETH Block reward per client (better case) = $1,000,000 * 10 / (2000 * 30,000) = 0.166666667 ETH Suppose that we use a block reward of 0.15 ETH for clients. <!--There are more than 5552465 blocks and counting. With a reward of 0.001 ETH for each block, a full state node that verified every block would receive 5552.465 ETH. However, the difficulty of verifying blocks increases over time, so--> ### More rationale (outdated by above) The amount of computation to validate a transaction will be the same as a miner, since the transaction will need to be executed. Thus, if there would be transaction fees for validating full nodes and clients, and transactions need to be executed by validators just like miners have to, it makes sense to have them calculated in the same way as gas fees for miners. This would controversially increase the amount of transaction fees a lot, since there can be many validators for a transaction. In other words, it is controversial whether to provide the same amount of transaction fee for a full node validator as for a miner (which in one respect is fair, since the validator has to do the same amount of computation), or prevent transaction fees from rising much higher, and have a transaction fee for a full node as, say, the transaction fee for a miner, divided by the average number of full nodes validating a transaction. The latter option seems even more controversial (but is still better than the status quo), since while there would be more of an incentive to run a full node than there is now with no incentive, validators would be paid less for performing the same amount of computation. And as for the absolute amounts, this will require data analysis, but clearly a full node should receive much less than a miner for processing a transaction in a block, since there are many transactions in a block, and there are many confirmations of a block. Data analysis could involve calculating the average number of full nodes verifying transactions in a block. Macroeconomic analysis could entail the economic security benefit that full nodes provide to the network. Now, as to the ratio of rewards to the client vs the full node, as an initial guess I would suggest something like 99:1. Why such a big difference? Well, I would guess that clients spend roughly 99 times more time on developing and maintaining the client than a full node user spends running and maintaining a full node. During a week there might be several full-time people working on the client, but a full node might only spend half an hour (or less) initially setting it up, plus running it, plus electricity and internet costs. Full node operators probably don't need to upgrade their computer (and buying a mining rig isn't worth it with Casper PoS planning on being implemented soon). However, on further analysis, clients would also get the benefit of a large volume of rewards from every full node running the client, so to incentivise full node operation further, the ratio could change to say, 4:1, or even 1:1, and of course could be adjusted with even further actual data analysis, rather than speculation. Providing rewards to full node validators and to clients would increase the issuance. In order to maintain the issuance at current levels, this EIP could also reduce the mining reward (despite being reduced previously with the Byzantium release in October 2017 from 5 ETH to 3 ETH), but that would generate more controversy and discussion. Another potential point of controversy with rewarding clients and full nodes is that the work previously done by them has not been paid for until now (except of course by the Ethereum Foundation or Parity VCs funding the work), so existing clients may say that this EIP gives an advantage to new entrants. However, this doesn't hold up well, because existing clients have the first mover advantage, with much development to create useful and well-used products. There is a tradeoff. Higher fees means you may cut out poor people and people who just don't want to pay fees. But if a laptop can run a full node and get paid for it then that would offset the fees through usage. Full nodes do provide a security benefit, so the total fees given could at least be some fraction of this benefit. Fees that go towards client development incentivise a higher quality client. To me, I think it makes more sense to internalize costs as much as possible: for computation, storage, bandwidth, I/O, client development, running full nodes, mining/validating, etc. You avoid a tragedy of the commons through externalizing costs. The more you internalize costs, the more sustainable it is, and the less you rely on rich people being generous, etc. (Although, getting philosophical, ultimately you can't force rich people to be generous, they have to do so out of the kindness of their hearts.) Regarding rewards for full nodes, in the [draft phase 1 sharding spec](https://ethresear.ch/t/sharding-phase-1-spec/1407) proposers acting as full nodes have rewards for proposing blobs (without execution) or later in phase 3 transactions (with execution) to be included into collations/blocks. So that would help. However, full nodes that do not act as proposers and just verify transactions, or [full state nodes](https://ethresear.ch/t/incentivizing-full-state-nodes/1640), are still not incentivized. Note that while further quantitative analysis to specify fees should be done, some level of experimentation after implementing this method on-chain may be necessary. ### Security All of the below struck out information should be prevented via using an access list and verifying that the read-only address provided by the client matches with an address in the access list, as well as using a layer 2 solution such as a PoA network for censorship resistance and minimization of centralization in the access list. Further discussion is at https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239. ## Backwards Compatibility Introducing in-protocol fees is a backwards-incompatible change, so would be introduced in a hard-fork. ## Test Cases TODO ## Implementation TODO ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 01 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-908 https://eips.ethereum.org/EIPS/eip-908 Mineable Token Standard Standards Track/ERC ### Simple Summary A specification for a standardized Mineable Token that uses a Proof of Work algorithm for distribution. ### Abstract This specification describes a method for initially locking tokens within a token contract and slowly dispensing them with a mint() function which acts like a faucet. This mint() function uses a Proof of Work algorithm in order to minimize gas fees and control the distribution rate. Additionally, standardization of mineable tokens will give rise to standardized CPU and GPU token mining software, token mining pools and other external tools in the token mining ecosystem. ### Motivation Token distribution via the ICO model and its derivatives is susceptible to illicit behavior by human actors. Furthermore, new token projects are centralized because a single entity must handle and control all of the initial coins and all of the raised ICO money. By distributing tokens via an 'Initial Mining Offering' (or IMO), the ownership of the token contract no longer belongs with the deployer at all and the deployer is 'just another user.' As a result, investor risk exposure utilizing a mined token distribution model is significantly diminished. This standard is intended to be standalone, allowing maximum interoperability with ERC20, ERC721, and others. ### Specification #### Interface The general behavioral specification includes a primary function that defines the token minting operation, an optional merged minting operation for issuing multiple tokens, getters for challenge number, mining difficulty, mining target and current reward, and finally a Mint event, to be emitted upon successful solution validation and token issuance. At a minimum, contracts must adhere to this interface (save the optional merge operation). It is recommended that contracts interface with the more behaviorally defined Abstract Contract described below, in order to leverage a more defined construct, allowing for easier external implementations via overridden phased functions. (see 'Abstract Contract' below) ``` solidity interface ERC918 { function mint(uint256 nonce) public returns (bool success); function getAdjustmentInterval() public view returns (uint); function getChallengeNumber() public view returns (bytes32); function getMiningDifficulty() public view returns (uint); function getMiningTarget() public view returns (uint); function getMiningReward() public view returns (uint); function decimals() public view returns (uint8); event Mint(address indexed from, uint rewardAmount, uint epochCount, bytes32 newChallengeNumber); } ``` #### Abstract Contract (Optional) The Abstract Contract adheres to the EIP918 Interface and extends behavioral definition through the introduction of 4 internal phases of token mining and minting: hash, reward, epoch and adjust difficulty, all called during the mint() operation. This construct provides a balance between being too general for use while providing ample room for multiple mined implementation types. ### Fields #### adjustmentInterval The amount of time between difficulty adjustments in seconds. ``` solidity bytes32 public adjustmentInterval; ``` #### challengeNumber The current challenge number. It is expected that a new challenge number is generated after a new reward is minted. ``` solidity bytes32 public challengeNumber; ``` #### difficulty The current mining difficulty which should be adjusted via the \_adjustDifficulty minting phase ``` solidity uint public difficulty; ``` #### tokensMinted Cumulative counter of the total minted tokens, usually modified during the \_reward phase ``` solidity uint public tokensMinted; ``` #### epochCount Number of 'blocks' mined ``` solidity uint public epochCount; ``` ### Mining Operations #### mint Returns a flag indicating a successful hash digest verification, and reward allocation to msg.sender. In order to prevent MiTM attacks, it is recommended that the digest include a recent Ethereum block hash and msg.sender's address. Once verified, the mint function calculates and delivers a mining reward to the sender and performs internal accounting operations on the contract's supply. The mint operation exists as a public function that invokes 4 separate phases, represented as functions hash, \_reward, \_newEpoch, and \_adjustDifficulty. In order to create the most flexible implementation while adhering to a necessary contract protocol, it is recommended that token implementors override the internal methods, allowing the base contract to handle their execution via mint. This externally facing function is called by miners to validate challenge digests, calculate reward, populate statistics, mutate epoch variables and adjust the solution difficulty as required. Once complete, a Mint event is emitted before returning a boolean success flag. ``` solidity contract AbstractERC918 is EIP918Interface { // the amount of time between difficulty adjustments uint public adjustmentInterval; // generate a new challenge number after a new reward is minted bytes32 public challengeNumber; // the current mining target uint public miningTarget; // cumulative counter of the total minted tokens uint public tokensMinted; // number of blocks per difficulty readjustment uint public blocksPerReadjustment; //number of 'blocks' mined uint public epochCount; /* * Externally facing mint function that is called by miners to validate challenge digests, calculate reward, * populate statistics, mutate epoch variables and adjust the solution difficulty as required. Once complete, * a Mint event is emitted before returning a success indicator. **/ function mint(uint256 nonce) public returns (bool success) { require(msg.sender != address(0)); // perform the hash function validation hash(nonce); // calculate the current reward uint rewardAmount = _reward(); // increment the minted tokens amount tokensMinted += rewardAmount; epochCount = _epoch(); //every so often, readjust difficulty. Don't readjust when deploying if(epochCount % blocksPerReadjustment == 0){ _adjustDifficulty(); } // send Mint event indicating a successful implementation emit Mint(msg.sender, rewardAmount, epochCount, challengeNumber); return true; } } ``` ##### *Mint Event* Upon successful verification and reward the mint method dispatches a Mint Event indicating the reward address, the reward amount, the epoch count and newest challenge number. ``` solidity event Mint(address indexed from, uint reward_amount, uint epochCount, bytes32 newChallengeNumber); ``` #### hash Public interface function hash, meant to be overridden in implementation to define hashing algorithm and validation. Returns the validated digest ``` solidity function hash(uint256 nonce) public returns (bytes32 digest); ``` #### \_reward Internal interface function \_reward, meant to be overridden in implementation to calculate and allocate the reward amount. The reward amount must be returned by this method. ``` solidity function _reward() internal returns (uint); ``` #### \_newEpoch Internal interface function \_newEpoch, meant to be overridden in implementation to define a cutpoint for mutating mining variables in preparation for the next phase of mine. ``` solidity function _newEpoch(uint256 nonce) internal returns (uint); ``` #### \_adjustDifficulty Internal interface function \_adjustDifficulty, meant to be overridden in implementation to adjust the difficulty (via field difficulty) of the mining as required ``` solidity function _adjustDifficulty() internal returns (uint); ``` #### getAdjustmentInterval The amount of time, in seconds, between difficulty adjustment operations. ``` solidity function getAdjustmentInterval() public view returns (uint); ``` #### getChallengeNumber Recent ethereum block hash, used to prevent pre-mining future blocks. ``` solidity function getChallengeNumber() public view returns (bytes32); ``` #### getMiningDifficulty The number of digits that the digest of the PoW solution requires which typically auto adjusts during reward generation. ``` solidity function getMiningDifficulty() public view returns (uint) ``` #### getMiningReward Return the current reward amount. Depending on the algorithm, typically rewards are divided every reward era as tokens are mined to provide scarcity. ``` solidity function getMiningReward() public view returns (uint) ``` ### Example mining function A general mining function written in python for finding a valid nonce for keccak256 mined token, is as follows: ``` python def generate_nonce(): myhex = b'%064x' % getrandbits(32*8) return codecs.decode(myhex, 'hex_codec') def mine(challenge, public_address, difficulty): while True: nonce = generate_nonce() hash1 = int(sha3.keccak_256(challenge+public_address+nonce).hexdigest(), 16) if hash1 < difficulty: return nonce, hash1 ``` Once the nonce and hash1 are found, these are used to call the mint() function of the smart contract to receive a reward of tokens. ### Merged Mining Extension (Optional) In order to provide support for merge mining multiple tokens, an optional merged mining extension can be implemented as part of the ERC918 standard. It is important to note that the following function will only properly work if the base contracts use tx.origin instead of msg.sender when applying rewards. If not the rewarded tokens will be sent to the calling contract and not the end user. ``` solidity /** * @title ERC-918 Mineable Token Standard, optional merged mining functionality * @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-918.md * */ contract ERC918Merged is AbstractERC918 { /* * @notice Externally facing merge function that is called by miners to validate challenge digests, calculate reward, * populate statistics, mutate state variables and adjust the solution difficulty as required. Additionally, the * merge function takes an array of target token addresses to be used in merged rewards. Once complete, * a Mint event is emitted before returning a success indicator. * * @param _nonce the solution nonce **/ function merge(uint256 _nonce, address[] _mineTokens) public returns (bool) { for (uint i = 0; i < _mineTokens.length; i++) { address tokenAddress = _mineTokens[i]; ERC918Interface(tokenAddress).mint(_nonce); } } /* * @notice Externally facing merge function kept for backwards compatibility with previous definition * * @param _nonce the solution nonce * @param _challenge_digest the keccak256 encoded challenge number + message sender + solution nonce **/ function merge(uint256 _nonce, bytes32 _challenge_digest, address[] _mineTokens) public returns (bool) { //the challenge digest must match the expected bytes32 digest = keccak256( abi.encodePacked(challengeNumber, msg.sender, _nonce) ); require(digest == _challenge_digest, "Challenge digest does not match expected digest on token contract [ ERC918Merged.mint() ]"); return merge(_nonce, _mineTokens); } } ``` ### Delegated Minting Extension (Optional) In order to facilitate a third party minting submission paradigm, such as the case of miners submitting solutions to a pool operator and/or system, a delegated minting extension can be used to allow pool accounts submit solutions on the behalf of a user, so the miner can avoid directly paying Ethereum transaction costs. This is performed by an off chain mining account packaging and signing a standardized mint solution packet and sending it to a pool or 3rd party to be submitted. The ERC918 Mineable Mint Packet Metadata should be prepared using following schema: ``` solidity { "title": "Mineable Mint Packet Metadata", "type": "object", "properties": { "nonce": { "type": "string", "description": "Identifies the target solution nonce", }, "origin": { "type": "string", "description": "Identifies the original user that mined the solution nonce", }, "signature": { "type": "string", "description": "The signed hash of tightly packed variables sha3('delegatedMintHashing(uint256,address)')+nonce+origin_account", } } } ``` The preparation of a mineable mint packet on a JavaScript client would appear as follows: ``` solidity function prepareDelegatedMintTxn(nonce, account) { var functionSig = web3.utils.sha3("delegatedMintHashing(uint256,address)").substring(0,10) var data = web3.utils.soliditySha3( functionSig, nonce, account.address ) var sig = web3.eth.accounts.sign(web3.utils.toHex(data), account.privateKey ) // prepare the mint packet var packet = {} packet.nonce = nonce packet.origin = account.address packet.signature = sig.signature // deliver resulting JSON packet to pool or third party var mineableMintPacket = JSON.stringify(packet, null, 4) /* todo: send mineableMintPacket to submitter */ ... } ``` Once the packet is prepared and formatted it can then be routed to a third party that will submit the transaction to the contract's delegatedMint() function, thereby paying for the transaction gas and receiving the resulting tokens. The pool/third party must then manually payback the minted tokens minus fees to the original minter. The following code sample exemplifies third party packet relaying: ``` solidity //received by minter var mineableMintPacket = ... var packet = JSON.parse(mineableMintPacket) erc918MineableToken.delegatedMint(packet.nonce, packet.origin, packet.signature) ``` The Delegated Mint Extension expands upon ERC918 realized as a sub-contract: ``` js import 'openzeppelin-solidity/contracts/contracts/cryptography/ECDSA.sol'; contract ERC918DelegatedMint is AbstractERC918, ECDSA { /** * @notice Hash (keccak256) of the payload used by delegatedMint * @param _nonce the golden nonce * @param _origin the original minter * @param _signature the original minter's elliptical curve signature */ function delegatedMint(uint256 _nonce, address _origin, bytes _signature) public returns (bool success) { bytes32 hashedTx = delegatedMintHashing(_nonce, _origin); address minter = recover(hashedTx, _signature); require(minter == _origin, "Origin minter address does not match recovered signature address [ AbstractERC918.delegatedMint() ]"); require(minter != address(0), "Invalid minter address recovered from signature [ ERC918DelegatedMint.delegatedMint() ]"); success = mintInternal(_nonce, minter); } /** * @notice Hash (keccak256) of the payload used by delegatedMint * @param _nonce the golden nonce * @param _origin the original minter */ function delegatedMintHashing(uint256 _nonce, address _origin) public pure returns (bytes32) { /* "0x7b36737a": delegatedMintHashing(uint256,address) */ return toEthSignedMessageHash(keccak256(abi.encodePacked( bytes4(0x7b36737a), _nonce, _origin))); } } ``` ### Mineable Token Metadata (Optional) In order to provide for richer and potentially mutable metadata for a particular Mineable Token, it is more viable to offer an off-chain reference to said data. This requires the implementation of a single interface method 'metadataURI()' that returns a JSON string encoded with the string fields symbol, name, description, website, image, and type. Solidity interface for Mineable Token Metadata: ``` solidity /** * @title ERC-918 Mineable Token Standard, optional metadata extension * @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-918.md * */ interface ERC918Metadata is AbstractERC918 { /** * @notice A distinct Uniform Resource Identifier (URI) for a mineable asset. */ function metadataURI() external view returns (string); } ``` Mineable Token Metadata JSON schema definition: ``` solidity { "title": "Mineable Token Metadata", "type": "object", "properties": { "symbol": { "type": "string", "description": "Identifies the Mineable Token's symbol", }, "name": { "type": "string", "description": "Identifies the Mineable Token's name", }, "description": { "type": "string", "description": "Identifies the Mineable Token's long description", }, "website": { "type": "string", "description": "Identifies the Mineable Token's homepage URI", }, "image": { "type": "string", "description": "Identifies the Mineable Token's image URI", }, "type": { "type": "string", "description": "Identifies the Mineable Token's hash algorithm ( ie.keccak256 ) used to encode the solution", } } } ``` ### Rationale The solidity keccak256 algorithm does not have to be used, but it is recommended since it is a cost effective one-way algorithm to perform in the EVM and simple to perform in solidity. The nonce is the solution that miners try to find and so it is part of the hashing algorithm. A challengeNumber is also part of the hash so that future blocks cannot be mined since it acts like a random piece of data that is not revealed until a mining round starts. The msg.sender address is part of the hash so that a nonce solution is valid only for a particular Ethereum account and so the solution is not susceptible to man-in-the-middle attacks. This also allows pools to operate without being easily cheated by the miners since pools can force miners to mine using the pool's address in the hash algorithm. The economics of transferring electricity and hardware into mined token assets offers a flourishing community of decentralized miners the option to be involved in the Ethereum token economy directly. By voting with hash power, an economically pegged asset to real-world resources, miners are incentivized to participate in early token trade to revamp initial costs, providing a bootstrapped stimulus mechanism between miners and early investors. One community concern for mined tokens has been around energy use without a function for securing a network. Although token mining does not secure a network, it serves the function of securing a community from corruption as it offers an alternative to centralized ICOs. Furthermore, an initial mining offering may last as little as a week, a day, or an hour at which point all of the tokens would have been minted. ### Backwards Compatibility Earlier versions of this standard incorporated a redundant 'challenge_digest' parameter on the mint() function that hash-encoded the packed variables challengeNumber, msg.sender and nonce. It was decided that this could be removed from the standard to help minimize processing and thereby gas usage during mint operations. However, in the name of interoperability with existing mining programs and pool software the following contract can be added to the inheritance tree: ``` solidity /** * @title ERC-918 Mineable Token Standard, optional backwards compatibility function * @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-918.md * */ contract ERC918BackwardsCompatible is AbstractERC918 { /* * @notice Externally facing mint function kept for backwards compatibility with previous mint() definition * @param _nonce the solution nonce * @param _challenge_digest the keccak256 encoded challenge number + message sender + solution nonce **/ function mint(uint256 _nonce, bytes32 _challenge_digest) public returns (bool success) { //the challenge digest must match the expected bytes32 digest = keccak256( abi.encodePacked(challengeNumber, msg.sender, _nonce) ); require(digest == _challenge_digest, "Challenge digest does not match expected digest on token contract [ AbstractERC918.mint() ]"); success = mint(_nonce); } } ``` ### Test Cases (Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.) ### Implementation Simple Example: https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/SimpleERC918.sol Complex Examples: https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/0xdogeExample.sol https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/0xdogeExample2.sol https://github.com/0xbitcoin/EIP918-Mineable-Token/blob/master/contracts/0xBitcoinBase.sol 0xBitcoin Token Contract: https://etherscan.io/address/0xb6ed7644c69416d67b522e20bc294a9a9b405b31 MVI OpenCL Token Miner https://github.com/mining-visualizer/MVis-tokenminer/releases PoWAdv Token Contract: https://etherscan.io/address/0x1a136ae98b49b92841562b6574d1f3f5b0044e4c ### Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 07 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-918 https://eips.ethereum.org/EIPS/eip-918 Address metadata registry Standards Track/ERC ## Abstract This EIP specifies a registry for address metadata, permitting both contracts and external accounts to supply metadata about themselves to onchain and offchain callers. This permits use-cases such as generalised authorisations, providing token acceptance settings, and claims registries. ## Motivation An increasing set of use cases require storage of metadata associated with an address; see for instance EIP 777 and EIP 780, and the ENS reverse registry in EIP 181. Presently each use-case defines its own specialised registry. To prevent a proliferation of special-purpose registry contracts, we instead propose a single standardised registry using an extendable architecture that allows future standards to implement their own metadata standards. ## Specification The metadata registry has the following interface: ```solidity interface AddressMetadataRegistry { function provider(address target) view returns(address); function setProvider(address _provider); } ``` `setProvider` specifies the metadata registry to be associated with the caller's address, while `provider` returns the address of the metadata registry for the supplied address. The metadata registry will be compiled with an agreed-upon version of Solidity and deployed using the trustless deployment mechanism to a fixed address that can be replicated across all chains. ## Provider specification Providers may implement any subset of the metadata record types specified here. Where a record types specification requires a provider to provide multiple functions, the provider MUST implement either all or none of them. Providers MUST throw if called with an unsupported function ID. Providers have one mandatory function: ```solidity function supportsInterface(bytes4 interfaceID) constant returns (bool) ``` The `supportsInterface` function is documented in [EIP-165](/EIPS/eip-165), and returns true if the provider implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a provider returns `true` for `supportsInterface()`, it must implement the functions specified in that interface. `supportsInterface` must always return true for `0x01ffc9a7`, which is the interface ID of `supportsInterface` itself. The first argument to all provider functions MUST be the address being queried; this facilitates the creation of multi-user provider contracts. Currently standardised provider interfaces are specified in the table below. | Interface name | Interface hash | Specification | | --- | --- | --- | EIPs may define new interfaces to be added to this registry. ## Rationale There are two obvious approaches for a generic metadata registry: the indirection approach employed here, or a generalised key/value store. While indirection incurs the cost of an additional contract call, and requires providers to change over time, it also provides for significantly enhanced flexibility over a key/value store; for that reason we selected this approach. ## Backwards Compatibility There are no backwards compatibility concerns. ## Implementation The canonical implementation of the metadata registry is as follows: ```solidity contract AddressMetadataRegistry { mapping(address=>address) public provider; function setProvider(address _provider) { provider[msg.sender] = _provider; } } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 12 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-926 https://eips.ethereum.org/EIPS/eip-926 Generalised authorisations Standards Track/ERC ## Abstract This EIP specifies a generic authorisation mechanism, which can be used to implement a variety of authorisation patterns, replacing approvals in ERC20, operators in ERC777, and bespoke authorisation patterns in a variety of other types of contract. ## Motivation Smart contracts commonly need to provide an interface that allows a third-party caller to perform actions on behalf of a user. The most common example of this is token authorisations/operators, but other similar situations exist throughout the ecosystem, including for instance authorising operations on ENS domains. Typically each standard reinvents this system for themselves, leading to a large number of incompatible implementations of the same basic pattern. Here, we propose a generic method usable by all such contracts. The pattern implemented here is inspired by [ds-auth](https://github.com/dapphub/ds-auth) and by OAuth. ## Specification The generalised authorisation interface is implemented as a metadata provider, as specified in EIP 926. The following mandatory function is implemented: ```solidity function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool); ``` Where: - `owner` is the owner of the resource. If approved the function call is treated as being made by this address. - `caller` is the address making the present call. - `callee` is the address of the contract being called. - `func` is the 4-byte signature of the function being called. For example, suppose Alice authorises Bob to transfer tokens on her behalf. When Bob does so, Alice is the `owner`, Bob is the `caller`, the token contract is the `callee`, and the function signature for the transfer function is `func`. As this standard uses EIP 926, the authorisation flow is as follows: 1. The callee contract fetches the provider for the `owner` address from the metadata registry contract, which resides at a well-known address. 2. The callee contract calls `canCall()` with the parameters described above. If the function returns false, the callee reverts execution. Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface: ```solidity function authoriseCaller(address owner, address caller, address callee, bytes4 func); function revokeCaller(address owner, address caller, address callee, bytes4 func); ``` Arguments have the same meaning as in `canCall`. Implementing contracts MUST ensure that `msg.sender` is authorised to call `authoriseCaller` or `revokeCaller` on behalf of `owner`; this MUST always be true if `owner == msg.sender`. Implementing contracts SHOULD use the standard specified here to determine if other callers may provide authorisations as well. Implementing contracts SHOULD treat a `func` of 0 as authorising calls to all functions on `callee`. If `authorised` is `false` and `func` is 0, contracts need only clear any blanket authorisation; individual authorisations may remain in effect. ## Backwards Compatibility There are no backwards compatibility concerns. ## Implementation Example implementation TBD. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 12 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-927 https://eips.ethereum.org/EIPS/eip-927 Modifications to ethash to invalidate existing dedicated hardware implementations Standards Track/Core ## Simple Summary This EIP modifies ethash in order to break ASIC miners specialized for the current ethash mining algorithm. ## Abstract There are companies who currently have dedicated hardware based ethereum miners in production, and may be actively mining. This EIP aims to "poison the well" by modifying the block mining algorithm in a low risk manner that may *"break"* these miners if they are in-fact built as traditional ASICs. ## Motivation ASIC-based miners will have lower operational costs than GPU-based miners, which will result in GPU-based mining quickly becoming unprofitable. Given that production of ASIC-based miners has a high barrier to entry and few market players, this will cause a trend towards centralization of mining power. Risks include market dominance by a single manufacturer that may utilize production stock to mine themselves, introduce backdoors in their hardware, or facilitate a 51% attack that would otherwise be infeasible. This trend towards centralization has a negative effect on network security, putting significant control of the network in the hands of only a few entities. Ethash remains ASIC-resistant, however ASIC manufacturer technology is advancing and ethash may require further changes in order to remain resistant to unforeseen design techniques. This EIP seeks explicitly to buy time during which newly-developed ASIC technology will face a barrier while more long-term mechanisms to ensure continued ASIC resistance can be explored. ## Specification If `block.number >= ASIC_MITIGATION_FORK_BLKNUM`, require that the ethash solution sealing the block has been mined using `ethashV2`. ## EthashV2 `ethashV2` will be identical in specification to the current `ethash`(v1) algorithm, with the exception of the implementation of `fnv`. The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 separate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing ``` c FNV_PRIME_A=0x10001a7 FNV_PRIME_B=0x10001ab FNV_PRIME_C=0x10001cf FNV_PRIME_D=0x10001e3 FNV_PRIME_E=0x10001f9 ``` `fnvA` replaces `fnv` in the DAG item selection step; `fnvB` replaces `fnv` in the DAG item mix step; `fnvC(fnvD(fnvE` replaces `fnv(fnv(fnv(` in the compress mix step. `fnv` as utilized in DAG-item creation should remain unchanged. ## Agent Changes (Optional Variant) The JSON-RPC `eth_GetWork` call may optionally return the proposed blocks algorithm. While a miner or pool may infer the requirement for `ethashV2` based on the computed epoch of the provided seedHash, it is beneficial to explicitly provide this field so a miner does not require special configuration when mining on a chain that chooses not to implement the `ASIC_Mitigation` hardfork. Due to compatibility concerns with implementations that already add additional parameters to `GetWork`, it is desired to add `BlockNumber` as an explicit 4th parameter as suggested in https://github.com/ethereum/go-ethereum/issues/2333. Algorithm should then be returned as either `"ethash"` or `"ethashV2"` according to the `block.number >= ASIC_MITIGATION_FORK_BLKNUM` criteria. ## Rationale This EIP is aimed at breaking existing ASIC-based miners via small changes to the existing ethash algorithm. We hope to accomplish the following: 1. Break existing ASIC-based miners. 2. Demonstrate a willingness to fork in the event of future ASIC miner production. Goal #1 is something that we can only do probabilistically without detailed knowledge of existing ASIC miner design. The known released miner is available for purchase [here](https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7), with delivery slated for mid-summer 2018. Our approach should balance the inherent security risks involved with changing the mining algorithm with the risk that the change we make does not break existing ASIC miners. This EIP leans towards minimizing the security risks by making minimal changes to the algorithm, accepting the risk that the change may not break dedicated hardware miners that utilize partially- or fully-configurable logic. Furthermore, we do not wish to introduce significant algorithm changes that may alter the power utilization or performance profile of existing GPU hardware. The change of FNV constant is a minimal change that can be quickly implemented across the various network node and miner implementations. It is proposed that `ASIC_MITIGATION_FORK_BLKNUM` be no more than 5550000 (epoch 185), giving around 30 days of notice to node and miner developers and a sufficient window for formal analysis of the changes by experts. We must weigh this window against the risk introduced by allowing ASICs that may exist to continue to propagate on the network, as well as the risk of providing too much advanced warning to ASIC developers. It is further understood that this change will not prevent redesign of existing dedicated hardware with new ASIC chips. The intention of this change is only to disable currently active or mid-production hardware and provide time for POS development as well as larger algorithm changes to be well analyzed by experts. The choice of FNV constants is made based on the formal specification at https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1 @goobur provided the following python code to output primes matching this criteria: ``` python candidates = [2**24 + 2**8 + _ for _ in xrange(256)] candidates = [_ for _ in candidates if is_prime(_)] ["0x%x" % _ for _ in candidates if _ % (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7)] ``` The minimal prime constraint was relaxed, as has already been the case in `ethashV1`. Typical ASIC synthesis tools would optimize multiplication of a constant in the FNV algorithm, while reducing the area needed for the multiplier according to the hamming weight of the constant. To reduce the chance of ASIC adaptation through minor mask changes, we propose choosing new constants with a larger hamming weight, however care should be taken not to choose constants with too large of a weight. The current FNV prime, `0x1000193`, has a hamming weight of 6. ``` c HammingWeight(0x10001a7) = 7; HammingWeight(0x10001ab) = 7; HammingWeight(0x10001cf) = 8; HammingWeight(0x10001e3) = 7; HammingWeight(0x10001ef) = 9; // Not chosen HammingWeight(0x10001f9) = 8; HammingWeight(0x10001fb) = 9; // Not chosen ``` An analysis can be done regarding the dispersion of these constants as compared to `0x01000193`, using the following snippet. ``` c // https://eips.ethereum.org/EIPS/eip-969 #include <stdlib.h> #include <stdio.h> #include <string.h> int main() { u_int32_t candidate = 0; u_int32_t dups = 0; u_int32_t fnv_candidate = 0x10001a7; // MODIFY! u_int8_t *counts = malloc(0xFFFFFFFF); memset(counts, '\0', 0xFFFFFFFF); for (candidate = 0; candidate < 0xFFFFFFFF; candidate++) { u_int32_t result = (u_int32_t)(candidate * fnv_candidate); u_int8_t oldCount = counts[result]; counts[result] = counts[result]+1; if (oldCount != 0) { dups++; } //// progress display: remove comment to speed down //if ((candidate & 0xFFFFF) == 0xFFFFF) printf("0x%08x\n", candidate); } printf("\nFNV candidate 0x%08x : %i dups\n", fnv_candidate, dups); return 0; } ``` It can be empirically confirmed that no more than 1 duplicate occurs in the 32-bit word space with these constants. It is worth noting that FNV is not a cryptographic hash, and it is not used as such in ethash. That said, a more invasive hash algorithm change could be considered. One suggestion has been [MurmurHash3](https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp). [Other suggestions have been made](https://twitter.com/el33th4xor/status/981292363627810818): [Argon2](https://github.com/P-H-C/phc-winner-argon2), [Equihash](https://blog.z.cash/why-equihash/) of Zcash fame, and [Balloon Hashing](https://crypto.stanford.edu/balloon/). Another possible candidate is [Cuckoo Cycle](https://github.com/tromp/cuckoo), although there are some concerns regarding unaddressed optimization vulnerabilities. One review can be found [here](https://da-data.blogspot.com/2014/03/a-public-review-of-cuckoo-cycle.html). This may be considered once the exact mechanism of the released ASICs is known and their effectiveness against its optimisations can be fully evaluated. ## Backwards Compatibility This change implements a backwards incompatible change to proof of work based block mining. All existing miners will be required to update to clients which implement this new algorithm, and all nodes will require updates to accept solutions from the new proof of work algorithm. ## Test Cases TODO: will need to generate test cases for `ethereum/tests` repository corresponding to the consensus changes. ## Implementation TODO ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 03 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-969 https://eips.ethereum.org/EIPS/eip-969 Composable Non-Fungible Token Standards Track/ERC https://ethereum-magicians.org/t/erc-998-composable-non-fungible-tokens-cnfts/387 ## Abstract An extension of the [ERC-721 standard](/EIPS/eip-721) to enable ERC-721 tokens to own other ERC-721 tokens and [ERC-20](/EIPS/eip-20) tokens. An extension of the [ERC-20](/EIPS/eip-20) and `ERC-223 https://github.com/ethereum/EIPs/issues/223` standards to enable ERC-20 and `ERC-223` tokens to be owned by ERC-721 tokens. This specification covers four different kinds of composable tokens: 1. [`ERC998ERC721` top-down composable tokens that receive, hold and transfer ERC-721 tokens](#erc-721-top-down-composable) 2. [`ERC998ERC20` top-down composable tokens that receive, hold and transfer ERC-20 tokens](#erc-20-top-down-composable) 3. [`ERC998ERC721` bottom-up composable tokens that attach themselves to other ERC-721 tokens.](#erc-721-bottom-up-composable) 4. [`ERC998ERC20` bottom-up composable tokens that attach themselves to ERC-721 tokens.](#erc-20-bottom-up-composable) which map to 1. An `ERC998ERC721` top-down composable is an ERC-721 token with additional functionality for owning other ERC-721 tokens. 2. An `ERC998ERC20` top-down composable is an ERC-721 token with additional functionality for owning ERC-20 tokens. 3. An `ERC998ERC721` bottom-up composable is an ERC-721 token with additional functionality for being owned by an ERC-721 token. 4. An `ERC998ERC20` bottom-up composable is an ERC-20 token with additional functionality for being owned by an ERC-721 token. A top-down composable contract stores and keeps track of child tokens for each of its tokens. A bottom-up composable contract stores and keeps track of a parent token for each its tokens. With composable tokens it is possible to compose lists or trees of ERC-721 and ERC-20 tokens connected by ownership. Any such structure will have a single owner address at the root of the structure that is the owner of the entire composition. The entire composition can be transferred with one transaction by changing the root owner. Different composables, top-down and bottom-up, have their advantages and disadvantages which are explained in the [Rational section](#rationale). It is possible for a token to be one or more kinds of composable token. A non-fungible token is compliant and Composable of this EIP if it implements one or more of the following interfaces: * `ERC998ERC721TopDown` * `ERC998ERC20TopDown` * `ERC998ERC721BottomUp` * `ERC998ERC20BottomUp` ## Specification ### ERC-721 `ERC998ERC721` top-down, `ERC998ERC20` top-down, and `ERC998ERC721` bottom-up composable contracts must implement the [ERC-721 interface](/EIPS/eip-721). ### ERC-20 `ERC998ERC20` bottom-up composable contracts must implement the [ERC-20 interface](/EIPS/eip-20). ### [ERC-165](/EIPS/eip-165) The [ERC-165 standard](/EIPS/eip-165) must be applied to each [ERC-998](/EIPS/eip-998) interface that is used. ### Authentication Authenticating whether a user or contract can execute some action works the same for both `ERC998ERC721` top-down and `ERC998ERC721` bottom-up composables. A `rootOwner` refers to the owner address at the top of a tree of composables and ERC-721 tokens. Authentication within any composable is done by finding the rootOwner and comparing it to `msg.sender`, the return result of `getApproved(tokenId)` and the return result of `isApprovedForAll(rootOwner, msg.sender)`. If a match is found then authentication passes, otherwise authentication fails and the contract throws. Here is an example of authentication code: ```solidity address rootOwner = address(rootOwnerOf(_tokenId)); require(rootOwner == msg.sender || isApprovedForAll(rootOwner,msg.sender) || getApproved(tokenId) == msg.sender; ``` The `approve(address _approved, uint256 _tokenId)` and `getApproved(uint256 _tokenId)` ERC-721 functions are implemented specifically for the rootOwner. This enables a tree of composables to be transferred to a new rootOwner without worrying about which addresses have been approved in child composables, because any prior approves can only be used by the prior rootOwner. Here are example implementations: ```solidity function approve(address _approved, uint256 _tokenId) external { address rootOwner = address(rootOwnerOf(_tokenId)); require(rootOwner == msg.sender || isApprovedForAll(rootOwner,msg.sender)); rootOwnerAndTokenIdToApprovedAddress[rootOwner][_tokenId] = _approved; emit Approval(rootOwner, _approved, _tokenId); } function getApproved(uint256 _tokenId) public view returns (address) { address rootOwner = address(rootOwnerOf(_tokenId)); return rootOwnerAndTokenIdToApprovedAddress[rootOwner][_tokenId]; } ``` ### Traversal The rootOwner of a composable is gotten by calling `rootOwnerOf(uint256 _tokenId)` or `rootOwnerOfChild(address _childContract, uint256 _childTokenId)`. These functions are used by top-down and bottom-up composables to traverse up the tree of composables and ERC-721 tokens to find the rootOwner. `ERC998ERC721` top-down and bottom-up composables are interoperable with each other. It is possible for a top-down composable to own a bottom-up composable or for a top-down composable to own an ERC-721 token that owns a bottom-up token. In any configuration calling `rootOwnerOf(uint256 _tokenID)` on a composable will return the root owner address at the top of the ownership tree. It is important to get the traversal logic of `rootOwnerOf` right. The logic for `rootOwnerOf` is the same whether or not a composable is bottom-up or top-down or both. Here is the logic: ``` Logic for rootOwnerOf(uint256 _tokenId) If the token is a bottom-up composable and has a parent token then call rootOwnerOf for the parent token. If the call was successful then the returned address is the rootOwner. Otherwise call rootOwnerOfChild for the parent token. If the call was successful then the returned address is the rootOwner. Otherwise get the owner address of the token and that is the rootOwner. Otherwise call rootOwnerOfChild for the token If the call was successful then the returned address is the rootOwner. Otherwise get the owner address of the token and that is the rootOwner. ``` Calling `rootOwnerOfChild` for a token means the following logic: ```solidity // Logic for calling rootOwnerOfChild for a tokenId address tokenOwner = ownerOf(tokenId); address childContract = address(this); bytes32 rootOwner = ERC998ERC721(tokenOwner).rootOwnerOfChild(childContract, tokenId); ``` But understand that the real call to `rootOwnerOfChild` should be made with assembly so that the code can check if the call failed and so that the `staticcall` opcode is used to ensure that no state is modified. Tokens/contracts that implement the above authentication and traversal functionality are "composable aware". ### Composable Transfer Function Parameter Format Composable functions that make transfers follow the same parameter format: **from:to:what**. For example the `getChild(address _from, uint256 _tokenId, address _childContract, uint256 _childTokenId)` composable function transfers an ERC-721 token from an address to a top-down composable. The `_from` parameter is the **from**, the `_tokenId` parameter is the **to** and the `address _childContract, uint256 _childTokenId` parameters are the **what**. Another example is the `safeTransferChild(uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId)` function. The `_fromTokenId` is the **from**, the `_to` is the **to** and the `address _childContract, address _childTokenId` parameters are the **what**. ### transferFrom/safeTransferFrom Functions Do Not Transfer Tokens Owned By Tokens In bottom-up and top-down composable contracts the `transferFrom` and `safeTransferFrom` functions must throw if they are called directly to transfer a token that is owned by another token. The reason for this is that these functions do not explicitly specify which token owns a token to be transferred. [See the rational section for more information about this.](#explicit-transfer-parameters) `transferFrom/safeTransferFrom` functions must be used to transfer tokens that are owned by an address. ### ERC-721 Top-Down Composable ERC-721 top-down composables act as containers for ERC-721 tokens. ERC-721 top-down composables are ERC-721 tokens that can receive, hold and transfer ERC-721 tokens. There are two ways to transfer a ERC-721 token to a top-down composable: 1. Use the `function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data)` function. The `_to` argument is the top-down composable contract address. The `bytes data` argument holds the integer value of the top-down composable tokenId that the ERC-721 token is transferred to. 2. Call `approve` in the ERC-721 token contract for the top-down composable contract. Then call `getChild` in the composable contract. The first ways is for ERC-721 contracts that have a `safeTransferFrom` function. The second way is for contracts that do not have this function such as cryptokitties. Here is an example of transferring ERC-721 token 3 from an address to top-down composable token 6: ```solidity uint256 tokenId = 6; bytes memory tokenIdBytes = new bytes(32); assembly { mstore(add(tokenIdBytes, 32), tokenId) } ERC721(contractAddress).safeTransferFrom(userAddress, composableAddress, 3, tokenIdBytes); ``` Every ERC-721 top-down composable compliant contract must implement the `ERC998ERC721TopDown` interface. The `ERC998ERC721TopDownEnumerable` and `ERC998ERC20TopDownEnumerable` interfaces are optional. ```solidity pragma solidity ^0.4.24; /// @title `ERC998ERC721` Top-Down Composable Non-Fungible Token /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-998.md /// Note: the ERC-165 identifier for this interface is 0xcde244d9 interface ERC998ERC721TopDown { /// @dev This emits when a token receives a child token. /// @param _from The prior owner of the token. /// @param _toTokenId The token that receives the child token. event ReceivedChild( address indexed _from, uint256 indexed _toTokenId, address indexed _childContract, uint256 _childTokenId ); /// @dev This emits when a child token is transferred from a token to an address. /// @param _fromTokenId The parent token that the child token is being transferred from. /// @param _to The new owner address of the child token. event TransferChild( uint256 indexed _fromTokenId, address indexed _to, address indexed _childContract, uint256 _childTokenId ); /// @notice Get the root owner of tokenId. /// @param _tokenId The token to query for a root owner address /// @return rootOwner The root owner at the top of tree of tokens and ERC-998 magic value. function rootOwnerOf(uint256 _tokenId) public view returns (bytes32 rootOwner); /// @notice Get the root owner of a child token. /// @param _childContract The contract address of the child token. /// @param _childTokenId The tokenId of the child. /// @return rootOwner The root owner at the top of tree of tokens and ERC-998 magic value. function rootOwnerOfChild( address _childContract, uint256 _childTokenId ) public view returns (bytes32 rootOwner); /// @notice Get the parent tokenId of a child token. /// @param _childContract The contract address of the child token. /// @param _childTokenId The tokenId of the child. /// @return parentTokenOwner The parent address of the parent token and ERC-998 magic value /// @return parentTokenId The parent tokenId of _tokenId function ownerOfChild( address _childContract, uint256 _childTokenId ) external view returns ( bytes32 parentTokenOwner, uint256 parentTokenId ); /// @notice A token receives a child token /// @param _operator The address that caused the transfer. /// @param _from The owner of the child token. /// @param _childTokenId The token that is being transferred to the parent. /// @param _data Up to the first 32 bytes contains an integer which is the receiving parent tokenId. function onERC721Received( address _operator, address _from, uint256 _childTokenId, bytes _data ) external returns(bytes4); /// @notice Transfer child token from top-down composable to address. /// @param _fromTokenId The owning token to transfer from. /// @param _to The address that receives the child token /// @param _childContract The ERC-721 contract of the child token. /// @param _childTokenId The tokenId of the token that is being transferred. function transferChild( uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId ) external; /// @notice Transfer child token from top-down composable to address. /// @param _fromTokenId The owning token to transfer from. /// @param _to The address that receives the child token /// @param _childContract The ERC-721 contract of the child token. /// @param _childTokenId The tokenId of the token that is being transferred. function safeTransferChild( uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId ) external; /// @notice Transfer child token from top-down composable to address. /// @param _fromTokenId The owning token to transfer from. /// @param _to The address that receives the child token /// @param _childContract The ERC-721 contract of the child token. /// @param _childTokenId The tokenId of the token that is being transferred. /// @param _data Additional data with no specified format function safeTransferChild( uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId, bytes _data ) external; /// @notice Transfer bottom-up composable child token from top-down composable to other ERC-721 token. /// @param _fromTokenId The owning token to transfer from. /// @param _toContract The ERC-721 contract of the receiving token /// @param _toTokenId The receiving token /// @param _childContract The bottom-up composable contract of the child token. /// @param _childTokenId The token that is being transferred. /// @param _data Additional data with no specified format function transferChildToParent( uint256 _fromTokenId, address _toContract, uint256 _toTokenId, address _childContract, uint256 _childTokenId, bytes _data ) external; /// @notice Get a child token from an ERC-721 contract. /// @param _from The address that owns the child token. /// @param _tokenId The token that becomes the parent owner /// @param _childContract The ERC-721 contract of the child token /// @param _childTokenId The tokenId of the child token function getChild( address _from, uint256 _tokenId, address _childContract, uint256 _childTokenId ) external; } ``` #### `rootOwnerOf` 1 ```solidity /// @notice Get the root owner of tokenId. /// @param _tokenId The token to query for a root owner address /// @return rootOwner The root owner at the top of tree of tokens and ERC-998 magic value. function rootOwnerOf(uint256 _tokenId) public view returns (bytes32 rootOwner); ``` This function traverses token owners until the root owner address of `_tokenId` is found. The first 4 bytes of rootOwner contain the ERC-998 magic value `0xcd740db5`. The last 20 bytes contain the root owner address. The magic value is returned because this function may be called on contracts when it is unknown if the contracts have a `rootOwnerOf` function. The magic value is used in such calls to ensure a valid return value is received. If it is unknown whether a contract has the `rootOwnerOf` function then the first four bytes of the `rootOwner` return value must be compared to `0xcd740db5`. `0xcd740db5` is equal to: ```solidity this.rootOwnerOf.selector ^ this.rootOwnerOfChild.selector ^ this.tokenOwnerOf.selector ^ this.ownerOfChild.selector; ``` Here is an example of a value returned by `rootOwnerOf`. `0xcd740db50000000000000000e5240103e1ff986a2c8ae6b6728ffe0d9a395c59` #### rootOwnerOfChild ```solidity /// @notice Get the root owner of a child token. /// @param _childContract The contract address of the child token. /// @param _childTokenId The tokenId of the child. /// @return rootOwner The root owner at the top of tree of tokens and ERC-998 magic value. function rootOwnerOfChild( address _childContract, uint256 _childTokenId ) public view returns (bytes32 rootOwner); ``` This function traverses token owners until the root owner address of the supplied child token is found. The first 4 bytes of rootOwner contain the ERC-998 magic value `0xcd740db5`. The last 20 bytes contain the root owner address. The magic value is returned because this function may be called on contracts when it is unknown if the contracts have a `rootOwnerOf` function. The magic value is used in such calls to ensure a valid return value is received. If it is unknown whether a contract has the `rootOwnerOfChild` function then the first four bytes of the `rootOwner` return value must be compared to `0xcd740db5`. #### ownerOfChild ```solidity /// @notice Get the parent tokenId of a child token. /// @param _childContract The contract address of the child token. /// @param _childTokenId The tokenId of the child. /// @return parentTokenOwner The parent address of the parent token and ERC-998 magic value /// @return parentTokenId The parent tokenId of _tokenId function ownerOfChild( address _childContract, uint256 _childTokenId ) external view returns ( address parentTokenOwner, uint256 parentTokenId ); ``` This function is used to get the parent tokenId of a child token and get the owner address of the parent token. The first 4 bytes of parentTokenOwner contain the ERC-998 magic value `0xcd740db5`. The last 20 bytes contain the parent token owner address. The magic value is returned because this function may be called on contracts when it is unknown if the contracts have a `ownerOfChild` function. The magic value is used in such calls to ensure a valid return value is received. If it is unknown whether a contract has the `ownerOfChild` function then the first four bytes of the `parentTokenOwner` return value must be compared to `0xcd740db5`. #### `onERC721Received` ```solidity /// @notice A token receives a child token /// @param _operator The address that caused the transfer. /// @param _from The prior owner of the child token. /// @param _childTokenId The token that is being transferred to the parent. /// @param _data Up to the first 32 bytes contains an integer which is the receiving parent tokenId. function onERC721Received( address _operator, address _from, uint256 _childTokenId, bytes _data ) external returns(bytes4); ``` This is a function defined in the ERC-721 standard. This function is called in an ERC-721 contract when `safeTransferFrom` is called. The `bytes _data` argument contains an integer value from 1 to 32 bytes long that is the parent tokenId that an ERC-721 token is transferred to. The `onERC721Received` function is how a top-down composable contract is notified that an ERC-721 token has been transferred to it and what tokenId in the top-down composable is the parent tokenId. The return value for `onERC721Received` is the magic value `0x150b7a02` which is equal to `bytes4(keccak256(abi.encodePacked("onERC721Received(address,address,uint256,bytes)")))`. #### transferChild ```solidity /// @notice Transfer child token from top-down composable to address. /// @param _fromTokenId The owning token to transfer from. /// @param _to The address that receives the child token /// @param _childContract The ERC-721 contract of the child token. /// @param _childTokenId The tokenId of the token that is being transferred. function transferChild( uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId ) external; ``` This function authenticates `msg.sender` and transfers a child token from a top-down composable to a different address. This function makes this call within it: ```solidity ERC721(_childContract).transferFrom(this, _to, _childTokenId); ``` #### safeTransferChild 1 ```solidity /// @notice Transfer child token from top-down composable to address. /// @param _fromTokenId The owning token to transfer from. /// @param _to The address that receives the child token /// @param _childContract The ERC-721 contract of the child token. /// @param _childTokenId The tokenId of the token that is being transferred. function safeTransferChild( uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId ) external; ``` This function authenticates `msg.sender` and transfers a child token from a top-down composable to a different address. This function makes this call within it: ```solidity ERC721(_childContract).safeTransferFrom(this, _to, _childTokenId); ``` #### safeTransferChild 2 ```solidity /// @notice Transfer child token from top-down composable to address or other top-down composable. /// @param _fromTokenId The owning token to transfer from. /// @param _to The address that receives the child token /// @param _childContract The ERC721 contract of the child token. /// @param _childTokenId The tokenId of the token that is being transferred. /// @param _data Additional data with no specified format, can be used to specify tokenId to transfer to function safeTransferChild( uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId, bytes _data ) external; ``` This function authenticates `msg.sender` and transfers a child token from a top-down composable to a different address or to a different top-down composable. A child token is transferred to a different top-down composable if the `_to` address is a top-down composable contract and `bytes _data` is supplied an integer representing the parent tokenId. This function makes this call within it: ```solidity ERC721(_childContract).safeTransferFrom(this, _to, _childTokenId, _data); ``` #### transferChildToParent ```solidity /// @notice Transfer bottom-up composable child token from top-down composable to other ERC-721 token. /// @param _fromTokenId The owning token to transfer from. /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _childContract The bottom-up composable contract of the child token. /// @param _childTokenId The token that is being transferred. /// @param _data Additional data with no specified format function transferChildToParent( uint256 _fromTokenId, address _toContract, uint256 _toTokenId, address _childContract, uint256 _childTokenId, bytes _data ) external ``` This function authenticates `msg.sender` and transfers a child bottom-up composable token from a top-down composable to a different ERC-721 token. This function can only be used when the child token is a bottom-up composable token. It is designed to transfer a bottom-up composable token from a top-down composable to an ERC-721 token (bottom-up style) in one transaction. This function makes this call within it: ```solidity ERC998ERC721BottomUp(_childContract).transferToParent( address(this), _toContract, _toTokenId, _childTokenId, _data ); ``` #### getChild ```solidity /// @notice Get a child token from an ERC-721 contract. /// @param _from The address that owns the child token. /// @param _tokenId The token that becomes the parent owner /// @param _childContract The ERC-721 contract of the child token /// @param _childTokenId The tokenId of the child token function getChild( address _from, uint256 _tokenId, address _childContract, uint256 _childTokenId ) external; ``` This function is used to transfer an ERC-721 token when its contract does not have a `safeTransferChild(uint256 _fromTokenId, address _to, address _childContract, uint256 _childTokenId, bytes _data)` function. A transfer with this function is done in two steps: 1. The owner of the ERC-721 token calls `approve` or `setApprovalForAll` in the ERC-721 contract for the top-down composable contract. 2. The owner of the ERC-721 token calls `getChild` in the top-down composable contract for the ERC-721 token. The `getChild` function must authenticate that `msg.sender` is the owner of the ERC-721 token in the ERC-721 contract or is approved or an operator of the ERC-721 token in the ERC-721 contract. #### ERC-721 Top-Down Composable Enumeration Optional interface for top-down composable enumeration: ```solidity /// @dev The ERC-165 identifier for this interface is 0xa344afe4 interface ERC998ERC721TopDownEnumerable { /// @notice Get the total number of child contracts with tokens that are owned by tokenId. /// @param _tokenId The parent token of child tokens in child contracts /// @return uint256 The total number of child contracts with tokens owned by tokenId. function totalChildContracts(uint256 _tokenId) external view returns(uint256); /// @notice Get child contract by tokenId and index /// @param _tokenId The parent token of child tokens in child contract /// @param _index The index position of the child contract /// @return childContract The contract found at the tokenId and index. function childContractByIndex( uint256 _tokenId, uint256 _index ) external view returns (address childContract); /// @notice Get the total number of child tokens owned by tokenId that exist in a child contract. /// @param _tokenId The parent token of child tokens /// @param _childContract The child contract containing the child tokens /// @return uint256 The total number of child tokens found in child contract that are owned by tokenId. function totalChildTokens( uint256 _tokenId, address _childContract ) external view returns(uint256); /// @notice Get child token owned by tokenId, in child contract, at index position /// @param _tokenId The parent token of the child token /// @param _childContract The child contract of the child token /// @param _index The index position of the child token. /// @return childTokenId The child tokenId for the parent token, child token and index function childTokenByIndex( uint256 _tokenId, address _childContract, uint256 _index ) external view returns (uint256 childTokenId); } ``` ### ERC-20 Top-Down Composable ERC-20 top-down composables act as containers for ERC-20 tokens. ERC-20 top-down composables are ERC-721 tokens that can receive, hold and transfer ERC-20 tokens. There are two ways to transfer ERC-20 tokens to an ERC-20 Top-Down Composable: 1. Use the `transfer(address _to, uint256 _value, bytes _data);` function from the `ERC-223` contract. The `_to` argument is the ERC-20 top-down composable contract address. The `_value` argument is how many ERC-20 tokens to transfer. The `bytes` argument holds the integer value of the top-down composable tokenId that receives the ERC-20 tokens. 2. Call `approve` in the ERC-20 contract for the ERC-20 top-down composable contract. Then call `getERC20(address _from, uint256 _tokenId, address _erc20Contract, uint256 _value)` from the ERC-20 top-down composable contract. The first way is for ERC-20 contracts that support the `ERC-223` standard. The second way is for contracts that do not. ERC-20 top-down composables implement the following interface: ```solidity /// @title `ERC998ERC20` Top-Down Composable Non-Fungible Token /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-998.md /// Note: the ERC-165 identifier for this interface is 0x7294ffed interface ERC998ERC20TopDown { /// @dev This emits when a token receives ERC-20 tokens. /// @param _from The prior owner of the token. /// @param _toTokenId The token that receives the ERC-20 tokens. /// @param _erc20Contract The ERC-20 contract. /// @param _value The number of ERC-20 tokens received. event ReceivedERC20( address indexed _from, uint256 indexed _toTokenId, address indexed _erc20Contract, uint256 _value ); /// @dev This emits when a token transfers ERC-20 tokens. /// @param _tokenId The token that owned the ERC-20 tokens. /// @param _to The address that receives the ERC-20 tokens. /// @param _erc20Contract The ERC-20 contract. /// @param _value The number of ERC-20 tokens transferred. event TransferERC20( uint256 indexed _fromTokenId, address indexed _to, address indexed _erc20Contract, uint256 _value ); /// @notice A token receives ERC-20 tokens /// @param _from The prior owner of the ERC-20 tokens /// @param _value The number of ERC-20 tokens received /// @param _data Up to the first 32 bytes contains an integer which is the receiving tokenId. function tokenFallback(address _from, uint256 _value, bytes _data) external; /// @notice Look up the balance of ERC-20 tokens for a specific token and ERC-20 contract /// @param _tokenId The token that owns the ERC-20 tokens /// @param _erc20Contract The ERC-20 contract /// @return The number of ERC-20 tokens owned by a token from an ERC-20 contract function balanceOfERC20( uint256 _tokenId, address _erc20Contract ) external view returns(uint256); /// @notice Transfer ERC-20 tokens to address /// @param _tokenId The token to transfer from /// @param _value The address to send the ERC-20 tokens to /// @param _erc20Contract The ERC-20 contract /// @param _value The number of ERC-20 tokens to transfer function transferERC20( uint256 _tokenId, address _to, address _erc20Contract, uint256 _value ) external; /// @notice Transfer ERC-20 tokens to address or ERC-20 top-down composable /// @param _tokenId The token to transfer from /// @param _value The address to send the ERC-20 tokens to /// @param _erc223Contract The `ERC-223` token contract /// @param _value The number of ERC-20 tokens to transfer /// @param _data Additional data with no specified format, can be used to specify tokenId to transfer to function transferERC223( uint256 _tokenId, address _to, address _erc223Contract, uint256 _value, bytes _data ) external; /// @notice Get ERC-20 tokens from ERC-20 contract. /// @param _from The current owner address of the ERC-20 tokens that are being transferred. /// @param _tokenId The token to transfer the ERC-20 tokens to. /// @param _erc20Contract The ERC-20 token contract /// @param _value The number of ERC-20 tokens to transfer function getERC20( address _from, uint256 _tokenId, address _erc20Contract, uint256 _value ) external; } ``` #### tokenFallback ```solidity /// @notice A token receives ERC-20 tokens /// @param _from The prior owner of the ERC-20 tokens /// @param _value The number of ERC-20 tokens received /// @param _data Up to the first 32 bytes contains an integer which is the receiving tokenId. function tokenFallback(address _from, uint256 _value, bytes _data) external; ``` This function comes from the `ERC-223` which is an extension of the ERC-20 standard. This function is called on the receiving contract from the sending contract when ERC-20 tokens are transferred. This function is how the ERC-20 top-down composable contract gets notified that one of its tokens received ERC-20 tokens. Which token received ERC-20 tokens is specified in the `_data` parameter. #### `balanceOfERC20` ```solidity /// @notice Look up the balance of ERC-20 tokens for a specific token and ERC-20 contract /// @param _tokenId The token that owns the ERC-20 tokens /// @param _erc20Contract The ERC-20 contract /// @return The number of ERC-20 tokens owned by a token from an ERC-20 contract function balanceOfERC20( uint256 _tokenId, address _erc20Contract ) external view returns(uint256); ``` Gets the balance of ERC-20 tokens owned by a token from a specific ERC-20 contract. #### `transferERC20` ```solidity /// @notice Transfer ERC-20 tokens to address /// @param _tokenId The token to transfer from /// @param _value The address to send the ERC-20 tokens to /// @param _erc20Contract The ERC-20 contract /// @param _value The number of ERC-20 tokens to transfer function transferERC20( uint256 _tokenId, address _to, address _erc20Contract, uint256 _value ) external; ``` This is used to transfer ERC-20 tokens from a token to an address. This function calls `ERC20(_erc20Contract).transfer(_to, _value)`; This function must authenticate `msg.sender`. #### `transferERC223` ```solidity /// @notice Transfer ERC-20 tokens to address or ERC-20 top-down composable /// @param _tokenId The token to transfer from /// @param _value The address to send the ERC-20 tokens to /// @param _erc223Contract The `ERC-223` token contract /// @param _value The number of ERC-20 tokens to transfer /// @param _data Additional data with no specified format, can be used to specify tokenId to transfer to function transferERC223( uint256 _tokenId, address _to, address _erc223Contract, uint256 _value, bytes _data ) external; ``` This function is from the `ERC-223`. It is used to transfer ERC-20 tokens from a token to an address or to another token by putting an integer token value in the `_data` argument. This function must authenticate `msg.sender`. #### `getERC20` ```solidity /// @notice Get ERC-20 tokens from ERC-20 contract. /// @param _from The current owner address of the ERC-20 tokens that are being transferred. /// @param _tokenId The token to transfer the ERC-20 tokens to. /// @param _erc20Contract The ERC-20 token contract /// @param _value The number of ERC-20 tokens to transfer function getERC20( address _from, uint256 _tokenId, address _erc20Contract, uint256 _value ) external; ``` This function is used to transfer ERC-20 tokens to an ERC-20 top-down composable when an ERC-20 contract does not have a `transferERC223(uint256 _tokenId, address _to, address _erc223Contract, uint256 _value, bytes _data)` function. Before this function can be used the ERC-20 top-down composable contract address must be approved in the ERC-20 contract to transfer the ERC-20 tokens. This function must authenticate that `msg.sender` equals `_from` or has been approved in the ERC-20 contract. #### ERC-20 Top-Down Composable Enumeration Optional interface for top-down composable enumeration: ```solidity /// @dev The ERC-165 identifier for this interface is 0xc5fd96cd interface ERC998ERC20TopDownEnumerable { /// @notice Get the number of ERC-20 contracts that token owns ERC-20 tokens from /// @param _tokenId The token that owns ERC-20 tokens. /// @return uint256 The number of ERC-20 contracts function totalERC20Contracts(uint256 _tokenId) external view returns(uint256); /// @notice Get an ERC-20 contract that token owns ERC-20 tokens from by index /// @param _tokenId The token that owns ERC-20 tokens. /// @param _index The index position of the ERC-20 contract. /// @return address The ERC-20 contract function erc20ContractByIndex( uint256 _tokenId, uint256 _index ) external view returns(address); } ``` ### ERC-721 Bottom-Up Composable ERC-721 bottom-up composables are ERC-721 tokens that attach themselves to other ERC-721 tokens. ERC-721 bottom-up composable contracts store the owning address of a token and the parent tokenId if any. ```solidity /// @title `ERC998ERC721` Bottom-Up Composable Non-Fungible Token /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-998.md /// Note: the ERC-165 identifier for this interface is 0xa1b23002 interface ERC998ERC721BottomUp { /// @dev This emits when a token is transferred to an ERC-721 token /// @param _toContract The contract the token is transferred to /// @param _toTokenId The token the token is transferred to /// @param _tokenId The token that is transferred event TransferToParent( address indexed _toContract, uint256 indexed _toTokenId, uint256 _tokenId ); /// @dev This emits when a token is transferred from an ERC-721 token /// @param _fromContract The contract the token is transferred from /// @param _fromTokenId The token the token is transferred from /// @param _tokenId The token that is transferred event TransferFromParent( address indexed _fromContract, uint256 indexed _fromTokenId, uint256 _tokenId ); /// @notice Get the root owner of tokenId. /// @param _tokenId The token to query for a root owner address /// @return rootOwner The root owner at the top of tree of tokens and ERC-998 magic value. function rootOwnerOf(uint256 _tokenId) external view returns (bytes32 rootOwner); /// @notice Get the owner address and parent token (if there is one) of a token /// @param _tokenId The tokenId to query. /// @return tokenOwner The owner address of the token /// @return parentTokenId The parent owner of the token and ERC-998 magic value /// @return isParent True if parentTokenId is a valid parent tokenId and false if there is no parent tokenId function tokenOwnerOf( uint256 _tokenId ) external view returns ( bytes32 tokenOwner, uint256 parentTokenId, bool isParent ); /// @notice Transfer token from owner address to a token /// @param _from The owner address /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _data Additional data with no specified format function transferToParent( address _from, address _toContract, uint256 _toTokenId, uint256 _tokenId, bytes _data ) external; /// @notice Transfer token from a token to an address /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _to The address the token is transferred to. /// @param _tokenId The token that is transferred /// @param _data Additional data with no specified format function transferFromParent( address _fromContract, uint256 _fromTokenId, address _to, uint256 _tokenId, bytes _data ) external; /// @notice Transfer a token from a token to another token /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _tokenId The token that is transferred /// @param _data Additional data with no specified format function transferAsChild( address _fromContract, uint256 _fromTokenId, address _toContract, uint256 _toTokenId, uint256 _tokenId, bytes _data ) external; } ``` #### `rootOwnerOf` ```solidity /// @notice Get the root owner of tokenId. /// @param _tokenId The token to query for a root owner address /// @return rootOwner The root owner at the top of tree of tokens and ERC-998 magic value. function rootOwnerOf(uint256 _tokenId) public view returns (bytes32 rootOwner); ``` This function traverses token owners until the root owner address of `_tokenId` is found. The first 4 bytes of rootOwner contain the ERC-998 magic value `0xcd740db5`. The last 20 bytes contain the root owner address. The magic value is returned because this function may be called on contracts when it is unknown if the contracts have a `rootOwnerOf` function. The magic value is used in such calls to ensure a valid return value is received. If it is unknown whether a contract has the `rootOwnerOf` function then the first four bytes of the `rootOwner` return value must be compared to `0xcd740db5`. `0xcd740db5` is equal to: ```solidity this.rootOwnerOf.selector ^ this.rootOwnerOfChild.selector ^ this.tokenOwnerOf.selector ^ this.ownerOfChild.selector; ``` Here is an example of a value returned by `rootOwnerOf`. `0xcd740db50000000000000000e5240103e1ff986a2c8ae6b6728ffe0d9a395c59` #### tokenOwnerOf ```solidity /// @notice Get the owner address and parent token (if there is one) of a token /// @param _tokenId The tokenId to query. /// @return tokenOwner The owner address of the token and ERC-998 magic value. /// @return parentTokenId The parent owner of the token /// @return isParent True if parentTokenId is a valid parent tokenId and false if there is no parent tokenId function tokenOwnerOf( uint256 _tokenId ) external view returns ( bytes32 tokenOwner, uint256 parentTokenId, bool isParent ); ``` This function is used to get the owning address and parent tokenId of a token if there is one stored in the contract. If `isParent` is true then `tokenOwner` is the owning ERC-721 contract address and `parentTokenId` is a valid parent tokenId. If `isParent` is false then `tokenOwner` is a user address and `parentTokenId` does not contain a valid parent tokenId and must be ignored. The first 4 bytes of `tokenOwner` contain the ERC-998 magic value `0xcd740db5`. The last 20 bytes contain the token owner address. The magic value is returned because this function may be called on contracts when it is unknown if the contracts have a `tokenOwnerOf` function. The magic value is used in such calls to ensure a valid return value is received. If it is unknown whether a contract has the `rootOwnerOf` function then the first four bytes of the `tokenOwner` return value must be compared to `0xcd740db5`. #### transferToParent ```solidity /// @notice Transfer token from owner address to a token /// @param _from The owner address /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _data Additional data with no specified format function transferToParent( address _from, address _toContract, uint256 _toTokenId, uint256 _tokenId, bytes _data ) external; ``` This function is used to transfer a token from an address to a token. `msg.sender` must be authenticated. This function must check that `_toToken` exists in `_toContract` and throw if not. #### transferFromParent ```solidity /// @notice Transfer token from a token to an address /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _to The address the token is transferred to. /// @param _tokenId The token that is transferred /// @param _data Additional data with no specified format function transferFromParent( address _fromContract, uint256 _fromTokenId, address _to, uint256 _tokenId, bytes _data ) external; ``` This function is used to transfer a token from a token to an address. `msg.sender` must be authenticated. This function must check that `_fromContract` and `_fromTokenId` own `_tokenId` and throw not. #### transferAsChild ```solidity /// @notice Transfer a token from a token to another token /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _tokenId The token that is transferred /// @param _data Additional data with no specified format function transferAsChild( address _fromContract, uint256 _fromTokenId, address _toContract, uint256 _toTokenId, uint256 _tokenId, bytes _data ) external; ``` This function is used to transfer a token from a token to another token. `msg.sender` must be authenticated. This function must check that `_toToken` exists in `_toContract` and throw if not. This function must check that `_fromContract` and `_fromTokenId` own `_tokenId` and throw if not. #### ERC-721 Bottom-Up Composable Enumeration Optional interface for bottom-up composable enumeration: ```solidity /// @dev The ERC-165 identifier for this interface is 0x8318b539 interface ERC998ERC721BottomUpEnumerable { /// @notice Get the number of ERC-721 tokens owned by parent token. /// @param _parentContract The contract the parent ERC-721 token is from. /// @param _parentTokenId The parent tokenId that owns tokens // @return uint256 The number of ERC-721 tokens owned by parent token. function totalChildTokens( address _parentContract, uint256 _parentTokenId ) external view returns (uint256); /// @notice Get a child token by index /// @param _parentContract The contract the parent ERC-721 token is from. /// @param _parentTokenId The parent tokenId that owns the token /// @param _index The index position of the child token /// @return uint256 The child tokenId owned by the parent token function childTokenByIndex( address _parentContract, uint256 _parentTokenId, uint256 _index ) external view returns (uint256); } ``` ### ERC-20 Bottom-Up Composable ERC-20 bottom-up composables are ERC-20 tokens that attach themselves to ERC-721 tokens, or are owned by a user address like standard ERC-20 tokens. When owned by an ERC-721 token, ERC-20 bottom-up composable contracts store the owning address of a token and the parent tokenId. ERC-20 bottom-up composables add several methods to the ERC-20 and `ERC-223` interfaces allowing for querying the balance of parent tokens, and transferring tokens to, from, and between parent tokens. This functionality can be implemented by adding one additional mapping to track balances of tokens, in addition to the standard mapping for tracking user address balances. ```solidity /// @dev This mapping tracks standard ERC20/`ERC-223` ownership, where an address owns /// a particular amount of tokens. mapping(address => uint) userBalances; /// @dev This additional mapping tracks ERC-998 ownership, where an ERC-721 token owns /// a particular amount of tokens. This tracks contractAddres => tokenId => balance mapping(address => mapping(uint => uint)) nftBalances; ``` The complete interface is below. ```solidity /// @title `ERC998ERC20` Bottom-Up Composable Fungible Token /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-998.md /// Note: The ERC-165 identifier for this interface is 0xffafa991 interface ERC998ERC20BottomUp { /// @dev This emits when a token is transferred to an ERC-721 token /// @param _toContract The contract the token is transferred to /// @param _toTokenId The token the token is transferred to /// @param _amount The amount of tokens transferred event TransferToParent( address indexed _toContract, uint256 indexed _toTokenId, uint256 _amount ); /// @dev This emits when a token is transferred from an ERC-721 token /// @param _fromContract The contract the token is transferred from /// @param _fromTokenId The token the token is transferred from /// @param _amount The amount of tokens transferred event TransferFromParent( address indexed _fromContract, uint256 indexed _fromTokenId, uint256 _amount ); /// @notice Get the balance of a non-fungible parent token /// @param _tokenContract The contract tracking the parent token /// @param _tokenId The ID of the parent token /// @return amount The balance of the token function balanceOfToken( address _tokenContract, uint256 _tokenId ) external view returns (uint256 amount); /// @notice Transfer tokens from owner address to a token /// @param _from The owner address /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _amount The amount of tokens to transfer function transferToParent( address _from, address _toContract, uint256 _toTokenId, uint256 _amount ) external; /// @notice Transfer token from a token to an address /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _to The address the token is transferred to /// @param _amount The amount of tokens to transfer function transferFromParent( address _fromContract, uint256 _fromTokenId, address _to, uint256 _amount ) external; /// @notice Transfer token from a token to an address, using `ERC-223` semantics /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _to The address the token is transferred to /// @param _amount The amount of tokens to transfer /// @param _data Additional data with no specified format, can be used to specify the sender tokenId function transferFromParentERC223( address _fromContract, uint256 _fromTokenId, address _to, uint256 _amount, bytes _data ) external; /// @notice Transfer a token from a token to another token /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _amount The amount tokens to transfer function transferAsChild( address _fromContract, uint256 _fromTokenId, address _toContract, uint256 _toTokenId, uint256 _amount ) external; } ``` #### balanceOfToken ```solidity /// @notice Get the balance of a non-fungible parent token /// @param _tokenContract The contract tracking the parent token /// @param _tokenId The ID of the parent token /// @return amount The balance of the token function balanceOfToken( address _tokenContract, uint256 _tokenId ) external view returns (uint256 amount); ``` This function returns the balance of a non-fungible token. It mirrors the standard ERC-20 method `balanceOf`, but accepts the address of the parent token's contract, and the parent token's ID. This method behaves identically to `balanceOf`, but checks for ownership by ERC-721 tokens rather than user addresses. #### `transferToParent` ```solidity /// @notice Transfer tokens from owner address to a token /// @param _from The owner address /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _amount The amount of tokens to transfer function transferToParent( address _from, address _toContract, uint256 _toTokenId, uint256 _amount ) external; ``` This function transfers an amount of tokens from a user address to an ERC-721 token. This function MUST ensure that the recipient contract implements ERC-721 using the ERC-165 `supportsInterface` function. This function SHOULD ensure that the recipient token actually exists, by calling `ownerOf` on the recipient token's contract, and ensuring it neither throws nor returns the zero address. This function MUST emit the `TransferToParent` event upon a successful transfer (in addition to the standard ERC-20 `Transfer` event!). This function MUST throw if the `_from` account balance does not have enough tokens to spend. #### `transferFromParent` ```solidity /// @notice Transfer token from a token to an address /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _to The address the token is transferred to /// @param _amount The amount of tokens to transfer function transferFromParent( address _fromContract, uint256 _fromTokenId, address _to, uint256 _amount ) external; ``` This function transfers an amount of tokens from an ERC-721 token to an address. This function MUST emit the `TransferFromParent` event upon a successful transfer (in addition to the standard ERC-20 `Transfer` event!). This function MUST throw if the balance of the sender ERC-721 token is less than the `_amount` specified. This function MUST verify that the `msg.sender` owns the sender ERC-721 token, and MUST throw otherwise. #### `transferFromParentERC223` ```solidity /// @notice Transfer token from a token to an address, using `ERC-223` semantics /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _to The address the token is transferred to /// @param _amount The amount of tokens to transfer /// @param _data Additional data with no specified format, can be used to specify the sender tokenId function transferFromParentERC223( address _fromContract, uint256 _fromTokenId, address _to, uint256 _amount, bytes _data ) external; ``` This function transfers an amount of tokens from an ERC-721 token to an address. This function has identical requirements to `transferFromParent`, except that it additionally MUST invoke `tokenFallback` on the recipient address, if the address is a contract, as specified by `ERC-223`. #### transferAsChild 1 ```solidity /// @notice Transfer a token from a token to another token /// @param _fromContract The address of the owning contract /// @param _fromTokenId The owning token /// @param _toContract The ERC-721 contract of the receiving token /// @param _toToken The receiving token /// @param _amount The amount tokens to transfer function transferAsChild( address _fromContract, uint256 _fromTokenId, address _toContract, uint256 _toTokenId, uint256 _amount ) external; ``` This function transfers an amount of tokens from an ERC-721 token to another ERC-721 token. This function MUST emit BOTH the `TransferFromParent` and `TransferToParent` events (in addition to the standard ERC-20 `Transfer` event!). This function MUST throw if the balance of the sender ERC-721 token is less than the `_amount` specified. This function MUST verify that the `msg.sender` owns the sender ERC-721 token, and MUST throw otherwise. This function MUST ensure that the recipient contract implements ERC-721 using the ERC-165 `supportsInterface` function. This function SHOULD ensure that the recipient token actually exists, by calling `ownerOf` on the recipient token's contract, and ensuring it neither throws nor returns the zero address. ### Notes For backwards-compatibility, implementations MUST emit the standard ERC-20 `Transfer` event when a transfer occurs, regardless of whether the sender and recipient are addresses or ERC-721 tokens. In the case that either sender or recipient are tokens, the corresponding parameter in the `Transfer` event SHOULD be the contract address of the token. Implementations MUST implement all ERC-20 and `ERC-223` functions in addition to the functions specified in this interface. ## Rationale Two different kinds of composable (top-down and bottom-up) exist to handle different use cases. A regular ERC-721 token cannot own a top-down composable, but it can own a bottom-up composable. A bottom-up composable cannot own a regular ERC-721 but a top-down composable can own a regular ERC-721 token. Having multiple kinds of composables enable different token ownership possibilities. ### Which Kind of Composable To Use? If you want to transfer regular ERC-721 tokens to non-fungible tokens, then use top-down composables. If you want to transfer non-fungible tokens to regular ERC-721 tokens then use bottom-up composables. ### Explicit Transfer Parameters Every ERC-998 transfer function includes explicit parameters to specify the prior owner and the new owner of a token. Explicitly providing **from** and **to** is done intentionally to avoid situations where tokens are transferred in unintended ways. Here is an example of what could occur if **from** was not explicitly provided in transfer functions: > An exchange contract is an approved operator in a specific composable contract for user A, user B and user C. > > User A transfers token 1 to user B. At the same time the exchange contract transfers token 1 to user C (with the implicit intention to transfer from user A). User B gets token 1 for a minute before it gets incorrectly transferred to user C. The second transfer should have failed but it didn't because no explicit **from** was provided to ensure that token 1 came from user A. ## Backwards Compatibility Composables are designed to work with ERC-721, `ERC-223` and ERC-20 tokens. Some older ERC-721 contracts do not have a `safeTransferFrom` function. The `getChild` function can still be used to transfer a token to an ERC-721 top-down composable. If an ERC-20 contract does not have the `ERC-223` function `transfer(address _to, uint _value, bytes _data)` then the `getERC20` function can still be used to transfer ERC-20 tokens to an ERC-20 top-down composable. ## Reference Implementation An implementation can be found here: `https://github.com/mattlockyer/composables-998` ## Security Considerations Needs discussion. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 07 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-998 https://eips.ethereum.org/EIPS/eip-998 Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 Standards Track/Core https://ethereum-magicians.org/t/eip-999-restore-contract-code-at-0x863df6bfa4/130 ## Simple Summary This document proposes to restore the contract code of the `WalletLibrary` contract at `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4` with a patched version. The contract was accidentally self-destructed and renders a significant amount of Ether inaccessible. ## Abstract The `WalletLibrary` contract was used by the [Parity Wallet](https://www.parity.io/) to reduce gas costs for users deploying multi-signature wallets on the Ethereum blockchain. It contained basic functionality such as confirming or revoking multi-signature transactions for any wallet deployed that depends on this library. The [accidental self-destruction](https://github.com/paritytech/parity/issues/6995) of the library contract caused significant amounts of Ether and other assets owned by many different parties to be inaccessible. This proposal suggests restoring the `WalletLibrary` by a [patched](https://github.com/parity-contracts/0x863df6bfa4) version to allow the owners of the dependent multi-signature wallets regain access to their assets. ## Motivation This proposal is necessary because the Ethereum protocol does not allow the restoration of self-destructed contracts and there is no other simple way to enable the affected users and companies regaining access to their tokens and Ether. In opposite to previously discussed proposals, this will not change any EVM semantics and tries to achieve the goal of unfreezing the funds by a single state transition as specified in the next section. ## Specification The self-destructed contract code at [`0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4`](https://etherscan.io/address/0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4#code) shall be replaced with a patched version of the [`walletLibrary.sol`](https://github.com/parity-contracts/0x863df6bfa4/blob/master/contracts/walletLibrary.sol) as reviewed, tested, and approved in [parity-contracts/0x863df6bfa4](https://github.com/parity-contracts/0x863df6bfa4): ```json { "object": "606060405234156200000d57fe5b5b6000808054806001018281620000259190620002d9565b916000526020600020900160005b6000909190916101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550506200012081805480602002602001604051908101604052809291908181526020018280548015620000fd57602002820191906000526020600020905b8160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019060010190808311620000b2575b505050505060016000620001286401000000000262001d46176401000000009004565b5b5062000330565b600060015411156200013a5760006000fd5b6200015981620001806401000000000262001d71176401000000009004565b620001798383620001c26401000000000262001d9c176401000000009004565b5b5b505050565b60006001541115620001925760006000fd5b80600281905550620001b7620002c16401000000000262001bcf176401000000009004565b6004819055505b5b50565b600060006001541115620001d65760006000fd5b600082111515620001e75760006000fd5b81835110151515620001f95760006000fd5b8251600181905550600090505b8251811015620002b35782818151811015156200021f57fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff16600582600101610100811015156200025357fe5b0160005b508190555080600101610105600085848151811015156200027457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b80600101905062000206565b816000819055505b5b505050565b60006201518042811515620002d257fe5b0490505b90565b815481835581811511620003035781836000526020600020918201910162000302919062000308565b5b505050565b6200032d91905b80821115620003295760008160009055506001016200030f565b5090565b90565b611ebf80620003406000396000f300606060405236156100ef576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063173825d91461016d5780632f54bf6e146101a35780634123cb6b146101f157806352375093146102175780635c52c2f51461023d578063659010e71461024f5780637065cb4814610275578063746c9171146102ab578063797af627146102d1578063b20d30a91461030d578063b61d27f61461032d578063b75c7dc61461039c578063ba51a6df146103c0578063c2cf7326146103e0578063c41a360a1461043b578063f00d4b5d1461049b578063f1736d86146104f0575b61016b5b6000341115610168577fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c3334604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a15b5b565b005b341561017557fe5b6101a1600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610516565b005b34156101ab57fe5b6101d7600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610659565b604051808215151515815260200191505060405180910390f35b34156101f957fe5b610201610691565b6040518082815260200191505060405180910390f35b341561021f57fe5b610227610697565b6040518082815260200191505060405180910390f35b341561024557fe5b61024d61069d565b005b341561025757fe5b61025f6106d7565b6040518082815260200191505060405180910390f35b341561027d57fe5b6102a9600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506106dd565b005b34156102b357fe5b6102bb610829565b6040518082815260200191505060405180910390f35b34156102d957fe5b6102f360048080356000191690602001909190505061082f565b604051808215151515815260200191505060405180910390f35b341561031557fe5b61032b6004808035906020019091905050610dcc565b005b341561033557fe5b61037e600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919080359060200190919080359060200190820180359060200191909192905050610e06565b60405180826000191660001916815260200191505060405180910390f35b34156103a457fe5b6103be60048080356000191690602001909190505061127d565b005b34156103c857fe5b6103de6004808035906020019091905050611392565b005b34156103e857fe5b61042160048080356000191690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190505061141a565b604051808215151515815260200191505060405180910390f35b341561044357fe5b610459600480803590602001909190505061149c565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34156104a357fe5b6104ee600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506114bf565b005b34156104f857fe5b610500611672565b6040518082815260200191505060405180910390f35b600060003660405180838380828437820191505092505050604051809103902061053f81611678565b156106535761010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561057f57610652565b600160015403600054111561059357610652565b6000600583610100811015156105a557fe5b0160005b5081905550600061010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506105e6611890565b6105ee6119d0565b7f58619076adf5bb0943d100ef88d52d7c3fd691b19d3a9071b555b651fbf418da83604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b505050565b6000600061010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541190505b919050565b60015481565b60045481565b6000366040518083838082843782019150509250505060405180910390206106c481611678565b156106d35760006003819055505b5b5b50565b60035481565b60003660405180838380828437820191505092505050604051809103902061070481611678565b156108245761071282610659565b1561071c57610823565b610724611890565b60fa600154101515610739576107386119d0565b5b60fa60015410151561074a57610823565b6001600081548092919060010191905055508173ffffffffffffffffffffffffffffffffffffffff1660056001546101008110151561078557fe5b0160005b508190555060015461010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507f994a936646fe87ffe4f1e469d3d6aa417d6b855598397f323de5b449f765f0c382604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b5050565b60005481565b600060008261083d81611678565b15610dc45760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415806108c757506000610108600086600019166000191681526020019081526020016000206001015414155b80610906575060006101086000866000191660001916815260200190815260200160002060020180546001816001161561010002031660029004905014155b15610dc25760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415610a5057610a496101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610a3f5780601f10610a1457610100808354040283529160200191610a3f565b820191906000526020600020905b815481529060010190602001808311610a2257829003601f168201915b5050505050611b37565b9150610b71565b6101086000856000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002016040518082805460018160011615610100020316600290048015610b4a5780601f10610b1f57610100808354040283529160200191610b4a565b820191906000526020600020905b815481529060010190602001808311610b2d57829003601f168201915b505091505060006040518083038185876185025a03f1925050501515610b705760006000fd5b5b7fe3a3a4111a84df27d76b68dc721e65c7711605ea5eee4afd3a9c58195217365c338561010860008860001916600019168152602001908152602001600020600101546101086000896000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1661010860008a6000191660001916815260200190815260200160002060020187604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200186600019166000191681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001828103825284818154600181600116156101000203166002900481526020019150805460018160011615610100020316600290048015610d475780601f10610d1c57610100808354040283529160200191610d47565b820191906000526020600020905b815481529060010190602001808311610d2a57829003601f168201915b505097505050505050505060405180910390a16101086000856000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff02191690556001820160009055600282016000610db79190611be6565b505060019250610dc3565b5b5b5b5050919050565b600036604051808383808284378201915050925050506040518091039020610df381611678565b15610e0157816002819055505b5b5b5050565b60006000610e1333610659565b1561127357600084849050148015610e305750610e2f85611b51565b5b80610e3d57506001600054145b15610fed5760008673ffffffffffffffffffffffffffffffffffffffff161415610ea457610e9d8585858080601f016020809104026020016040519081016040528093929190818152602001838380828437820191505050505050611b37565b9050610ef3565b8573ffffffffffffffffffffffffffffffffffffffff168585856040518083838082843782019150509250505060006040518083038185876185025a03f1925050501515610ef25760006000fd5b5b7f9738cd1a8777c86b011f7b01d87d484217dc6ab5154a9d41eda5d14af8caf292338688878786604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018681526020018573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281038252858582818152602001925080828437820191505097505050505050505060405180910390a1611271565b6000364360405180848480828437820191505082815260200193505050506040518091039020915060006101086000846000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16148015611099575060006101086000846000191660001916815260200190815260200160002060010154145b80156110d85750600061010860008460001916600019168152602001908152602001600020600201805460018160011615610100020316600290049050145b1561118f57856101086000846000191660001916815260200190815260200160002060000160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550846101086000846000191660001916815260200190815260200160002060010181905550838361010860008560001916600019168152602001908152602001600020600201919061118d929190611c2e565b505b6111988261082f565b1515611270577f1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf328233878988886040518087600019166000191681526020018673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018281038252848482818152602001925080828437820191505097505050505050505060405180910390a15b5b5b5b5b50949350505050565b60006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156112be5761138c565b8260020a9150610106600085600019166000191681526020019081526020016000209050600082826001015416111561138b5780600001600081548092919060010191905055508181600101600082825403925050819055507fc7fb647e59b18047309aa15aad418e5d7ca96d173ad704f1031a2c3d7591734b3385604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a15b5b50505050565b6000366040518083838082843782019150509250505060405180910390206113b981611678565b15611415576001548211156113cd57611414565b816000819055506113dc611890565b7facbdb084c721332ac59f9b8e392196c9eb0e4932862da8eb9beaf0dad4f550da826040518082815260200191505060405180910390a15b5b5b5050565b600060006000600061010660008760001916600019168152602001908152602001600020925061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561147f5760009350611493565b8160020a9050600081846001015416141593505b50505092915050565b6000600560018301610100811015156114b157fe5b0160005b505490505b919050565b60006000366040518083838082843782019150509250505060405180910390206114e881611678565b1561166b576114f683610659565b156115005761166a565b61010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561153b5761166a565b611543611890565b8273ffffffffffffffffffffffffffffffffffffffff166005836101008110151561156a57fe5b0160005b5081905550600061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508161010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507fb532073b38c83145e3e5135377a08bf9aab55bc0fd7c1179cd4fb995d2a5159c8484604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019250505060405180910390a15b5b5b50505050565b60025481565b600060006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156116bb57611888565b6101066000866000191660001916815260200190815260200160002091506000826000015414156117455760005482600001819055506000826001018190555061010780548091906001016117109190611cae565b826002018190555084610107836002015481548110151561172d57fe5b906000526020600020900160005b5081600019169055505b8260020a90506000818360010154161415611887577fe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda3386604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a16001826000015411151561185e57610107610106600087600019166000191681526020019081526020016000206002015481548110151561180a57fe5b906000526020600020900160005b5060009055610106600086600019166000191681526020019081526020016000206000600082016000905560018201600090556002820160009055505060019350611888565b8160000160008154809291906001900391905055508082600101600082825417925050819055505b5b5b505050919050565b60006000610107805490509150600090505b818110156119bc576101086000610107838154811015156118bf57fe5b906000526020600020900160005b50546000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560018201600090556002820160006119269190611be6565b505060006001026101078281548110151561193d57fe5b906000526020600020900160005b5054600019161415156119b05761010660006101078381548110151561196d57fe5b906000526020600020900160005b505460001916600019168152602001908152602001600020600060008201600090556001820160009055600282016000905550505b5b8060010190506118a2565b61010760006119cb9190611cda565b5b5050565b6000600190505b600154811015611b33575b60015481108015611a095750600060058261010081101515611a0057fe5b0160005b505414155b15611a1b5780806001019150506119e2565b5b6001600154118015611a4557506000600560015461010081101515611a3d57fe5b0160005b5054145b15611a625760016000815480929190600190039190505550611a1c565b60015481108015611a8b57506000600560015461010081101515611a8257fe5b0160005b505414155b8015611aac5750600060058261010081101515611aa457fe5b0160005b5054145b15611b2e57600560015461010081101515611ac357fe5b0160005b505460058261010081101515611ad957fe5b0160005b508190555080610105600060058461010081101515611af857fe5b0160005b50548152602001908152602001600020819055506000600560015461010081101515611b2457fe5b0160005b50819055505b6119d7565b5b50565b600081516020830184f09050803b15610000575b92915050565b6000611b5c33610659565b15611bc957600454611b6c611bcf565b1115611b89576000600381905550611b82611bcf565b6004819055505b600354826003540110158015611ba55750600254826003540111155b15611bc3578160036000828254019250508190555060019050611bc8565b600090505b5b5b919050565b60006201518042811515611bdf57fe5b0490505b90565b50805460018160011615610100020316600290046000825580601f10611c0c5750611c2b565b601f016020900490600052602060002090810190611c2a9190611cfc565b5b50565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f10611c6f57803560ff1916838001178555611c9d565b82800160010185558215611c9d579182015b82811115611c9c578235825591602001919060010190611c81565b5b509050611caa9190611cfc565b5090565b815481835581811511611cd557818360005260206000209182019101611cd49190611d21565b5b505050565b5080546000825590600052602060002090810190611cf89190611d21565b5b50565b611d1e91905b80821115611d1a576000816000905550600101611d02565b5090565b90565b611d4391905b80821115611d3f576000816000905550600101611d27565b5090565b90565b60006001541115611d575760006000fd5b611d6081611d71565b611d6a8383611d9c565b5b5b505050565b60006001541115611d825760006000fd5b80600281905550611d91611bcf565b6004819055505b5b50565b600060006001541115611daf5760006000fd5b600082111515611dbf5760006000fd5b81835110151515611dd05760006000fd5b8251600181905550600090505b8251811015611e85578281815181101515611df457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff1660058260010161010081101515611e2757fe5b0160005b50819055508060010161010560008584815181101515611e4757fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b806001019050611ddd565b816000819055505b5b5050505600a165627a7a7230582016889f0740f073d397f9d00b0d19900fb050b957e3e2942f861085beb9baab180029", "opcodes": "PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH3 0xD JUMPI INVALID JUMPDEST JUMPDEST PUSH1 0x0 DUP1 DUP1 SLOAD DUP1 PUSH1 0x1 ADD DUP3 DUP2 PUSH3 0x25 SWAP2 SWAP1 PUSH3 0x2D9 JUMP JUMPDEST SWAP2 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST PUSH1 0x0 SWAP1 SWAP2 SWAP1 SWAP2 PUSH2 0x100 EXP DUP2 SLOAD DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR SWAP1 SSTORE POP POP PUSH3 0x120 DUP2 DUP1 SLOAD DUP1 PUSH1 0x20 MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP1 SLOAD DUP1 ISZERO PUSH3 0xFD JUMPI PUSH1 0x20 MUL DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 PUSH1 0x1 ADD SWAP1 DUP1 DUP4 GT PUSH3 0xB2 JUMPI JUMPDEST POP POP POP POP POP PUSH1 0x1 PUSH1 0x0 PUSH3 0x128 PUSH5 0x100000000 MUL PUSH3 0x1D46 OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST JUMPDEST POP PUSH3 0x330 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x13A JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH3 0x159 DUP2 PUSH3 0x180 PUSH5 0x100000000 MUL PUSH3 0x1D71 OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST PUSH3 0x179 DUP4 DUP4 PUSH3 0x1C2 PUSH5 0x100000000 MUL PUSH3 0x1D9C OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x192 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP1 PUSH1 0x2 DUP2 SWAP1 SSTORE POP PUSH3 0x1B7 PUSH3 0x2C1 PUSH5 0x100000000 MUL PUSH3 0x1BCF OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x1D6 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH1 0x0 DUP3 GT ISZERO ISZERO PUSH3 0x1E7 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP2 DUP4 MLOAD LT ISZERO ISZERO ISZERO PUSH3 0x1F9 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP3 MLOAD PUSH1 0x1 DUP2 SWAP1 SSTORE POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP3 MLOAD DUP2 LT ISZERO PUSH3 0x2B3 JUMPI DUP3 DUP2 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH3 0x21F JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP3 PUSH1 0x1 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH3 0x253 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH1 0x1 ADD PUSH2 0x105 PUSH1 0x0 DUP6 DUP5 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH3 0x274 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH3 0x206 JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH3 0x15180 TIMESTAMP DUP2 ISZERO ISZERO PUSH3 0x2D2 JUMPI INVALID JUMPDEST DIV SWAP1 POP JUMPDEST SWAP1 JUMP JUMPDEST DUP2 SLOAD DUP2 DUP4 SSTORE DUP2 DUP2 ISZERO GT PUSH3 0x303 JUMPI DUP2 DUP4 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP2 DUP3 ADD SWAP2 ADD PUSH3 0x302 SWAP2 SWAP1 PUSH3 0x308 JUMP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH3 0x32D SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH3 0x329 JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH3 0x30F JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH2 0x1EBF DUP1 PUSH3 0x340 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x60 PUSH1 0x40 MSTORE CALLDATASIZE ISZERO PUSH2 0xEF JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0x173825D9 EQ PUSH2 0x16D JUMPI DUP1 PUSH4 0x2F54BF6E EQ PUSH2 0x1A3 JUMPI DUP1 PUSH4 0x4123CB6B EQ PUSH2 0x1F1 JUMPI DUP1 PUSH4 0x52375093 EQ PUSH2 0x217 JUMPI DUP1 PUSH4 0x5C52C2F5 EQ PUSH2 0x23D JUMPI DUP1 PUSH4 0x659010E7 EQ PUSH2 0x24F JUMPI DUP1 PUSH4 0x7065CB48 EQ PUSH2 0x275 JUMPI DUP1 PUSH4 0x746C9171 EQ PUSH2 0x2AB JUMPI DUP1 PUSH4 0x797AF627 EQ PUSH2 0x2D1 JUMPI DUP1 PUSH4 0xB20D30A9 EQ PUSH2 0x30D JUMPI DUP1 PUSH4 0xB61D27F6 EQ PUSH2 0x32D JUMPI DUP1 PUSH4 0xB75C7DC6 EQ PUSH2 0x39C JUMPI DUP1 PUSH4 0xBA51A6DF EQ PUSH2 0x3C0 JUMPI DUP1 PUSH4 0xC2CF7326 EQ PUSH2 0x3E0 JUMPI DUP1 PUSH4 0xC41A360A EQ PUSH2 0x43B JUMPI DUP1 PUSH4 0xF00D4B5D EQ PUSH2 0x49B JUMPI DUP1 PUSH4 0xF1736D86 EQ PUSH2 0x4F0 JUMPI JUMPDEST PUSH2 0x16B JUMPDEST PUSH1 0x0 CALLVALUE GT ISZERO PUSH2 0x168 JUMPI PUSH32 0xE1FFFCC4923D04B559F4D29A8BFC6CDA04EB5B0D3C460751C2402C5C5CC9109C CALLER CALLVALUE PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x175 JUMPI INVALID JUMPDEST PUSH2 0x1A1 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x516 JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x1AB JUMPI INVALID JUMPDEST PUSH2 0x1D7 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x659 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x1F9 JUMPI INVALID JUMPDEST PUSH2 0x201 PUSH2 0x691 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x21F JUMPI INVALID JUMPDEST PUSH2 0x227 PUSH2 0x697 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x245 JUMPI INVALID JUMPDEST PUSH2 0x24D PUSH2 0x69D JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x257 JUMPI INVALID JUMPDEST PUSH2 0x25F PUSH2 0x6D7 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x27D JUMPI INVALID JUMPDEST PUSH2 0x2A9 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x6DD JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x2B3 JUMPI INVALID JUMPDEST PUSH2 0x2BB PUSH2 0x829 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x2D9 JUMPI INVALID JUMPDEST PUSH2 0x2F3 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x82F JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x315 JUMPI INVALID JUMPDEST PUSH2 0x32B PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0xDCC JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x335 JUMPI INVALID JUMPDEST PUSH2 0x37E PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP3 ADD DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP2 SWAP1 SWAP2 SWAP3 SWAP1 POP POP PUSH2 0xE06 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x3A4 JUMPI INVALID JUMPDEST PUSH2 0x3BE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x127D JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x3C8 JUMPI INVALID JUMPDEST PUSH2 0x3DE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x1392 JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x3E8 JUMPI INVALID JUMPDEST PUSH2 0x421 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x141A JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x443 JUMPI INVALID JUMPDEST PUSH2 0x459 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x149C JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x4A3 JUMPI INVALID JUMPDEST PUSH2 0x4EE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x14BF JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x4F8 JUMPI INVALID JUMPDEST PUSH2 0x500 PUSH2 0x1672 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x0 PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x53F DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x653 JUMPI PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x57F JUMPI PUSH2 0x652 JUMP JUMPDEST PUSH1 0x1 PUSH1 0x1 SLOAD SUB PUSH1 0x0 SLOAD GT ISZERO PUSH2 0x593 JUMPI PUSH2 0x652 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x5 DUP4 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x5A5 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH2 0x5E6 PUSH2 0x1890 JUMP JUMPDEST PUSH2 0x5EE PUSH2 0x19D0 JUMP JUMPDEST PUSH32 0x58619076ADF5BB0943D100EF88D52D7C3FD691B19D3A9071B555B651FBF418DA DUP4 PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD GT SWAP1 POP JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x1 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x4 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x6C4 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x6D3 JUMPI PUSH1 0x0 PUSH1 0x3 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x3 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x704 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x824 JUMPI PUSH2 0x712 DUP3 PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x71C JUMPI PUSH2 0x823 JUMP JUMPDEST PUSH2 0x724 PUSH2 0x1890 JUMP JUMPDEST PUSH1 0xFA PUSH1 0x1 SLOAD LT ISZERO ISZERO PUSH2 0x739 JUMPI PUSH2 0x738 PUSH2 0x19D0 JUMP JUMPDEST JUMPDEST PUSH1 0xFA PUSH1 0x1 SLOAD LT ISZERO ISZERO PUSH2 0x74A JUMPI PUSH2 0x823 JUMP JUMPDEST PUSH1 0x1 PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 ADD SWAP2 SWAP1 POP SSTORE POP DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x785 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x1 SLOAD PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH32 0x994A936646FE87FFE4F1E469D3D6AA417D6B855598397F323DE5B449F765F0C3 DUP3 PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 DUP3 PUSH2 0x83D DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0xDC4 JUMPI PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO DUP1 PUSH2 0x8C7 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD EQ ISZERO JUMPDEST DUP1 PUSH2 0x906 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 POP EQ ISZERO JUMPDEST ISZERO PUSH2 0xDC2 JUMPI PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO PUSH2 0xA50 JUMPI PUSH2 0xA49 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xA3F JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xA14 JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xA3F JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xA22 JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP POP POP POP PUSH2 0x1B37 JUMP JUMPDEST SWAP2 POP PUSH2 0xB71 JUMP JUMPDEST PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD PUSH1 0x40 MLOAD DUP1 DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xB4A JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xB1F JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xB4A JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xB2D JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP SWAP2 POP POP PUSH1 0x0 PUSH1 0x40 MLOAD DUP1 DUP4 SUB DUP2 DUP6 DUP8 PUSH2 0x8502 GAS SUB CALL SWAP3 POP POP POP ISZERO ISZERO PUSH2 0xB70 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST JUMPDEST PUSH32 0xE3A3A4111A84DF27D76B68DC721E65C7711605EA5EEE4AFD3A9C58195217365C CALLER DUP6 PUSH2 0x108 PUSH1 0x0 DUP9 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP10 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH2 0x108 PUSH1 0x0 DUP11 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP8 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD DUP6 DUP2 MSTORE PUSH1 0x20 ADD DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP5 DUP2 DUP2 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xD47 JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xD1C JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xD47 JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xD2A JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD SWAP1 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 PUSH2 0xDB7 SWAP2 SWAP1 PUSH2 0x1BE6 JUMP JUMPDEST POP POP PUSH1 0x1 SWAP3 POP PUSH2 0xDC3 JUMP JUMPDEST JUMPDEST JUMPDEST JUMPDEST POP POP SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0xDF3 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0xE01 JUMPI DUP2 PUSH1 0x2 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0xE13 CALLER PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1273 JUMPI PUSH1 0x0 DUP5 DUP5 SWAP1 POP EQ DUP1 ISZERO PUSH2 0xE30 JUMPI POP PUSH2 0xE2F DUP6 PUSH2 0x1B51 JUMP JUMPDEST JUMPDEST DUP1 PUSH2 0xE3D JUMPI POP PUSH1 0x1 PUSH1 0x0 SLOAD EQ JUMPDEST ISZERO PUSH2 0xFED JUMPI PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO PUSH2 0xEA4 JUMPI PUSH2 0xE9D DUP6 DUP6 DUP6 DUP1 DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP4 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP POP POP POP POP PUSH2 0x1B37 JUMP JUMPDEST SWAP1 POP PUSH2 0xEF3 JUMP JUMPDEST DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP6 DUP6 DUP6 PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x0 PUSH1 0x40 MLOAD DUP1 DUP4 SUB DUP2 DUP6 DUP8 PUSH2 0x8502 GAS SUB CALL SWAP3 POP POP POP ISZERO ISZERO PUSH2 0xEF2 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST JUMPDEST PUSH32 0x9738CD1A8777C86B011F7B01D87D484217DC6AB5154A9D41EDA5D14AF8CAF292 CALLER DUP7 DUP9 DUP8 DUP8 DUP7 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 DUP2 MSTORE PUSH1 0x20 ADD DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP6 DUP6 DUP3 DUP2 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH2 0x1271 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE NUMBER PUSH1 0x40 MLOAD DUP1 DUP5 DUP5 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP4 POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 SWAP2 POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ DUP1 ISZERO PUSH2 0x1099 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD EQ JUMPDEST DUP1 ISZERO PUSH2 0x10D8 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 POP EQ JUMPDEST ISZERO PUSH2 0x118F JUMPI DUP6 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR SWAP1 SSTORE POP DUP5 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD DUP2 SWAP1 SSTORE POP DUP4 DUP4 PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD SWAP2 SWAP1 PUSH2 0x118D SWAP3 SWAP2 SWAP1 PUSH2 0x1C2E JUMP JUMPDEST POP JUMPDEST PUSH2 0x1198 DUP3 PUSH2 0x82F JUMP JUMPDEST ISZERO ISZERO PUSH2 0x1270 JUMPI PUSH32 0x1733CBB53659D713B79580F79F3F9FF215F78A7C7AA45890F3B89FC5CDDFBF32 DUP3 CALLER DUP8 DUP10 DUP9 DUP9 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP6 DUP2 MSTORE PUSH1 0x20 ADD DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP5 DUP5 DUP3 DUP2 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST JUMPDEST JUMPDEST POP SWAP5 SWAP4 POP POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 CALLER PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP3 POP PUSH1 0x0 DUP4 EQ ISZERO PUSH2 0x12BE JUMPI PUSH2 0x138C JUMP JUMPDEST DUP3 PUSH1 0x2 EXP SWAP2 POP PUSH2 0x106 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP1 POP PUSH1 0x0 DUP3 DUP3 PUSH1 0x1 ADD SLOAD AND GT ISZERO PUSH2 0x138B JUMPI DUP1 PUSH1 0x0 ADD PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 ADD SWAP2 SWAP1 POP SSTORE POP DUP2 DUP2 PUSH1 0x1 ADD PUSH1 0x0 DUP3 DUP3 SLOAD SUB SWAP3 POP POP DUP2 SWAP1 SSTORE POP PUSH32 0xC7FB647E59B18047309AA15AAD418E5D7CA96D173AD704F1031A2C3D7591734B CALLER DUP6 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST POP POP POP POP JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x13B9 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x1415 JUMPI PUSH1 0x1 SLOAD DUP3 GT ISZERO PUSH2 0x13CD JUMPI PUSH2 0x1414 JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP PUSH2 0x13DC PUSH2 0x1890 JUMP JUMPDEST PUSH32 0xACBDB084C721332AC59F9B8E392196C9EB0E4932862DA8EB9BEAF0DAD4F550DA DUP3 PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x106 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP3 POP PUSH2 0x105 PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x147F JUMPI PUSH1 0x0 SWAP4 POP PUSH2 0x1493 JUMP JUMPDEST DUP2 PUSH1 0x2 EXP SWAP1 POP PUSH1 0x0 DUP2 DUP5 PUSH1 0x1 ADD SLOAD AND EQ ISZERO SWAP4 POP JUMPDEST POP POP POP SWAP3 SWAP2 POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 DUP4 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x14B1 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD SWAP1 POP JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x14E8 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x166B JUMPI PUSH2 0x14F6 DUP4 PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1500 JUMPI PUSH2 0x166A JUMP JUMPDEST PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x153B JUMPI PUSH2 0x166A JUMP JUMPDEST PUSH2 0x1543 PUSH2 0x1890 JUMP JUMPDEST DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP4 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x156A JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP DUP2 PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH32 0xB532073B38C83145E3E5135377A08BF9AAB55BC0FD7C1179CD4FB995D2A5159C DUP5 DUP5 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP POP POP JUMP JUMPDEST PUSH1 0x2 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 CALLER PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP3 POP PUSH1 0x0 DUP4 EQ ISZERO PUSH2 0x16BB JUMPI PUSH2 0x1888 JUMP JUMPDEST PUSH2 0x106 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP2 POP PUSH1 0x0 DUP3 PUSH1 0x0 ADD SLOAD EQ ISZERO PUSH2 0x1745 JUMPI PUSH1 0x0 SLOAD DUP3 PUSH1 0x0 ADD DUP2 SWAP1 SSTORE POP PUSH1 0x0 DUP3 PUSH1 0x1 ADD DUP2 SWAP1 SSTORE POP PUSH2 0x107 DUP1 SLOAD DUP1 SWAP2 SWAP1 PUSH1 0x1 ADD PUSH2 0x1710 SWAP2 SWAP1 PUSH2 0x1CAE JUMP JUMPDEST DUP3 PUSH1 0x2 ADD DUP2 SWAP1 SSTORE POP DUP5 PUSH2 0x107 DUP4 PUSH1 0x2 ADD SLOAD DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x172D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP DUP2 PUSH1 0x0 NOT AND SWAP1 SSTORE POP JUMPDEST DUP3 PUSH1 0x2 EXP SWAP1 POP PUSH1 0x0 DUP2 DUP4 PUSH1 0x1 ADD SLOAD AND EQ ISZERO PUSH2 0x1887 JUMPI PUSH32 0xE1C52DC63B719ADE82E8BEA94CC41A0D5D28E4AAF536ADB5E9CCCC9FF8C1AEDA CALLER DUP7 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH1 0x1 DUP3 PUSH1 0x0 ADD SLOAD GT ISZERO ISZERO PUSH2 0x185E JUMPI PUSH2 0x107 PUSH2 0x106 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD SLOAD DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x180A JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP PUSH1 0x0 SWAP1 SSTORE PUSH2 0x106 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE POP POP PUSH1 0x1 SWAP4 POP PUSH2 0x1888 JUMP JUMPDEST DUP2 PUSH1 0x0 ADD PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 SWAP1 SUB SWAP2 SWAP1 POP SSTORE POP DUP1 DUP3 PUSH1 0x1 ADD PUSH1 0x0 DUP3 DUP3 SLOAD OR SWAP3 POP POP DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP POP POP SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0x107 DUP1 SLOAD SWAP1 POP SWAP2 POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP2 DUP2 LT ISZERO PUSH2 0x19BC JUMPI PUSH2 0x108 PUSH1 0x0 PUSH2 0x107 DUP4 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x18BF JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD SWAP1 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 PUSH2 0x1926 SWAP2 SWAP1 PUSH2 0x1BE6 JUMP JUMPDEST POP POP PUSH1 0x0 PUSH1 0x1 MUL PUSH2 0x107 DUP3 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x193D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND EQ ISZERO ISZERO PUSH2 0x19B0 JUMPI PUSH2 0x106 PUSH1 0x0 PUSH2 0x107 DUP4 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x196D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE POP POP JUMPDEST JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH2 0x18A2 JUMP JUMPDEST PUSH2 0x107 PUSH1 0x0 PUSH2 0x19CB SWAP2 SWAP1 PUSH2 0x1CDA JUMP JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SWAP1 POP JUMPDEST PUSH1 0x1 SLOAD DUP2 LT ISZERO PUSH2 0x1B33 JUMPI JUMPDEST PUSH1 0x1 SLOAD DUP2 LT DUP1 ISZERO PUSH2 0x1A09 JUMPI POP PUSH1 0x0 PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A00 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ ISZERO JUMPDEST ISZERO PUSH2 0x1A1B JUMPI DUP1 DUP1 PUSH1 0x1 ADD SWAP2 POP POP PUSH2 0x19E2 JUMP JUMPDEST JUMPDEST PUSH1 0x1 PUSH1 0x1 SLOAD GT DUP1 ISZERO PUSH2 0x1A45 JUMPI POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A3D JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ JUMPDEST ISZERO PUSH2 0x1A62 JUMPI PUSH1 0x1 PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 SWAP1 SUB SWAP2 SWAP1 POP SSTORE POP PUSH2 0x1A1C JUMP JUMPDEST PUSH1 0x1 SLOAD DUP2 LT DUP1 ISZERO PUSH2 0x1A8B JUMPI POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A82 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ ISZERO JUMPDEST DUP1 ISZERO PUSH2 0x1AAC JUMPI POP PUSH1 0x0 PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AA4 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ JUMPDEST ISZERO PUSH2 0x1B2E JUMPI PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AC3 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AD9 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH2 0x105 PUSH1 0x0 PUSH1 0x5 DUP5 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AF8 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1B24 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP JUMPDEST PUSH2 0x19D7 JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 DUP2 MLOAD PUSH1 0x20 DUP4 ADD DUP5 CREATE SWAP1 POP DUP1 EXTCODESIZE ISZERO PUSH2 0x0 JUMPI JUMPDEST SWAP3 SWAP2 POP POP JUMP JUMPDEST PUSH1 0x0 PUSH2 0x1B5C CALLER PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1BC9 JUMPI PUSH1 0x4 SLOAD PUSH2 0x1B6C PUSH2 0x1BCF JUMP JUMPDEST GT ISZERO PUSH2 0x1B89 JUMPI PUSH1 0x0 PUSH1 0x3 DUP2 SWAP1 SSTORE POP PUSH2 0x1B82 PUSH2 0x1BCF JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST PUSH1 0x3 SLOAD DUP3 PUSH1 0x3 SLOAD ADD LT ISZERO DUP1 ISZERO PUSH2 0x1BA5 JUMPI POP PUSH1 0x2 SLOAD DUP3 PUSH1 0x3 SLOAD ADD GT ISZERO JUMPDEST ISZERO PUSH2 0x1BC3 JUMPI DUP2 PUSH1 0x3 PUSH1 0x0 DUP3 DUP3 SLOAD ADD SWAP3 POP POP DUP2 SWAP1 SSTORE POP PUSH1 0x1 SWAP1 POP PUSH2 0x1BC8 JUMP JUMPDEST PUSH1 0x0 SWAP1 POP JUMPDEST JUMPDEST JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH3 0x15180 TIMESTAMP DUP2 ISZERO ISZERO PUSH2 0x1BDF JUMPI INVALID JUMPDEST DIV SWAP1 POP JUMPDEST SWAP1 JUMP JUMPDEST POP DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV PUSH1 0x0 DUP3 SSTORE DUP1 PUSH1 0x1F LT PUSH2 0x1C0C JUMPI POP PUSH2 0x1C2B JUMP JUMPDEST PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 DUP2 ADD SWAP1 PUSH2 0x1C2A SWAP2 SWAP1 PUSH2 0x1CFC JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV DUP2 ADD SWAP3 DUP3 PUSH1 0x1F LT PUSH2 0x1C6F JUMPI DUP1 CALLDATALOAD PUSH1 0xFF NOT AND DUP4 DUP1 ADD OR DUP6 SSTORE PUSH2 0x1C9D JUMP JUMPDEST DUP3 DUP1 ADD PUSH1 0x1 ADD DUP6 SSTORE DUP3 ISZERO PUSH2 0x1C9D JUMPI SWAP2 DUP3 ADD JUMPDEST DUP3 DUP2 GT ISZERO PUSH2 0x1C9C JUMPI DUP3 CALLDATALOAD DUP3 SSTORE SWAP2 PUSH1 0x20 ADD SWAP2 SWAP1 PUSH1 0x1 ADD SWAP1 PUSH2 0x1C81 JUMP JUMPDEST JUMPDEST POP SWAP1 POP PUSH2 0x1CAA SWAP2 SWAP1 PUSH2 0x1CFC JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST DUP2 SLOAD DUP2 DUP4 SSTORE DUP2 DUP2 ISZERO GT PUSH2 0x1CD5 JUMPI DUP2 DUP4 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP2 DUP3 ADD SWAP2 ADD PUSH2 0x1CD4 SWAP2 SWAP1 PUSH2 0x1D21 JUMP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST POP DUP1 SLOAD PUSH1 0x0 DUP3 SSTORE SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 DUP2 ADD SWAP1 PUSH2 0x1CF8 SWAP2 SWAP1 PUSH2 0x1D21 JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH2 0x1D1E SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x1D1A JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x1D02 JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH2 0x1D43 SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x1D3F JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x1D27 JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1D57 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH2 0x1D60 DUP2 PUSH2 0x1D71 JUMP JUMPDEST PUSH2 0x1D6A DUP4 DUP4 PUSH2 0x1D9C JUMP JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1D82 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP1 PUSH1 0x2 DUP2 SWAP1 SSTORE POP PUSH2 0x1D91 PUSH2 0x1BCF JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1DAF JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH1 0x0 DUP3 GT ISZERO ISZERO PUSH2 0x1DBF JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP2 DUP4 MLOAD LT ISZERO ISZERO ISZERO PUSH2 0x1DD0 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP3 MLOAD PUSH1 0x1 DUP2 SWAP1 SSTORE POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP3 MLOAD DUP2 LT ISZERO PUSH2 0x1E85 JUMPI DUP3 DUP2 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH2 0x1DF4 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP3 PUSH1 0x1 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1E27 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH1 0x1 ADD PUSH2 0x105 PUSH1 0x0 DUP6 DUP5 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH2 0x1E47 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH2 0x1DDD JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP POP POP JUMP STOP LOG1 PUSH6 0x627A7A723058 SHA3 AND DUP9 SWAP16 SMOD BLOCKHASH CREATE PUSH20 0xD397F9D00B0D19900FB050B957E3E2942F861085 0xbe 0xb9 0xba 0xab XOR STOP 0x29 ", "sourceMap": "2715:10853:0:-;;;3523:112;;;;;;;3552:18;3574:8;:27;;;;;;;;;;;:::i;:::-;;;;;;;;;;;3596:3;3574:27;;;;;;;;;;;;;;;;;;;;;;;3605:26;3616:8;3605:26;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;3626:1;3629;3605:10;;;;;:26;;;:::i;:::-;3523:112;;2715:10853;;7697:168;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;7800:23;7813:9;7800:12;;;;;:23;;;:::i;:::-;7827:34;7842:7;7851:9;7827:14;;;;;:34;;;:::i;:::-;7595:1;7697:168;;;;:::o;6966:115::-;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;7048:6;7033:12;:21;;;;7070:7;:5;;;;;:7;;;:::i;:::-;7058:9;:19;;;;7595:1;6966:115;;:::o;3977:349::-;4171:6;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;4088:1;4076:9;:13;4068:22;;;;;;;;4120:9;4102:7;:14;:27;;4094:36;;;;;;;;4148:7;:14;4134:11;:28;;;;4180:1;4171:10;;4166:131;4187:7;:14;4183:1;:18;4166:131;;;4238:7;4246:1;4238:10;;;;;;;;;;;;;;;;;;4233:16;;4215:8;4228:1;4224;:5;4215:15;;;;;;;;;;;;:34;;;;;4291:1;4287;:5;4254:12;:30;4272:7;4280:1;4272:10;;;;;;;;;;;;;;;;;;4267:16;;4254:30;;;;;;;;;;;:38;;;;4166:131;4203:3;;;;;4166:131;;;4313:9;4300:10;:22;;;;7595:1;3977:349;;;;:::o;12529:73::-;12572:4;12593:6;12587:3;:12;;;;;;;;12580:19;;12529:73;;:::o;2715:10853::-;;;;;;;;;;;;;;;;;;;;;;;;;;;;:::i;:::-;;;;;:::o;:::-;;;;;;;;;;;;;;;;;;;;;;;;;;;:::o;:::-;;;;;;;", "linkReferences": {} } ``` To verify the byte-code above, a patched version is deployed at [`0x21C9E434c669c4d73f55215A6F2130A185E127AC`](https://etherscan.io/address/0x21C9E434c669c4d73f55215A6F2130A185E127AC#code) to be reviewed. The compiler settings used can be extracted from the following meta-data: ```json {"compiler":{"version":"0.4.10+commit.f0d539ae"},"language":"Solidity","output":{"abi":[{"constant":false,"inputs":[{"name":"_owner","type":"address"}],"name":"removeOwner","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[{"name":"_addr","type":"address"}],"name":"isOwner","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"m_numOwners","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"m_lastDay","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"resetSpentToday","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"m_spentToday","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_owner","type":"address"}],"name":"addOwner","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"m_required","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_h","type":"bytes32"}],"name":"confirm","outputs":[{"name":"o_success","type":"bool"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_newLimit","type":"uint256"}],"name":"setDailyLimit","outputs":[],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_value","type":"uint256"},{"name":"_data","type":"bytes"}],"name":"execute","outputs":[{"name":"o_hash","type":"bytes32"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_operation","type":"bytes32"}],"name":"revoke","outputs":[],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_newRequired","type":"uint256"}],"name":"changeRequirement","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[{"name":"_operation","type":"bytes32"},{"name":"_owner","type":"address"}],"name":"hasConfirmed","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[{"name":"ownerIndex","type":"uint256"}],"name":"getOwner","outputs":[{"name":"","type":"address"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_from","type":"address"},{"name":"_to","type":"address"}],"name":"changeOwner","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"m_dailyLimit","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"inputs":[],"payable":false,"type":"constructor"},{"payable":true,"type":"fallback"},{"anonymous":false,"inputs":[{"indexed":false,"name":"owner","type":"address"},{"indexed":false,"name":"operation","type":"bytes32"}],"name":"Confirmation","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"owner","type":"address"},{"indexed":false,"name":"operation","type":"bytes32"}],"name":"Revoke","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"oldOwner","type":"address"},{"indexed":false,"name":"newOwner","type":"address"}],"name":"OwnerChanged","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"newOwner","type":"address"}],"name":"OwnerAdded","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"oldOwner","type":"address"}],"name":"OwnerRemoved","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"newRequirement","type":"uint256"}],"name":"RequirementChanged","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"_from","type":"address"},{"indexed":false,"name":"value","type":"uint256"}],"name":"Deposit","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"owner","type":"address"},{"indexed":false,"name":"value","type":"uint256"},{"indexed":false,"name":"to","type":"address"},{"indexed":false,"name":"data","type":"bytes"},{"indexed":false,"name":"created","type":"address"}],"name":"SingleTransact","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"owner","type":"address"},{"indexed":false,"name":"operation","type":"bytes32"},{"indexed":false,"name":"value","type":"uint256"},{"indexed":false,"name":"to","type":"address"},{"indexed":false,"name":"data","type":"bytes"},{"indexed":false,"name":"created","type":"address"}],"name":"MultiTransact","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"operation","type":"bytes32"},{"indexed":false,"name":"initiator","type":"address"},{"indexed":false,"name":"value","type":"uint256"},{"indexed":false,"name":"to","type":"address"},{"indexed":false,"name":"data","type":"bytes"}],"name":"ConfirmationNeeded","type":"event"}],"devdoc":{"methods":{}},"userdoc":{"methods":{}}},"settings":{"compilationTarget":{"browser/WalletLibrary.sol":"WalletLibrary"},"libraries":{},"optimizer":{"enabled":false,"runs":200},"remappings":[]},"sources":{"browser/WalletLibrary.sol":{"keccak256":"0xf72fcdc85e15f93172878ca6a61fb81604d1052e9e724bc3896d65b3b4ab1bb0","urls":["bzzr://009bd59bd78f59804eaffb6111d341caea58888f8e5b5f75aebdf009fc6136c0"]}},"version":1} ``` The differences to the originally deployed contract code can be reviewed at: * [parity-contracts/0x863df6bfa4#2](https://github.com/parity-contracts/0x863df6bfa4/pull/2): Remove the `selfdestruct()` * [parity-contracts/0x863df6bfa4#3](https://github.com/parity-contracts/0x863df6bfa4/pull/3): Initialize the library owner to `0x0` The following sections propose two equivalent specifications, 999a and 999b, which technically achieve the same results. To implement this proposal only one of them has to be applied. ### Direct State Transition via Bytecode (999a) At `CNSTNTNPL_FORK_BLKNUM`, directly recreate the account `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4` with the following parameters: * Nonce: `0x1` * Code: ``` 0x606060405236156100ef576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063173825d91461016d5780632f54bf6e146101a35780634123cb6b146101f157806352375093146102175780635c52c2f51461023d578063659010e71461024f5780637065cb4814610275578063746c9171146102ab578063797af627146102d1578063b20d30a91461030d578063b61d27f61461032d578063b75c7dc61461039c578063ba51a6df146103c0578063c2cf7326146103e0578063c41a360a1461043b578063f00d4b5d1461049b578063f1736d86146104f0575b61016b5b6000341115610168577fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c3334604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a15b5b565b005b341561017557fe5b6101a1600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610516565b005b34156101ab57fe5b6101d7600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610659565b604051808215151515815260200191505060405180910390f35b34156101f957fe5b610201610691565b6040518082815260200191505060405180910390f35b341561021f57fe5b610227610697565b6040518082815260200191505060405180910390f35b341561024557fe5b61024d61069d565b005b341561025757fe5b61025f6106d7565b6040518082815260200191505060405180910390f35b341561027d57fe5b6102a9600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506106dd565b005b34156102b357fe5b6102bb610829565b6040518082815260200191505060405180910390f35b34156102d957fe5b6102f360048080356000191690602001909190505061082f565b604051808215151515815260200191505060405180910390f35b341561031557fe5b61032b6004808035906020019091905050610dcc565b005b341561033557fe5b61037e600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919080359060200190919080359060200190820180359060200191909192905050610e06565b60405180826000191660001916815260200191505060405180910390f35b34156103a457fe5b6103be60048080356000191690602001909190505061127d565b005b34156103c857fe5b6103de6004808035906020019091905050611392565b005b34156103e857fe5b61042160048080356000191690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190505061141a565b604051808215151515815260200191505060405180910390f35b341561044357fe5b610459600480803590602001909190505061149c565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34156104a357fe5b6104ee600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506114bf565b005b34156104f857fe5b610500611672565b6040518082815260200191505060405180910390f35b600060003660405180838380828437820191505092505050604051809103902061053f81611678565b156106535761010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561057f57610652565b600160015403600054111561059357610652565b6000600583610100811015156105a557fe5b0160005b5081905550600061010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506105e6611890565b6105ee6119d0565b7f58619076adf5bb0943d100ef88d52d7c3fd691b19d3a9071b555b651fbf418da83604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b505050565b6000600061010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541190505b919050565b60015481565b60045481565b6000366040518083838082843782019150509250505060405180910390206106c481611678565b156106d35760006003819055505b5b5b50565b60035481565b60003660405180838380828437820191505092505050604051809103902061070481611678565b156108245761071282610659565b1561071c57610823565b610724611890565b60fa600154101515610739576107386119d0565b5b60fa60015410151561074a57610823565b6001600081548092919060010191905055508173ffffffffffffffffffffffffffffffffffffffff1660056001546101008110151561078557fe5b0160005b508190555060015461010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507f994a936646fe87ffe4f1e469d3d6aa417d6b855598397f323de5b449f765f0c382604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b5050565b60005481565b600060008261083d81611678565b15610dc45760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415806108c757506000610108600086600019166000191681526020019081526020016000206001015414155b80610906575060006101086000866000191660001916815260200190815260200160002060020180546001816001161561010002031660029004905014155b15610dc25760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415610a5057610a496101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610a3f5780601f10610a1457610100808354040283529160200191610a3f565b820191906000526020600020905b815481529060010190602001808311610a2257829003601f168201915b5050505050611b37565b9150610b71565b6101086000856000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002016040518082805460018160011615610100020316600290048015610b4a5780601f10610b1f57610100808354040283529160200191610b4a565b820191906000526020600020905b815481529060010190602001808311610b2d57829003601f168201915b505091505060006040518083038185876185025a03f1925050501515610b705760006000fd5b5b7fe3a3a4111a84df27d76b68dc721e65c7711605ea5eee4afd3a9c58195217365c338561010860008860001916600019168152602001908152602001600020600101546101086000896000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1661010860008a6000191660001916815260200190815260200160002060020187604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200186600019166000191681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001828103825284818154600181600116156101000203166002900481526020019150805460018160011615610100020316600290048015610d475780601f10610d1c57610100808354040283529160200191610d47565b820191906000526020600020905b815481529060010190602001808311610d2a57829003601f168201915b505097505050505050505060405180910390a16101086000856000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff02191690556001820160009055600282016000610db79190611be6565b505060019250610dc3565b5b5b5b5050919050565b600036604051808383808284378201915050925050506040518091039020610df381611678565b15610e0157816002819055505b5b5b5050565b60006000610e1333610659565b1561127357600084849050148015610e305750610e2f85611b51565b5b80610e3d57506001600054145b15610fed5760008673ffffffffffffffffffffffffffffffffffffffff161415610ea457610e9d8585858080601f016020809104026020016040519081016040528093929190818152602001838380828437820191505050505050611b37565b9050610ef3565b8573ffffffffffffffffffffffffffffffffffffffff168585856040518083838082843782019150509250505060006040518083038185876185025a03f1925050501515610ef25760006000fd5b5b7f9738cd1a8777c86b011f7b01d87d484217dc6ab5154a9d41eda5d14af8caf292338688878786604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018681526020018573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281038252858582818152602001925080828437820191505097505050505050505060405180910390a1611271565b6000364360405180848480828437820191505082815260200193505050506040518091039020915060006101086000846000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16148015611099575060006101086000846000191660001916815260200190815260200160002060010154145b80156110d85750600061010860008460001916600019168152602001908152602001600020600201805460018160011615610100020316600290049050145b1561118f57856101086000846000191660001916815260200190815260200160002060000160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550846101086000846000191660001916815260200190815260200160002060010181905550838361010860008560001916600019168152602001908152602001600020600201919061118d929190611c2e565b505b6111988261082f565b1515611270577f1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf328233878988886040518087600019166000191681526020018673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018281038252848482818152602001925080828437820191505097505050505050505060405180910390a15b5b5b5b5b50949350505050565b60006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156112be5761138c565b8260020a9150610106600085600019166000191681526020019081526020016000209050600082826001015416111561138b5780600001600081548092919060010191905055508181600101600082825403925050819055507fc7fb647e59b18047309aa15aad418e5d7ca96d173ad704f1031a2c3d7591734b3385604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a15b5b50505050565b6000366040518083838082843782019150509250505060405180910390206113b981611678565b15611415576001548211156113cd57611414565b816000819055506113dc611890565b7facbdb084c721332ac59f9b8e392196c9eb0e4932862da8eb9beaf0dad4f550da826040518082815260200191505060405180910390a15b5b5b5050565b600060006000600061010660008760001916600019168152602001908152602001600020925061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561147f5760009350611493565b8160020a9050600081846001015416141593505b50505092915050565b6000600560018301610100811015156114b157fe5b0160005b505490505b919050565b60006000366040518083838082843782019150509250505060405180910390206114e881611678565b1561166b576114f683610659565b156115005761166a565b61010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561153b5761166a565b611543611890565b8273ffffffffffffffffffffffffffffffffffffffff166005836101008110151561156a57fe5b0160005b5081905550600061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508161010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507fb532073b38c83145e3e5135377a08bf9aab55bc0fd7c1179cd4fb995d2a5159c8484604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019250505060405180910390a15b5b5b50505050565b60025481565b600060006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156116bb57611888565b6101066000866000191660001916815260200190815260200160002091506000826000015414156117455760005482600001819055506000826001018190555061010780548091906001016117109190611cae565b826002018190555084610107836002015481548110151561172d57fe5b906000526020600020900160005b5081600019169055505b8260020a90506000818360010154161415611887577fe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda3386604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a16001826000015411151561185e57610107610106600087600019166000191681526020019081526020016000206002015481548110151561180a57fe5b906000526020600020900160005b5060009055610106600086600019166000191681526020019081526020016000206000600082016000905560018201600090556002820160009055505060019350611888565b8160000160008154809291906001900391905055508082600101600082825417925050819055505b5b5b505050919050565b60006000610107805490509150600090505b818110156119bc576101086000610107838154811015156118bf57fe5b906000526020600020900160005b50546000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560018201600090556002820160006119269190611be6565b505060006001026101078281548110151561193d57fe5b906000526020600020900160005b5054600019161415156119b05761010660006101078381548110151561196d57fe5b906000526020600020900160005b505460001916600019168152602001908152602001600020600060008201600090556001820160009055600282016000905550505b5b8060010190506118a2565b61010760006119cb9190611cda565b5b5050565b6000600190505b600154811015611b33575b60015481108015611a095750600060058261010081101515611a0057fe5b0160005b505414155b15611a1b5780806001019150506119e2565b5b6001600154118015611a4557506000600560015461010081101515611a3d57fe5b0160005b5054145b15611a625760016000815480929190600190039190505550611a1c565b60015481108015611a8b57506000600560015461010081101515611a8257fe5b0160005b505414155b8015611aac5750600060058261010081101515611aa457fe5b0160005b5054145b15611b2e57600560015461010081101515611ac357fe5b0160005b505460058261010081101515611ad957fe5b0160005b508190555080610105600060058461010081101515611af857fe5b0160005b50548152602001908152602001600020819055506000600560015461010081101515611b2457fe5b0160005b50819055505b6119d7565b5b50565b600081516020830184f09050803b15610000575b92915050565b6000611b5c33610659565b15611bc957600454611b6c611bcf565b1115611b89576000600381905550611b82611bcf565b6004819055505b600354826003540110158015611ba55750600254826003540111155b15611bc3578160036000828254019250508190555060019050611bc8565b600090505b5b5b919050565b60006201518042811515611bdf57fe5b0490505b90565b50805460018160011615610100020316600290046000825580601f10611c0c5750611c2b565b601f016020900490600052602060002090810190611c2a9190611cfc565b5b50565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f10611c6f57803560ff1916838001178555611c9d565b82800160010185558215611c9d579182015b82811115611c9c578235825591602001919060010190611c81565b5b509050611caa9190611cfc565b5090565b815481835581811511611cd557818360005260206000209182019101611cd49190611d21565b5b505050565b5080546000825590600052602060002090810190611cf89190611d21565b5b50565b611d1e91905b80821115611d1a576000816000905550600101611d02565b5090565b90565b611d4391905b80821115611d3f576000816000905550600101611d27565b5090565b90565b60006001541115611d575760006000fd5b611d6081611d71565b611d6a8383611d9c565b5b5b505050565b60006001541115611d825760006000fd5b80600281905550611d91611bcf565b6004819055505b5b50565b600060006001541115611daf5760006000fd5b600082111515611dbf5760006000fd5b81835110151515611dd05760006000fd5b8251600181905550600090505b8251811015611e85578281815181101515611df457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff1660058260010161010081101515611e2757fe5b0160005b50819055508060010161010560008584815181101515611e4757fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b806001019050611ddd565b816000819055505b5b5050505600a165627a7a7230582084feb3505964efa62a6ffa78d913a175fe7bc168dd50067d25b1d5ddb6d10a1e0029 ``` * Storage: * `0x0000000000000000000000000000000000000000000000000000000000000000`: `0x0000000000000000000000000000000000000000000000000000000000000001` * `0x0000000000000000000000000000000000000000000000000000000000000001`: `0x0000000000000000000000000000000000000000000000000000000000000001` * `0x0000000000000000000000000000000000000000000000000000000000000004`: `0x00000000000000000000000000000000000000000000000000000000000044e1` * `0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d`: `0x0000000000000000000000000000000000000000000000000000000000000001` The balance of the account shall be left unchanged. ### Alternate Specification via Codehash (999b) At `CNSTNTNPL_FORK_BLKNUM`, directly recreate the account `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4` with the following parameters: * Nonce: `0x1` * Storage: * `0x0000000000000000000000000000000000000000000000000000000000000000`: `0x0000000000000000000000000000000000000000000000000000000000000001` * `0x0000000000000000000000000000000000000000000000000000000000000001`: `0x0000000000000000000000000000000000000000000000000000000000000001` * `0x0000000000000000000000000000000000000000000000000000000000000004`: `0x00000000000000000000000000000000000000000000000000000000000044e1` * `0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d`: `0x0000000000000000000000000000000000000000000000000000000000000001` In addition, the codehash at that address shall be replaced by the codehash at address `0x21C9E434c669c4d73f55215A6F2130A185E127AC`. The codehash is `0x6209d55547da7b035d54ef8d73275e863d3072b91da6ace1614fa6381f4e2c09`. The balance of the account shall be left unchanged. ## Rationale The design decision to restore the `WalletLibrary` contract code in a single state transition was made after lengthy discussions of [alternate proposals](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) that explored different ways to improve the Ethereum protocol to allow contract revivals by adding different built-in contracts. It was eventually concluded that all of these proposals changing the EVM semantics around self-destructed contracts were introducing unwanted side-effects and [potential risks](https://medium.com/@weka/on-paritys-proposed-changes-to-selfdestruct-behaviour-c3f0e5bc0f49) to the existing smart-contract ecosystem on the Ethereum platform. The total supply of Ether is neither changed nor does this proposal require the transfer of any tokens or assets including Ether. It is assumed that this change is aligned with the interests both of (A) Parity Technologies that intended to provide a smart-contracts library for multi-signature wallets to last forever for its users and (B) the users of the multi-signature wallets that meant to safely store their assets in a contract accessible any time they desire. Lastly, the client-side implementation cost of this proposal is estimated to be low. A sample implementation will be attached and linked in the following sections. ## Backwards Compatibility This proposal introduces backwards incompatibilities in the state of the contract at `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4`. The Ethereum protocol does not allow the restoration of self-destructed contracts. To implement this on the Ethereum blockchain, it is recommended to add the necessary state transition in a future hard-fork at a well-defined block number, e.g., `CNSTNTNPL_FORK_BLKNUM` for the Constantinople milestone which is supposed to be the next scheduled hard-fork on the Ethereum road-map. ## Implementation A proof-of-concept implementation is available for the Parity client on branch [`a5-eip999-poc`](https://github.com/paritytech/parity/compare/a5-eip999-poc) ([#8406](https://github.com/paritytech/parity/pull/8406)). A sample chain configuration for Parity can be found at the same branch in [`multisig_test.json`](https://github.com/paritytech/parity/blob/891e633021eec78dd62104bf5a99af50f66b06c7/ethcore/res/ethereum/multisig_test.json#L38-L51) describing the state change as specified above. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 04 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-999 https://eips.ethereum.org/EIPS/eip-999 Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c Standards Track/Core https://github.com/andywesley/EIPs/issues/1 ## Simple Summary This document proposes to improve the uniformity of ether distribution between wallet address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and wallet address `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` which are currently experiencing a significant non-uniformity. ## Abstract As of the date of this EIP, the difference in balance between address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and address `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` is far from equitable or uniform, with the former having more than 365,000 ether more than the latter. The distribution of ether between these two addresses must be improved in order to protect the Ethereum economy from centralized control. This will be accomplished by transferring 100,000 ether from the former address to the latter. This is a properly motivated improvement in keeping with the core Ethereum philosophy of decentralization. ## Motivation This proposal is necessary because the Ethereum protocol does not allow the owner of an address which does not own an equitable amount of ether to claim their share of ether from an address which owns a dangerously centralized quantity. Rather than proposing an overly complicated generic mechanism for any user to claim ether to which they believe they are equitably entitled, this proposal will take the simple route of a one-time transfer of 100,000 ether from `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` to `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c`. This avoids duplicating the effort of other proposals and provides a net improvement to the Ethereum project and community. ## Specification The balance of `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` will be decreased by 100,000 ether. The balance of `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` will be increased by 100,000 ether. No net change in the amount of extant ether will occur unless at the time of implementation the former address does not contain sufficient ether for such a deduction. ## Rationale The value 100,000 was chosen after careful technically sound analysis of various economic theories developed over the past century. In spite of the fact that it is a convenient round number, it is actually the exact output of a complex statistical process iterated to determine the optimal distribution of ether between these addresses. ## Backwards Compatibility Clients that fail to implement this change will not be aware of the correct balances for these addresses. This will create a hard fork. The implementation of this change consistently among all clients as intended by the proposal process will be sufficient to ensure that backwards compatibility is not a concern. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 18 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1010 https://eips.ethereum.org/EIPS/eip-1010 Hybrid Casper FFG Standards Track/Core https://github.com/djrtwo/EIPs/issues/5 ## Simple Summary Specification of the first step to transition Ethereum main net from Proof of Work (PoW) to Proof of Stake (PoS). The resulting consensus model is a PoW/PoS hybrid. ## Abstract This EIP specifies a hybrid PoW/PoS consensus model for Ethereum main net. Existing PoW mechanics are used for new block creation, and a novel PoS mechanism called Casper the Friendly Finality Gadget (FFG) is layered on top using a smart contract. Through the use of Ether deposits, slashing conditions, and a modified fork choice, FFG allows the underlying PoW blockchain to be finalized. As network security is greatly shifted from PoW to PoS, PoW block rewards are reduced. This EIP does not contain safety and liveness proofs or validator implementation details, but these can be found in the [Casper FFG paper](https://arxiv.org/abs/1710.09437) and [Validator Implementation Guide](https://github.com/ethereum/casper/blob/master/VALIDATOR_GUIDE.md) respectively. ## Glossary * **epoch**: The span of blocks between checkpoints. Epochs are numbered starting at the hybrid casper fork, incrementing by one at the start of each epoch. * **finality**: The point at which a block has been decided upon by a client to _never_ revert. Proof of Work does not have the concept of finality, only of further deep block confirmations. * **checkpoint**: The block/hash under consideration for finality for a given epoch. This block is the _last_ block of the previous epoch. Rather than dealing with every block, Casper FFG only considers checkpoints for finalization. When a checkpoint is explicitly finalized, all ancestor blocks of the checkpoint are implicitly finalized. * **validator**: A participant in the Casper FFG consensus that has deposited ether in the casper contract and has the responsibility to vote and finalize checkpoints. * **validator set**: The set of validators in the casper contract at any given time. * **dynasty**: The number of finalized checkpoints in the chain from root to the parent of a block. The dynasty is used to define when a validator starts and ends validating. The current dynasty only increments when a checkpoint is finalized as opposed to epoch numbers that increment regardless of finality. * **slash**: The burning of some amount of a validator's deposit along with an immediate logout from the validator set. Slashing occurs when a validator signs two conflicting `vote` messages that violate a slashing condition. For an in-depth discussion of slashing conditions, see the [Casper FFG Paper](https://arxiv.org/abs/1710.09437). ## Motivation Transitioning the Ethereum network from PoW to PoS has been on the roadmap and in the [Yellow Paper](https://github.com/ethereum/yellowpaper) since the launch of the protocol. Although effective in coming to a decentralized consensus, PoW consumes an incredible amount of energy, has no economic finality, and has no effective strategy in resisting cartels. Excessive energy consumption, issues with equal access to mining hardware, mining pool centralization, and an emerging market of ASICs each provide a distinct motivation to make the transition as soon as possible. Until recently, the proper way to make this transition was still an open area of research. In October of 2017 [Casper the Friendly Finality Gadget](https://arxiv.org/abs/1710.09437) was published, solving open questions of economic finality through validator deposits and crypto-economic incentives. For a detailed discussion and proofs of "accountable safety" and "plausible liveness", see the [Casper FFG](https://arxiv.org/abs/1710.09437) paper. The Casper FFG contract can be layered on top of any block proposal mechanism, providing finality to the underlying chain. This EIP proposes layering FFG on top of the existing PoW block proposal mechanism as a conservative step-wise approach in the transition to full PoS. The new FFG staking mechanism requires minimal changes to the protocol, allowing the Ethereum network to fully test and evaluate Casper FFG on top of PoW before moving to a validator based block proposal mechanism. ## Parameters * `HYBRID_CASPER_FORK_BLKNUM`: TBD * `CASPER_ADDR`: TBD * `CASPER_CODE`: see below * `CASPER_BALANCE`: 1.25e24 wei (1,250,000 ETH) * `MSG_HASHER_ADDR`: TBD * `MSG_HASHER_CODE`: see below * `PURITY_CHECKER_ADDR`: TBD * `PURITY_CHECKER_CODE`: see below * `NULL_SENDER`: `2**160 - 1` * `NEW_BLOCK_REWARD`: 6e17 wei (0.6 ETH) * `REWARD_STEPDOWN_BLOCK_COUNT`: 5.5e5 blocks (~3 months) * `CASPER_INIT_DATA`: TBD * `VOTE_BYTES`: `0xe9dc0614` * `INITIALIZE_EPOCH_BYTES`: `0x5dcffc17` * `NON_REVERT_MIN_DEPOSIT`: amount in wei configurable by client ### Casper Contract Parameters * `EPOCH_LENGTH`: 50 blocks * `WARM_UP_PERIOD`: 1.8e5 blocks (~1 month) * `WITHDRAWAL_DELAY`: 1.5e4 epochs * `DYNASTY_LOGOUT_DELAY`: 700 dynasties * `BASE_INTEREST_FACTOR`: 7e-3 * `BASE_PENALTY_FACTOR`: 2e-7 * `MIN_DEPOSIT_SIZE`: 1.5e21 wei (1500 ETH) ## Specification #### Deploying Casper Contract If `block.number == HYBRID_CASPER_FORK_BLKNUM`, then when processing the block before processing any transactions: * set the code of `MSG_HASHER_ADDR` to `MSG_HASHER_CODE` * set the code of `PURITY_CHECKER_ADDR` to `PURITY_CHECKER_CODE` * set the code of `CASPER_ADDR` to `CASPER_CODE` * set balance of `CASPER_ADDR` to `CASPER_BALANCE` Then execute a `CALL` with the following parameters before executing any normal block transactions: * `SENDER`: `NULL_SENDER` * `GAS`: 3141592 * `TO`: `CASPER_ADDR` * `VALUE`: 0 * `NONCE`: 0 * `GASPRICE`: 0 * `DATA`: `CASPER_INIT_DATA` This `CALL` utilizes no gas and does not increment the nonce of `NULL_SENDER` #### Initialize Epochs If `block.number >= (HYBRID_CASPER_FORK_BLKNUM + WARM_UP_PERIOD)` and `block.number % EPOCH_LENGTH == 0`, execute a `CALL` with the following parameters before executing any normal block transactions: * `SENDER`: `NULL_SENDER` * `GAS`: 3141592 * `TO`: `CASPER_ADDR` * `VALUE`: 0 * `NONCE`: 0 * `GASPRICE`: 0 * `DATA`: `INITIALIZE_EPOCH_BYTES` followed by the 32-byte encoding of `floor(block.number / EPOCH_LENGTH)` This `CALL` utilizes no gas and does not increment the nonce of `NULL_SENDER` #### Casper Votes A `vote` transaction is defined as a transaction with the following parameters: * `TO`: `CASPER_ADDR` * `DATA`: Begins with `VOTE_BYTES` If `block.number >= HYBRID_CASPER_FORK_BLKNUM`, then: * A valid `vote` transaction to `CASPER_ADDR` must satisfy each of the following: * Must have the following signature `(CHAIN_ID, 0, 0)` (ie. `r = s = 0, v = CHAIN_ID`) * Must have `value == nonce == gasprice == 0` * When producing and validating a block, when handling `vote` transactions to `CASPER_ADDR`: * Only include "valid" `vote` transactions as defined above * Place all `vote` transactions at the end of the block * Track cumulative gas used by votes separately from cumulative gas used by normal transactions via `vote_gas_used` * Total `vote_gas_used` of `vote` transactions cannot exceed the `block_gas_limit`, independent of gas used by normal block transactions * When applying `vote` transactions to `CASPER_ADDR` to vm state: * Set sender to `NULL_SENDER` * Count gas of `vote` toward `vote_gas_used` * Do not count gas of `vote` toward the normal `gas_used`. For all `vote` transaction receipts, cumulative gas used is equal to last non-`vote` transaction receipt * Do not increment the nonce of `NULL_SENDER` * All unsuccessful `vote` transactions to `CASPER_ADDR` are invalid and must not be included in the block #### Fork Choice and Finalization If `block.number >= HYBRID_CASPER_FORK_BLKNUM`, the fork choice rule is the logic represented by the following pseudocode. Note that options `--casper-fork-choice` and `--exclude` are discussed below in "Client Settings". ```python def handle_block(new_block): if not is_new_head(new_block): return set_head(new_block) if --casper-fork-choice is on: check_and_finalize_new_checkpoint(new_block) def is_new_head(new_block): if --casper-fork-choice is off # old pure PoW chain scoring rule return new_block.total_difficuty > current_head.total_difficulty if new_block is in --exclude list or one of its descendants return false # don't revert finalized blocks if db.last_finalized_block is not in new_block.ancestors: return false # new casper chain scoring rule return highest_justified_epoch(new_block) * 10**40 + new_block.total_difficuty > highest_justified_epoch(current_head) * 10**40 + current_head.total_difficulty def highest_justified_epoch(block): casper = block.post_state.casper_contract return casper.highest_justified_epoch(NON_REVERT_MIN_DEPOSITS) def check_and_finalize_new_checkpoint(new_block): casper = new_block.post_state.casper_contract # If no finalized blocks, db.last_finalized_epoch initialized to -1 finalized_epoch = casper.highest_finalized_epoch(NON_REVERT_MIN_DEPOSITS) if finalized_epoch > db.last_finalized_epoch: finalized_hash = casper.checkpoint_hashes(finalized_epoch) # ensure not trivially finalized if finalized_hash == b'\x00' * 32: return db.last_finalized_epoch = finalized_epoch db.last_finalized_block = finalized_hash ``` The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (`NON_REVERT_MIN_DEPOSITS`). The `10**40` multiplier ensures that the justified epoch takes precedence over block mining difficulty. `total_difficulty` only serves as a tie breaker if the two blocks in question have an equivalent `highest_justified_epoch`. _Note_: If the client has no justified checkpoints, the contract returns `highest_justified_epoch` as `0` essentially reverting the fork choice rule to pure PoW. When assessing a new block as the chain's head, clients must _never revert finalized blocks_ as seen by the code commented as "don't revert finalized blocks". When a new block is added as the chain's head, clients then check for a new finalized block. This is handled by the `check_and_finalized_new_checkpoint(new_block)` method above. If the highest finalized epoch in the casper contract is greater than the previous finalized epoch, then the client finalizes the block with the hash `casper.checkpoint_hashes(finalized_epoch)`, storing this block and the related epoch number in the client database as finalized. Clients only consider checkpoints justified or finalized if deposits were greater than `NON_REVERT_MIN_DEPOSIT` _during the epoch in question_. This logic is encapsulated in `casper.highest_justified_epoch(NON_REVERT_MIN_DEPOSIT)` and `casper.highest_finalized_epoch(NON_REVERT_MIN_DEPOSIT)`, respectively. #### Block Reward If `block.number >= HYBRID_CASPER_FORK_BLKNUM`, then `block_reward` is defined by the following logic and utilizes the same formulas for ommer rewards but with the updated `block_reward`. ```python if block.number < HYBRID_CASPER_FORK_BLKNUM + REWARD_STEPDOWN_BLOCK_COUNT: block_reward = 5 * NEW_BLOCK_REWARD elif block.number < HYBRID_CASPER_FORK_BLKNUM + 2*REWARD_STEPDOWN_BLOCK_COUNT: block_reward = 4 * NEW_BLOCK_REWARD elif block.number < HYBRID_CASPER_FORK_BLKNUM + 3*REWARD_STEPDOWN_BLOCK_COUNT: block_reward = 3 * NEW_BLOCK_REWARD elif block.number < HYBRID_CASPER_FORK_BLKNUM + 4*REWARD_STEPDOWN_BLOCK_COUNT: block_reward = 2 * NEW_BLOCK_REWARD else: block_reward = NEW_BLOCK_REWARD ``` #### Validators The mechanics and responsibilities of validators are not specified in this EIP because they rely upon network transactions to the contract at `CASPER_ADDR` rather than on protocol level implementation and changes. See the [Validator Implementation Guide](https://github.com/ethereum/casper/blob/master/VALIDATOR_GUIDE.md) for validator details. #### MSG_HASHER_CODE The source code for `MSG_HASHER_CODE` is located [here](https://github.com/ethereum/casper/blob/master/casper/contracts/msg_hash.se.py). The source is to be migrated to Vyper LLL before the bytecode is finalized for this EIP. The EVM init code is: ``` TBD ``` The EVM bytecode that the contract should be set to is: ``` TBD ``` #### PURITY_CHECKER_CODE The source code for `PURITY_CHECKER_CODE` is located [here](https://github.com/ethereum/research/blob/master/impurity/check_for_impurity.se). The source is to be migrated to Vyper LLL before the bytecode is finalized for this EIP. The EVM init code is: ``` TBD ``` The EVM bytecode that the contract should be set to is: ``` TBD ``` #### CASPER_CODE The source code for `CASPER_CODE` is located at [here](https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py). The contract is to be formally verified and further tested before the bytecode is finalized for this EIP. The EVM init code with the above specified params is: ``` TBD ``` The EVM bytecode that the contract should be set to is: ``` TBD ``` #### Client Settings Clients should be implemented with the following configurable settings: ##### Enable Casper Fork Choice The ability to enable/disable the Casper Fork Choice. A suggested implementation is `--casper-fork-choice`. This setting should ship as default disabled in client versions during the initial casper fork. This setting should ship as default enabled in subsequent client versions. ##### NON_REVERT_MIN_DEPOSIT The minimum size of total deposits that the client must observe in the FFG contract for the state of the contract to affect the client's fork choice. A suggested implementation is `--non-revert-min-deposit WEI_VALUE`. The suggested default value that clients should ship with is at least 2e23 wei (200K ETH). See "Fork Choice" more details. ##### Exclusion The ability to exclude a specified blockhash and all of its descendants from a client's fork choice. A suggested implementation is `--exclude BLOCKHASHES`, where `BLOCK_HASHES` is a comma delimited list of blockhashes to exclude. Note: this _can_ by design override a client's forkchoice and revert finalized blocks. ##### Join Fork The ability to manually join a fork specified by a blockhash. A suggested implementation is `--join-fork BLOCKHASH` where the client automatically sets the head to the block defined by`BLOCKHASH` and locally finalizes it. Note: this _can_ by design override a client's forkchoice and revert finalized blocks. ##### Monitor Votes The ability to monitor incoming `vote` transactions for slashing conditions and submit proof to the casper contract for a finder's fee if found. A suggested implementation is `--monitor-votes`. The setting should default to disabled. The following pseudocode defines when two `vote` messages violate a slashing condition. A `vote` message is the singular argument included in a `vote` transaction. ```python def decode_rlp_list(vote_msg): # [validator_index, target_hash, target_epoch, source_epoch, signature] return RLPList(vote_msg, [int, bytes, int, int, bytes]) def same_target_epoch(vote_msg_1, vote_msg_2): decoded_values_1 = decode_rlp_msg(vote_msg_1) target_epoch_1 = decoded_values_1[2] decoded_values_2 = decode_rlp_msg(vote_msg_2) target_epoch_2 = decoded_values_2[2] return target_epoch_1 == target_epoch_2 def surrounds(vote_msg_1, vote_msg_2): decoded_values_1 = decode_rlp_msg(vote_msg_1) target_epoch_1 = decoded_values_1[2] source_epoch_1 = decoded_values_1[3] decoded_values_2 = decode_rlp_msg(vote_msg_2) target_epoch_2 = decoded_values_2[2] source_epoch_1 = decoded_values_1[3] vote_1_surrounds_vote_2 = target_epoch_1 > target_epoch_2 and source_epoch_1 < source_epoch_2 vote_2_surrounds_vote_1 = target_epoch_2 > target_epoch_1 and source_epoch_2 < source_epoch_1 return vote_1_surrounds_vote_2 or vote_2_surrounds_vote_1 def violates_slashing_condition(vote_msg_1, vote_msg_2): return same_target_epoch(vote_msg_1, vote_msg_2) or surrounds(vote_msg_1, vote_msg_2) ``` The casper contract also provides a helper method `slashable(vote_msg_1, vote_msg_2)` to check if two votes violate a slashing condition. Clients should use the above pseudocode in combination with `casper.slashable()` as a final check when deciding whether to submit a `slash` to the contract. The `--monitor-votes` setting is to be used for clients that wish to monitor vote transactions for slashing conditions. If a slashing condition is found, the client creates and sends a transaction to `slash` on the casper contract. The first transaction to include the slashing condition proof slashes the validator in question and sends a 4% finder's fee to the transaction sender. ## Rationale Naive PoS specifications and implementations have existed since early blockchain days, but most are vulnerable to serious attacks and do not hold up under crypto-economic analysis. Casper FFG solves problems such as "Nothing at Stake" and "Long Range Attacks" through requiring validators to post slashable deposits and through defining economic finality. #### Minimize Consensus Changes The finality gadget is designed to minimize changes across clients. For this reason, FFG is implemented within the EVM, so that the contract byte code encapsulates most of the complexity of the fork. Most other decisions were made to minimize changes across clients. For example, it would be possible to allow `CASPER_ADDR` to mint Ether each time it paid rewards (as compared to creating the contract with `CASPER_BALANCE`), but this would be more invasive and error-prone than relying on existing EVM mechanics. #### Deploying Casper Contract The `MSG_HASHER_CODE` and `PURITY_CHECKER_CODE` both do not require any initialization so the EVM bytecode can simply be placed at `MSG_HASHER_ADDR` and `PURITY_CHECKER_ADDR`. On the other hand, the casper contract _does_ require passing in parameters and initialization of state. This initialization would normally occur by the EVM init code interacting with the CREATE opcode. Due to the nature of this contract being deployed outside of normal block transactions and to a particular address, the EVM init code/CREATE method requires client specific "hacks" to make it work. For simplicity of specifying across clients, the EVM bytecode -- `CASPER_CODE` -- is placed at `CASPER_ADDR` followed by an explicit `CALL` to a one-time `init` method on the casper contract. `init` handles all of the logic that a constructor normally would, accepting contract parameters as arguments and setting initial variable values, and can only be run _once_. `CASPER_INIT_DATA` is composed of the byte signature of the `init` method of the casper contract concatenated with the 32-byte encodings of the following variables in the following order: * `EPOCH_LENGTH` * `WITHDRAWAL_DELAY` * `DYNASTY_LOGOUT_DELAY` * `MSG_HASHER_ADDR` * `PURITY_CHECKER_ADDR` * `BASE_INTEREST_FACTOR` * `BASE_PENALTY_FACTOR` * `MIN_DEPOSIT_SIZE` The entirety of this data is provided as a bytestring -- `CASPER_INIT_DATA` -- to reduce the chance of encoding errors across clients, especially regarding fixed decimal types which are new in vyper and not yet supported by all clients. #### Casper Contract Params `EPOCH_LENGTH` is set to 50 blocks as a balance between time to finality and message overhead. `WARM_UP_PERIOD` is set to 1.8e5 blocks to provide validators with an approximate 1 month period to make initial deposits before full contract functionality and voting begin. This helps prevent degenerate cases such as having very few or even just one validator in the initial dynasty. This 1 month period also gives the network time to observe on the order of how many validators will initially be participating in consensus. If for some reason there is an unexpectedly low turnout, the community might choose to delay validation and consider design alternatives. `WITHDRAWAL_DELAY` is set to 15000 epochs to freeze a validator's funds for approximately 4 months after logout. This allows for at least a 4 month window to identify and slash a validator for attempting to finalize two conflicting checkpoints. This also defines the window of time with which a client must log on to sync the network due to weak subjectivity. `DYNASTY_LOGOUT_DELAY` is set to 700 dynasties to prevent immediate logout in the event of an attack from being a viable strategy. `BASE_INTEREST_FACTOR` is set to 7e-3 such that if there are ~10M ETH in total deposits, then validators earn approximately 5% per year in ETH rewards under optimal FFG conditions. `BASE_PENALTY_FACTOR` is set to 2e-7 such that if 50% of deposits go offline, then offline validators lose half of their deposits in approximately 3 weeks, at which the online portion of validators becomes a 2/3 majority and can begin finalizing checkpoints again. `MIN_DEPOSIT_SIZE` is set to 1500 ETH to form a natural upper bound on the total number of validators, bounding the overhead due to `vote` messages. Using formulas found [here](https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735) under "From validator count to minimum staking ETH", we estimate that with 1500 ETH minimum deposit at an assumed ~10M in total deposits there will be approximately 900 validators at any given time. `vote`s are only sent after the first quarter of an epoch so 900 votes have to fit into 37 blocks or ~24 `vote`s per block. We have experimented with more dynamic models for `MIN_DEPOSIT_SIZE`, but these tend to introduce significant complexities and without data from a live network seem to be premature optimizations. #### Initialize Epochs The call to the method at `INITIALIZE_EPOCH_BYTES` at `CASPER_ADDR` at the start of each epoch is a call to the `initialize_epoch` method in the casper contract. This method can only be called once per epoch and is guaranteed by the protocol to be called at the start block of each epoch by `NULL_SENDER`. This method performs a number of bookkeeping tasks around incrementing variables, updating rewards, etc. Any call to this method fails prior to the end of the `WARM_UP_PERIOD`. Thus the protocol does not begin executing `initialize_epoch` calls until `block.number >= HYBRID_CASPER_FORK_BLKNUM + WARM_UP_PERIOD`. #### Issuance A fixed amount of 1.25M ETH was chosen as `CASPER_BALANCE` to fund the casper contract. This gives the contract enough runway to operate for approximately 2 years (assuming ~10M ETH in validator deposits). Acting similarly to the "difficulty bomb", this "funding crunch" forces the network to hardfork in the relative near future to further fund the contract. This future hardfork is an opportunity to upgrade the contract and transition to full PoS. The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforeseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG. In addition to block rewards, miners now receive an issuance reward for including successful `vote` transactions into the block on time. This reward is equal to 1/8th that of the reward the validator receives for a successful `vote` transaction. Under optimal FFG conditions after group validator reward adjustments are made, miners receive approximately 1/5th of the total ETH issued by the Casper contract. Below is a table of deposit sizes with associated annual interest rate and approximate time until funding crunch: | Deposit Size | Annual Validator Interest | Funding Crunch | | -------- | -------- | -------- | | 2.5M ETH | 10.12% | ~4 years | | 10M ETH | 5.00% | ~2 years | | 20M ETH | 3.52% | ~1.4 years | | 40M ETH | 2.48% | ~1 year | #### Gas Changes Normal block transactions cannot affect casper `vote` validation results, but casper `vote` validation results can affect normal block transaction execution. Due to this asymmetrical relationship, `vote` transactions can be processed in parallel with normal block transactions if `vote` transactions are placed after all normal block transactions. Because `vote` transactions can be processed in parallel to normal block transactions, `vote` transactions cost 0 gas for validators, ensuring that validators can submit votes even in highly congested or high gas-price periods. `vote_gas_used` is introduced to ensure that `vote` transactions do not put an undue burden on block processing. The additional overhead from `vote` transactions is capped at the same limit as normal block transactions so that, when run in parallel, neither sets of transactions exceed the overhead defined by the `block_gas_limit`. The call to `initialize_epoch` at the beginning of each epoch requires 0 gas so that this protocol state transition does not take any gas allowance away from normal transactions. #### NULL_SENDER and Account Abstraction This EIP implements a limited version of account abstraction for validators' `vote` transactions. The general design was borrowed from [EIP-86](/EIPS/eip-86). Rather than relying upon native transaction signatures, each validator specifies a signature contract when sending their `deposit` to `CASPER_ADDR`. When casting a `vote`, the validator bundles and signs the parameters of their `vote` according to the requirements of their signature contract. The `vote` method of the casper contract checks the signature of the parameters against the validator's signature contract, exiting the transaction as unsuccessful if the signature is not successfully verified. This allows validators to customize their own signing scheme for votes. Use cases include: * quantum-secure signature schemes * multisig wallets * threshold schemes For more details on validator account abstraction, see the [Validator Implementation Guide](https://github.com/ethereum/casper/blob/master/VALIDATOR_GUIDE.md). #### Client Settings ##### Enable Casper Fork Choice Releasing client versions with the casper fork choice as initially default disabled allows for a more conservative transition to hybrid Casper FFG. Under normal operating conditions there are no disparities between the PoW fork choice and the hybrid Casper FFG fork choice. The two fork choice rules can only diverge if either 51% of miners or 51% of validators are faulty. Validators will begin to log on, vote, and finalize the FFG contract before the majority of the network begins explicitly relying upon the new finality mechanism. Once a significant number of validators have logged on and the finality mechanism has been tested on the live network, new client software versions that change the default to enabled will be released. ##### NON_REVERT_MIN_DEPOSIT `NON_REVERT_MIN_DEPOSIT` is defined and configurable locally by each client. Clients are in charge of deciding upon the minimum deposits (security) at which they will accept the chain as finalized. In the general case, differing values in the choice of this local constant will not create any fork inconsistencies because clients with very strict finalization requirements will revert to follow the longest PoW chain. Arguments have been made to hardcode a value into clients or the contract, but we cannot reasonably define security required for all clients especially in the context of massive fluctuations in the value of ETH. ##### Exclusion This setting is useful in coordinating minority forks in cases of majority collusion. ##### Join Fork This setting is to be used by new clients that are syncing the network for the first time. Due to weak subjectivity, a blockhash should be supplied to successfully sync the network when initially starting a node. This setting is also useful for coordinating minority forks in cases of majority collusion. ##### Monitor Votes Monitoring the network for slashing conditions is key to Casper FFG's "accountable safety" as submitting proof of nefarious activity burns a validator's deposit. This setting is suggested default disabled because the block producer will almost certainly frontrun anyone else submitting a `slash` transaction. To prevent every client on the network from submitting a `slash` transaction in the event of a slashing condition, this setting should only be enabled by block producers and those clients who explicitly choose to monitor votes. ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the state, fork choice rule, block reward, transaction validity, and gas calculations on certain transactions. Therefore, all changes should be included in a scheduled hardfork at `HYBRID_CASPER_FORK_BLKNUM`. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 20 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1011 https://eips.ethereum.org/EIPS/eip-1011 Hardfork Meta: Constantinople Meta/ ## Abstract This meta-EIP specifies the changes included in the Ethereum hardfork named Constantinople. ## Specification - Codename: Constantinople - Aliases: Metropolis/Constantinople, Metropolis part 2 - Activation: - `Block >= 7_280_000` on the Ethereum Mainnet - `Block >= 4,230,000` on the Ropsten testnet - `Block >= 9_200_000` on the Kovan testnet - `Block >= 3_660_663` on the Rinkeby testnet - Included EIPs: - [EIP-145](/EIPS/eip-145): Bitwise shifting instructions in EVM - [EIP-1014](/EIPS/eip-1014): Skinny CREATE2 - [EIP-1052](/EIPS/eip-1052): EXTCODEHASH Opcode - [EIP-1234](/EIPS/eip-1234): Delay difficulty bomb, adjust block reward - [EIP-1283](/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps ## References 1. The list above includes the EIPs discussed as candidates for Constantinople at the All Core Dev [Constantinople Session #1](https://github.com/ethereum/pm/issues/55). See also [Constantinople Progress Tracker](https://github.com/ethereum/pm/wiki/Constantinople-Progress-Tracker). 2. https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 20 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1013 https://eips.ethereum.org/EIPS/eip-1013 Skinny CREATE2 Standards Track/Core ### Specification Adds a new opcode (`CREATE2`) at `0xf5`, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to `CREATE` (`0xf0`), except using `keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. The `CREATE2` has the same `gas` schema as `CREATE`, but also an extra `hashcost` of `GSHA3WORD * ceil(len(init_code) / 32)`, to account for the hashing that must be performed. The `hashcost` is deducted at the same time as memory-expansion gas and `CreateGas` is deducted: _before_ evaluation of the resulting address and the execution of `init_code`. - `0xff` is a single byte, - `address` is always `20` bytes, - `salt` is always `32` bytes (a stack item). The preimage for the final hashing round is thus always exactly `85` bytes long. The coredev-call at 2018-08-10 decided to use the formula above. ### Motivation Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts. ### Rationale #### Address formula * Ensures that addresses created with this scheme cannot collide with addresses created using the traditional `keccak256(rlp([sender, nonce]))` formula, as `0xff` can only be a starting byte for RLP for data many petabytes long. * Ensures that the hash preimage has a fixed size, #### Gas cost Since address calculation depends on hashing the `init_code`, it would leave clients open to DoS attacks if executions could repeatedly cause hashing of large pieces of `init_code`, since expansion of memory is paid for only once. This EIP uses the same cost-per-word as the `SHA3` opcode. ### Clarifications The `init_code` is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a 'constructor'. This EIP makes collisions possible. The behaviour at collisions is specified by [EIP-684](https://github.com/ethereum/EIPs/issues/684): > If a contract creation is attempted, due to either a creation transaction or the `CREATE` (or future `CREATE2`) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis. Specifically, if `nonce` or `code` is nonzero, then the create-operation fails. With [EIP-161](/EIPS/eip-161) > Account creation transactions and the `CREATE` operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one This means that if a contract is created in a transaction, the `nonce` is immediately non-zero, with the side-effect that a collision within the same transaction will always fail -- even if it's carried out from the `init_code` itself. It should also be noted that `SELFDESTRUCT` (`0xff`) has no immediate effect on `nonce` or `code`, thus a contract cannot be destroyed and recreated within one transaction. ### Examples Example 0 * address `0x0000000000000000000000000000000000000000` * salt `0x0000000000000000000000000000000000000000000000000000000000000000` * init_code `0x00` * gas (assuming no mem expansion): `32006` * result: `0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38` Example 1 * address `0xdeadbeef00000000000000000000000000000000` * salt `0x0000000000000000000000000000000000000000000000000000000000000000` * init_code `0x00` * gas (assuming no mem expansion): `32006` * result: `0xB928f69Bb1D91Cd65274e3c79d8986362984fDA3` Example 2 * address `0xdeadbeef00000000000000000000000000000000` * salt `0x000000000000000000000000feed000000000000000000000000000000000000` * init_code `0x00` * gas (assuming no mem expansion): `32006` * result: `0xD04116cDd17beBE565EB2422F2497E06cC1C9833` Example 3 * address `0x0000000000000000000000000000000000000000` * salt `0x0000000000000000000000000000000000000000000000000000000000000000` * init_code `0xdeadbeef` * gas (assuming no mem expansion): `32006` * result: `0x70f2b2914A2a4b783FaEFb75f459A580616Fcb5e` Example 4 * address `0x00000000000000000000000000000000deadbeef` * salt `0x00000000000000000000000000000000000000000000000000000000cafebabe` * init_code `0xdeadbeef` * gas (assuming no mem expansion): `32006` * result: `0x60f3f640a8508fC6a86d45DF051962668E1e8AC7` Example 5 * address `0x00000000000000000000000000000000deadbeef` * salt `0x00000000000000000000000000000000000000000000000000000000cafebabe` * init_code `0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef` * gas (assuming no mem expansion): `32012` * result: `0x1d8bfDC5D46DC4f61D6b6115972536eBE6A8854C` Example 6 * address `0x0000000000000000000000000000000000000000` * salt `0x0000000000000000000000000000000000000000000000000000000000000000` * init_code `0x` * gas (assuming no mem expansion): `32000` * result: `0xE33C0C7F7df4809055C3ebA6c09CFe4BaF1BD9e0` Fri, 20 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1014 https://eips.ethereum.org/EIPS/eip-1014 Configurable On Chain Issuance Standards Track/Core https://ethereum-magicians.org/t/eip-dynamic-block-rewards-with-governance-contract/204 ## Simple Summary This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be maintained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance. ## Summary ### Thesis: many controversial issues boil down to resources These are current EIPs that are being developed or debated. They might seem unrelated but they have something in common, that they can be resolved by proper channel of funds. #### Casper and PoS Moving to PoS has been on the roadmap since day 0 for ethereum, along with a reduction in issuance to a cost equivalent to the Validator's cost of security (considered to be more efficient than PoW). But the exact issuance necessary for PoS has yet to be determined and is currently being researched. Casper validation will be an on chain contract and therefore it will need to be funded. It's unlikely that a definitive final answer on how much issuance is needed for validation will be reached in the next years as new research will uncover new arguments, so it would make sense to allow some flexibility on this matter #### Issuance Cap at 120 Million [EIP-960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision. #### Asics and advantages of PoW [EIP-960](https://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantages to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**. #### Recovery Forks After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. #### Other Public Goods There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](/EIPS/eip-908), fair distribution of tokens etc. ## Proposed Solution ### Issuance Contract This EIP proposes a future hard fork where block reward is not issued to miners/validators etherbase, but instead to a single contract, that then will activate the default function (with a fixed amount of gas) and then it will forward the ether to other contracts which will finally distribute to their final destinations. #### Limits on the contract ##### It can only deal with issuance It's not meant to be a general governance contract. The contract **should NOT be used** to decide software updates, to freeze funds, change contract balances or anything on the consensus layer other than the strict definition of *where block rewards go*. It should be seen as a platform to settle disputes to avoid the implementation of contentious hard forks, not as a mean to remove the power of users and developers to execute them. ##### It cannot only decrease issuance, and once decreased it cannot be increased again In order to reduce future abuse and uncertainty, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is aggressively to reduce issuance to zero, it would take a known number of years. ##### Results are locked for s Whenever a new decision on either reducing the issuance or changing the target is made, the effects will have a six-month delay to it. Once a decision is made it is final, it will take place six months after that, but if it's shortly reversed, then that change will be short lived. The rationale behind is that it allows time to anyone disagreeing with the decision to: * Sell their coins so that if a bad actor takes over they will have a reduced reward * Attempt to revert the decision as soon as possible, to reduce the duration that the change will take place * Organize to create counter measures against the decision * Implement a hard fork changing the decision contract or to remove the issuance contract altogether, as a last resort measure ##### Interface It would have the following interface: `function targetContract() returns (address)` There's a single target contract that should ether issued to. At each new block, that contract would have the default function called so it would forward to the intended addresses. `function decisionAssembly() returns (address)` A contract that would represent the internal governance of decisions. More on this later. `function reduceIssuance(uint)` Can only be called by **decision assembly**. The contract is allowed to reduce or maintain the issuance per block. **Change is not executed immediately, effects only happen six months later, but once a decision is committed it is irrevocable**. `function changeTargetContract(address)` Can only be called by **decision assembly**. It changes the contract that will receive the funds in the future. Only one contract can be appointed, but if the community desires to split issuance or even burn a part of it (in a non-irrevocable manner) it can be done in that contract. Change is not executed immediately, **effects only happen six months later**, but once a decision is committed it is certain, even if it's later reverted: if a new target contract is changed after a few hours, then it still means that in six month's time, it would issue for that contract for a few hours. `function executeDecision(uint)` Can be called by anyone: it executes a change to issuance amount or target that had been scheduled six months prior. ##### Decision Assembly A contract that has the power to decide the changes to issuance, the core of the governance of these decisions. The exact format of this governance is open to debate, but what follows is a suggestion: The decision would be made by multiple signalling contracts, each one implemented by separate groups and representing one aspect of the community or one sort of measurement. Each signaling process would have a `int` bound in which they could vote and they would have their own internal process to decide that. As new governance methods are tested and debated, new signalling contracts should be added and removed. Suggested signalling contracts: * Futarchy and prediction markets based on multiple measures * Votes weighted by ether balance (optionally with multipliers if the voters were committed to locking votes) * Token votes, weighted by their own relative ether exchange rate * Votes by individual humans if a good sybil resistance, coercion mechanism is developed * Block-signalling, as a way to measure validators/miners choices * Some sort of signalling representing developers, exchanges or other stakeholders * Any other proposed manner Since adding and removing signalling contracts, as well as changing their total weight would be controlled by the contract itself, it would be crucial that the first signalling contracts were a diverse set of interests, and that they were open to adding more signals as new governance is experimented as well as removing signals that stop representing the community. ### Questions to be debated A lot of things are suggested in this EIP, so I would like to propose these questions to be debated: 1. Do we want to have dynamically changing block rewards, instead of having them be hard coded in the protocol? 2. If the answer above is yes, then what would be the best governance process to decide it, and what sorts of limits would we want that governance contract to have? 3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the process to add and remove them? ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 20 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1015 https://eips.ethereum.org/EIPS/eip-1015 tokenURI Interoperability Standards Track/ERC https://ethereum-magicians.org/t/eip-1046-erc-20-metadata-extension/13036 ## Abstract [ERC-721](/EIPS/eip-721) introduced a `tokenURI` function for non-fungible tokens to handle miscellaneous metadata such as: - thumbnail image - title - description - special asset properties - etc. This ERC adds a `tokenURI` function to [ERC-20](/EIPS/eip-20), and extends [ERC-721](/EIPS/eip-721) and [ERC-1155](/EIPS/eip-1155) to enable interoperability between all three types of token URI. ## Motivation See the note about the metadata extension in [ERC-721](/EIPS/eip-721#rationale). The same arguments apply to ERC-20. Being able to use similar mechanisms to extract metadata for ERC-20, ERC-721, ERC-1155, and future standards is useful for determining: - What type of token a contract is (if any); - How to display a token to a user, either in an asset listing page or on a dedicated token page; and - Determining the capabilities of the token ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. ### Interoperability Metadata The following TypeScript interface is used in later sections: ```typescript /** * Interoperability metadata. * This can be extended by other proposals. * * All fields MUST be optional. * **Not every field has to be a boolean.** Any optional JSON-serializable object can be used by extensions. */ interface InteroperabilityMetadata { /** * This MUST be true if this is ERC-1046 Token Metadata, otherwise, this MUST be omitted. * Setting this to true indicates to wallets that the address should be treated as an ERC-20 token. **/ erc1046?: boolean | undefined; /** * This MUST be true if this is ERC-721 Token Metadata, otherwise, this MUST be omitted. * Setting this to true indicates to wallets that the address should be treated as an ERC-721 token. **/ erc721?: boolean | undefined; /** * This MUST be true if this is ERC-1155 Token Metadata, otherwise, this MUST be omitted. * Setting this to true indicates to wallets that the address should be treated as an ERC-1155 token. **/ erc1155?: boolean | undefined; } ``` ### ERC-20 Extension #### ERC-20 Interface Extension Compliant contracts MUST implement the following Solidity interface: ```solidity pragma solidity ^0.8.0; /// @title ERC-20 Metadata Extension interface ERC20TokenMetadata /* is ERC20 */ { /// @notice Gets an ERC-721-like token URI /// @dev The resolved data MUST be in JSON format and support ERC-1046's ERC-20 Token Metadata Schema function tokenURI() external view returns (string); } ``` #### ERC-20 Token Metadata Schema The resolved JSON of the `tokenURI` described in the ERC-20 Interface Extension section MUST conform to the following TypeScript interface: ```typescript /** * Asset Metadata */ interface ERC20TokenMetadata { /** * Interoperability, to differentiate between different types of tokens and their corresponding URIs. **/ interop: InteroperabilityMetadata; /** * The name of the ERC-20 token. * If the `name()` function is present in the ERC-20 token and returns a nonempty string, these MUST be the same value. */ name?: string; /** * The symbol of the ERC-20 token. * If the `symbol()` function is present in the ERC-20 token and returns a nonempty string, these MUST be the same value. */ symbol?: string; /** * The decimals of the ERC-20 token. * If the `decimals()` function is present in the ERC-20 token, these MUST be the same value. * Defaults to 18 if neither this parameter nor the ERC-20 `decimals()` function are present. */ decimals?: number; /** * Provides a short one-paragraph description of the ERC-20 token, without any markup or newlines. */ description?: string; /** * A URI pointing to a resource with mime type `image/*` that represents this token. * If the image is a bitmap, it SHOULD have a width between 320 and 1080 pixels * The image SHOULD have an aspect ratio between 1.91:1 and 4:5 inclusive. */ image?: string; /** * One or more URIs each pointing to a resource with mime type `image/*` that represents this token. * If an image is a bitmap, it SHOULD have a width between 320 and 1080 pixels * Images SHOULD have an aspect ratio between 1.91:1 and 4:5 inclusive. */ images?: string[]; /** * One or more URIs each pointing to a resource with mime type `image/*` that represent an icon for this token. * If an image is a bitmap, it SHOULD have a width between 320 and 1080 pixels, and MUST have a height equal to its width * Images MUST have an aspect ratio of 1:1, and use a transparent background */ icons?: string[]; } ``` ### ERC-721 Extension #### Extension to the ERC-721 Metadata Schema Contracts that implement ERC-721 and use its token metadata URI SHOULD to use the following TypeScript extension to the metadata URI: ```typescript interface ERC721TokenMetadataInterop extends ERC721TokenMetadata { /** * Interoperability, to avoid confusion between different token URIs **/ interop: InteroperabilityMetadata; } ``` ### ERC-1155 Extension #### ERC-1155 Interface Extension [ERC-1155](/EIPS/eip-1155)-compliant contracts using the metadata extension SHOULD implement the following Solidity interface: ```solidity pragma solidity ^0.8.0; /// @title ERC-1155 Metadata URI Interoperability Extension interface ERC1155TokenMetadataInterop /* is ERC1155 */ { /// @notice Gets an ERC-1046-compliant ERC-1155 token URI /// @param tokenId The token ID to get the URI of /// @dev The resolved data MUST be in JSON format and support ERC-1046's Extension to the ERC-1155 Token Metadata Schema /// This MUST be the same URI as the `uri(tokenId)` function, if present. function tokenURI(uint256 tokenId) external view returns (string); } ``` #### Extension to the ERC-1155 Metadata Schema Contracts that implement ERC-1155 and use its token metadata URI are RECOMMENDED to use the following extension to the metadata URI. Contracts that implement the interface described in the ERC-1155 Interface Extension section MUST use the following TypeScript extension: ```typescript interface ERC1155TokenMetadataInterop extends ERC1155TokenMetadata { /** * Interoperability, to avoid confusion between different token URIs **/ interop: InteroperabilityMetadata; } ``` ### Miscellaneous Recommendations To save gas, it is RECOMMENDED for compliant contracts not to implement the `name()`, `symbol()`, or `decimals()` functions, and instead to only include them in the metadata URI. Additionally, for ERC-20 tokens, if the decimals is `18`, then it is NOT RECOMMENDED to include the `decimals` field in the metadata. ## Rationale This ERC makes adding metadata to ERC-20 tokens more straightforward for developers, with minimal to no disruption to the overall ecosystem. Using the same parameter name makes it easier to reuse code. Additionally, the recommendations not to use ERC-20's `name`, `symbol`, and `decimals` functions save gas. Built-in interoperability is useful as otherwise it might not be easy to differentiate the type of the token. Interoperability could be done using [ERC-165](/EIPS/eip-165), but static calls are time-inefficient for wallets and websites, and is generally inflexible. Instead, including interoperability data in the token URI increases flexibility while also giving a performance increase. ## Backwards Compatibility This EIP is fully backwards compatible as its implementation simply extends the functionality of ERC-20 tokens and is optional. Additionally, it makes backward compatible recommendations for ERC-721 and ERC-1155 tokens. ## Security Considerations ### Server-Side Request Forgery (SSRF) Wallets should be careful about making arbitrary requests to URLs. As such, it is recommended for wallets to sanitize the URI by whitelisting specific schemes and ports. A vulnerable wallet could be tricked into, for example, modifying data on a locally-hosted redis database. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 13 Apr 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1046 https://eips.ethereum.org/EIPS/eip-1046 Overflow checking for the EVM Standards Track/Core https://ethereum-magicians.org/t/eip-arithmetic-overflow-detection-for-the-evm/261 ## Abstract This EIP adds overflow checking for EVM arithmetic operations, and two new opcodes that check and clear the overflow flags. ## Motivation The correct functioning of many contracts today is dependent on detecting and preventing overflow of arithmetic operations. Since the EVM operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation. In the interests of facilitating efficient and secure contracts, we propose new opcodes that permit efficient detection of overflows, which can be checked periodically rather than after each operation. ## Specification Two new flags are added to the EVM state: overflow (`ovf`) and signed overflow (`sovf`). The `ovf` flag is set in the following circumstances: - When an `ADD` (`0x01`) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1. - When a `SUB` (`0x03`) opcode, with both inputs treated as unsigned integers, produces an ideal output less than 0. - When a `MUL` (`0x02`) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1. The `sovf` flag is set whenever the `ovf` flag is set, and additionally in the following circumstances: - When an `ADD` opcode with both inputs having the same MSB results in the output having a different MSB (eg, `(+a) + (+b) = (-c)` or `(-a) + (-b) = (+c)`). - When a `SUB` opcode occurs and the result has the same MSB as the subtracted (second argument) (eg, `(+a) - (-b) = (-c)` or `(-a) - (+b) = (+c)`). - When a `MUL` opcode with both inputs being positive has a negative output. - When a `MUL` opcode with both inputs being negative has a negative output. - When a `MUL` opcode with one negative input and one positive input has a positive output. A new opcode, `OFV` is added, with number `0x0c`. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `ovf` flag is set, and `0` otherwise. It then sets the `ovf` flag to false. A new opcode, `SOVF` is added, with number `0x0d`. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `sovf` flag is set, and `0` otherwise. It then sets the `sovf` flag to false. ## Rationale Any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. One option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. However, this limits the manner in which overflows can be handled. Instead, we replicate functionality from real world CPUs, which typically implement 'carry' and 'overflow' flags. Separate flags for signed and unsigned overflow are necessary due to the fact that a signed overflow may not result in an unsigned overflow. ## Backwards Compatibility This EIP introduces no backwards compatibility issues. ## Test Cases TBD ## Implementation TBD ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 02 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1051 https://eips.ethereum.org/EIPS/eip-1051 EXTCODEHASH opcode Standards Track/Core https://ethereum-magicians.org/t/extcodehash-opcode/262 ## Abstract This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code. ## Motivation Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes. Contracts can presently do this using the `EXTCODECOPY` (`0x3c`) opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, `EXTCODEHASH`, which returns the keccak256 hash of a contract's bytecode. ## Specification A new opcode, `EXTCODEHASH`, is introduced, with number `0x3f`. The `EXTCODEHASH` takes one argument from the stack, zeros the first 96 bits and pushes to the stack the keccak256 hash of the code of the account at the address being the remaining 160 bits. In case the account does not exist or is empty (as defined by [EIP-161](/EIPS/eip-161)) `0` is pushed to the stack. In case the account does not have code the keccak256 hash of empty data (i.e. `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`) is pushed to the stack. The gas cost of the `EXTCODEHASH` is 400. ## Rationale As described in the motivation section, this opcode is widely useful, and saves on wasted gas in many cases. The gas cost is the same as the gas cost for the `BALANCE` opcode because the execution of the `EXTCODEHASH` requires the same account lookup as in `BALANCE`. Only the 20 last bytes of the argument are significant (the first 12 bytes are ignored) similarly to the semantics of the `BALANCE` (`0x31`), `EXTCODESIZE` (`0x3b`) and `EXTCODECOPY` (`0x3c`). The `EXTCODEHASH` distinguishes accounts without code and non-existing accounts. This is consistent with the way accounts are represented in the state trie. This also allows smart contracts to check whether an account exists. ## Backwards Compatibility There are no backwards compatibility concerns. ## Test Cases 1. The `EXTCODEHASH` of the account without code is `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470` what is the keccak256 hash of empty data. 2. The `EXTCODEHASH` of non-existent account is `0`. 3. The `EXTCODEHASH` of a precompiled contract is either `c5d246...` or `0`. 4. If `EXTCODEHASH` of `A` is `X`, then `EXTCODEHASH` of `A + 2**160` is `X`. 5. The `EXTCODEHASH` of an account that selfdestructed in the current transaction. 6. The `EXTCODEHASH` of an account that selfdestructed and later the selfdestruct has been reverted. 7. The `EXTCODEHASH` of an account created in the current transaction. 8. The `EXTCODEHASH` of an account that has been newly created and later the creation has been reverted. 9. The `EXTCODEHASH` of an account that firstly does not exist and later is empty. 10. The `EXTCODEHASH` of an empty account that is going to be cleared by the state clearing rule. ## Implementation TBD ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 02 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1052 https://eips.ethereum.org/EIPS/eip-1052 Ethereum Lightweight Identity Standards Track/ERC https://github.com/ethereum/EIPs/issues/1056 ## Simple Summary A registry for key and attribute management of lightweight blockchain identities. ## Abstract This ERC describes a standard for creating and updating identities with a limited use of blockchain resources. An identity can have an unlimited number of `delegates` and `attributes` associated with it. Identity creation is as simple as creating a regular key pair ethereum account, which means that it's free (no gas costs) and all ethereum accounts are valid identities. Furthermore this ERC is fully [DID compliant](https://w3c-ccg.github.io/did-spec/). ## Motivation As we have been developing identity systems for the last couple of years at uPort it has become apparent that the cost of identity creation is a large issue. The previous Identity proposal [ERC-725](/EIPS/eip-725) faces this exact issue. Our requirements when creating this ERC is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the identity. The identity system should be fit to use off-chain as well as on-chain. ## Definitions * `Identifier`: a piece of data that uniquely identifies the identity, an ethereum address * `delegate`: an address that is delegated for a specific time to perform some sort of function on behalf of an identity * `delegateType`: the type of a delegate, is determined by a protocol or application higher up Examples: * `did-jwt` * `raiden` * `attribute`: a piece of data associated with the identity ## Specification This ERC specifies a contract called `EthereumDIDRegistry` that is deployed once and can then be commonly used by everyone. ### Identity ownership By default an identity is owned by itself, meaning whoever controls the ethereum account with that address. The owner can be updated to a new key pair account or to a multisig account etc. #### identityOwner Returns the owner of the given identity. ```js function identityOwner(address identity) public view returns(address); ``` #### changeOwner Sets the owner of the given identity to another ethereum account. ```js function changeOwner(address identity, address newOwner) public; ``` #### changeOwnerSigned Same as above but with raw signature. ```js function changeOwnerSigned(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, address newOwner) public; ``` ### Delegate management Delegates can be used both on- and off-chain. They all have a `delegateType` which can be used to specify the purpose of the delegate. #### validDelegate Returns true if the given `delegate` is a delegate with type `delegateType` of `identity`. ```js function validDelegate(address identity, bytes32 delegateType, address delegate) public view returns(bool); ``` #### addDelegate Adds a new delegate with the given type. `validity` indicates the number of seconds that the delegate will be valid for, after which it will no longer be a delegate of `identity`. ```js function addDelegate(address identity, bytes32 delegateType, address delegate, uint validity) public; ``` #### addDelegateSigned Same as above but with raw signature. ```js function addDelegateSigned(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, bytes32 delegateType, address delegate, uint validity) public; ``` #### revokeDelegate Revokes the given `delegate` for the given `identity`. ```js function revokeDelegate(address identity, bytes32 delegateType, address delegate) public; ``` #### revokeDelegateSigned Same as above but with raw signature. ```js function revokeDelegateSigned(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, bytes32 delegateType, address delegate) public; ``` ### Attribute management Attributes contain simple data about the identity. They can be managed only by the owner of the identity. #### setAttribute Sets an attribute with the given `name` and `value`, valid for `validity` seconds. ```js function setAttribute(address identity, bytes32 name, bytes value, uint validity) public; ``` #### setAttributeSigned Same as above but with raw signature. ```js function setAttributeSigned(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, bytes32 name, bytes value, uint validity) public; ``` #### revokeAttribute Revokes an attribute. ```js function revokeAttribute(address identity, bytes32 name, bytes value) public; ``` #### revokeAttributeSigned Same as above but with raw signature. ```js function revokeAttributeSigned(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, bytes32 name, bytes value) public; ``` ### Events #### DIDOwnerChanged MUST be triggered when `changeOwner` or `changeOwnerSigned` was successfully called. ```js event DIDOwnerChanged( address indexed identity, address owner, uint previousChange ); ``` #### DIDDelegateChanged MUST be triggered when a change to a delegate was successfully made. ```js event DIDDelegateChanged( address indexed identity, bytes32 delegateType, address delegate, uint validTo, uint previousChange ); ``` #### DIDAttributeChanged MUST be triggered when a change to an attribute was successfully made. ```js event DIDAttributeChanged( address indexed identity, bytes32 name, bytes value, uint validTo, uint previousChange ); ``` ### Efficient lookup of events through linked identity events Contract Events are a useful feature for storing data from smart contracts exclusively for off-chain use. Unfortunately current ethereum implementations provide a very inefficient lookup mechanism. By using linked events that always link to the previous block with a change for the identity, we can solve this problem with much improved performance. Each identity has its previously changed block stored in the `changed` mapping. 1. Lookup `previousChange` block for identity 2. Lookup all events for given identity address using web3, but only for the `previousChange` block 3. Do something with the event 4. Find `previousChange` from the event and repeat Example code: ```js const history = [] previousChange = await didReg.changed(identity) while (previousChange) { const filter = await didReg.allEvents({topics: [identity], fromBlock: previousChange, toBlock: previousChange}) const events = await getLogs(filter) previousChange = undefined for (let event of events) { history.unshift(event) previousChange = event.args.previousChange } } ``` ### Building a DID document for an identity The primary owner key should be looked up using `identityOwner(identity)`. This should be the first of the publicKeys listed. Iterate through the `DIDDelegateChanged` events to build a list of additional keys and authentication sections as needed. The list of delegateTypes to include is still to be determined. Iterate through `DIDAttributeChanged` events for service entries, encryption public keys and other public names. The attribute names are still to be determined. ## Rationale For on-chain interactions Ethereum has a built in account abstraction that can be used regardless of whether the account is a smart contract or a key pair. Any transaction has a `msg.sender` as the verified send of the transaction. Since each Ethereum transaction has to be funded, there is a growing trend of on-chain transactions that are authenticated via an externally created signature and not by the actual transaction originator. This allows 3rd party funding services or receiver pays without any fundamental changes to the underlying Ethereum architecture. These kinds of transactions have to be signed by an actual key pair and thus can not be used to represent smart contract based Ethereum accounts. We propose a way of a Smart Contract or regular key pair delegating signing for various purposes to externally managed key pairs. This allows a smart contract to be represented both on-chain as well as off-chain or in payment channels through temporary or permanent delegates. ## Backwards Compatibility All ethereum accounts are valid identities (and DID compatible) using this standard. This means that any wallet provider that uses key pair accounts already supports the bare minimum of this standard, and can implement `delegate` and `attribute` functionality by simply using the `ethr-did` referenced below. As the **DID Auth** standard solidifies it also means that all of these wallets will be compatible with the [DID decentralized login system](https://github.com/decentralized-identity). ## Implementation [ethr-did-registry](https://github.com/uport-project/ethr-did-registry/blob/develop/contracts/EthereumDIDRegistry.sol) (`EthereumDIDRegistry` contract implementation) [ethr-did-resolver](https://github.com/uport-project/ethr-did-resolver) (DID compatible resolver) [ethr-did](https://github.com/uport-project/ethr-did) (javascript library for using the identity) ### Deployment The address for the `EthereumDIDRegistry` is `0xdca7ef03e98e0dc2b855be647c39abe984fcf21b` on Mainnet, Ropsten, Rinkeby and Kovan. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 03 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1056 https://eips.ethereum.org/EIPS/eip-1056 ProgPoW, a Programmatic Proof-of-Work Standards Track/Core https://ethereum-magicians.org/t/eip-progpow-a-programmatic-proof-of-work/272 ## Simple Summary A new Proof-of-Work algorithm to replace Ethash that utilizes almost all parts of commodity GPUs. ## Abstract ProgPoW is a proof-of-work algorithm designed to close the efficiency gap available to specialized ASICs. It utilizes almost all parts of commodity hardware (GPUs), and comes pre-tuned for the most common hardware utilized in the Ethereum network. This document presents an overview of the algorithm and examines what it means to be “ASIC-resistant.” Next, we compare existing PoW designs by analyzing how each algorithm executes in hardware. Finally, we present the detailed implementation by walking through the code. ## Motivation Ever since the first bitcoin mining ASIC was released, many new Proof of Work algorithms have been created with the intention of being “ASIC-resistant”. The goal of “ASIC-resistance” is to resist the centralization of PoW mining power such that these coins couldn’t be so easily manipulated by a few players. Ethereum's approach is to incentivize a geographically-distributed community of miners with a low barrier to entry on commodity hardware. As stated in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf): > 11.5. Mining Proof-of-Work. The mining proof-ofwork (PoW) exists as a cryptographically secure nonce that proves beyond reasonable doubt that a particular amount of computation has been expended in the determination of some token value n. It is utilised to enforce the blockchain security by giving meaning and credence to the notion of difficulty (and, by extension, total difficulty). However, since mining new blocks comes with an attached reward, the proof-of-work not only functions as a method of securing confidence that the blockchain will remain canonical into the future, but also as a wealth distribution mechanism. > For both reasons, there are two important goals of the proof-of-work function; firstly, it should be as accessible as possible to as many people as possible. The requirement of, or reward from, specialised and uncommon hardware should be minimised. This makes the distribution model as open as possible, and, ideally, makes the act of mining a simple swap from electricity to Ether at roughly the same rate for anyone around the world. > Secondly, it should not be possible to make super-linear profits, and especially not so with a high initial barrier. Such a mechanism allows a well-funded adversary to gain a troublesome amount of the network’s total mining power and as such gives them a super-linear reward (thus skewing distribution in their favour) as well as reducing the network security... > ... While ASICs exist for a proof-of-work function, both goals are placed in jeopardy. Because of this, a proof-of-work function that is ASIC-resistant (i.e. difficult or economically inefficient to implement in specialised compute hardware) has been identified as the proverbial silver bullet. It is from these premises that Ethash was designed as an ASIC-resistant proof-of-work: > Two directions exist for ASIC resistance; firstly make it sequential memory-hard, i.e. engineer the function such that the determination of the nonce requires a lot of memory and bandwidth such that the memory cannot be used in parallel to discover multiple nonces simultaneously. The second is to make the type of computation it would need to do general-purpose; the meaning of “specialised hardware” for a general-purpose task set is, naturally, general purpose hardware and as such commodity desktop computers are likely to be pretty close to “specialised hardware” for the task. For Ethereum 1.0 we have chosen the first path. 5 years of experience with the Ethereum blockchain have demonstrated the success of our approach. This success cannot be taken for granted. * 11 years of experience with PoW Blockchains have shown a centralization in hardware development, resulting in a [few companies](https://www.asicminervalue.com/) controlling the lifecycle of new hardware with limited distribution. * New ASICs for Ethash are providing higher efficiency than GPUs, such as the [Antminer E3](https://shop.bitmain.com/product/detail?pid=00020181031134626816gh0zYNKC06A3). * As much as 40% of the Ethereum network may now be secured by ASICs. ProgPow restores Ethash' ASIC-resistance by extending Ethash with a GPU-specific approach to the second path — making the “specialised hardware” for the PoW task commodity hardware. ### ProgPoW Overview The design goal of ProgPoW is to have the algorithm’s requirements match what is available on commodity GPUs: If the algorithm were to be implemented on a custom ASIC there should be little opportunity for efficiency gains compared to a commodity GPU. The main elements of the algorithm are: * Changes keccak_f1600 (with 64-bit words) to keccak_f800 (with 32-bit words) to reduce impact on total power * Increases mix state. * Adds a random sequence of math in the main loop. * Adds reads from a small, low-latency cache that supports random addresses. * Increases the DRAM read from 128 bytes to 256 bytes. The random sequence changes every `PROGPOW_PERIOD` (about 2 to 12 minutes depending on the configured value). When mining source code is generated for the random sequence and compiled on the host CPU. The GPU will execute the compiled code where what math to perform and what mix state to use are already resolved. While a custom ASIC to implement this algorithm is still possible, the efficiency gains available are minimal. The majority of a commodity GPU is required to support the above elements. The only optimizations available are: * Remove the graphics pipeline (displays, geometry engines, texturing, etc) * Remove floating point math * A few ISA tweaks, like instructions that exactly match the merge() function These would result in minimal, roughly 1.1-1.2x, efficiency gains. This is much less than the 2x for Ethash or 50x for Cryptonight. ### Rationale for PoW on Commodity Hardware With the growth of large mining pools, the control of hashing power has been delegated to the top few pools to provide a steadier economic return for small miners. While some have made the argument that large centralized pools defeats the purpose of “ASIC resistance,” it’s important to note that ASIC based coins are even more centralized for several reasons. 1. No natural distribution: There isn’t an economic purpose for ultra-specialized hardware outside of mining and thus no reason for most people to have it. 2. No reserve group: Thus, there’s no reserve pool of hardware or reserve pool of interested parties to jump in when coin price is volatile and attractive for manipulation. 3. High barrier to entry: Initial miners are those rich enough to invest capital and ecological resources on the unknown experiment a new coin may be. Thus, initial coin distribution through mining will be very limited causing centralized economic bias. 4. Delegated centralization vs implementation centralization: While pool centralization is delegated, hardware monoculture is not: only the limited buyers of this hardware can participate so there isn’t even the possibility of divesting control on short notice. 5. No obvious decentralization of control even with decentralized mining: Once large custom ASIC makers get into the game, designing back-doored hardware is trivial. ASIC makers have no incentive to be transparent or fair in market participation. While the goal of “ASIC resistance” is valuable, the entire concept of “ASIC resistance” is a bit of a fallacy. CPUs and GPUs are themselves ASICs. Any algorithm that can run on a commodity ASIC (a CPU or GPU) by definition can have a customized ASIC created for it with slightly less functionality. Some algorithms are intentionally made to be “ASIC friendly” - where an ASIC implementation is drastically more efficient than the same algorithm running on general purpose hardware. The protection that this offers when the coin is unknown also makes it an attractive target for a dedicated mining ASIC company as soon as it becomes useful. Therefore, ASIC resistance is: the efficiency difference of specialized hardware versus hardware that has a wider adoption and applicability. A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms. Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated. If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack. ### Review of Existing PoW Algorithms #### SHA256 * Potential ASIC efficiency gain ~ 1000X The SHA algorithm is a sequence of simple math operations - additions, logical ops, and rotates. To process a single op on a CPU or GPU requires fetching and decoding an instruction, reading data from a register file, executing the instruction, and then writing the result back to a register file. This takes significant time and power. A single op implemented in an ASIC takes a handful of transistors and wires. This means every individual op takes negligible power, area, or time. A hashing core is built by laying out the sequence of required ops. The hashing core can execute the required sequence of ops in much less time, and using less power or area, than doing the same sequence on a CPU or GPU. A bitcoin ASIC consists of a number of identical hashing cores and some minimal off-chip communication. #### Scrypt and NeoScrypt * Potential ASIC efficiency gain ~ 1000X Scrypt and NeoScrypt are similar to SHA in the arithmetic and bitwise operations used. Unfortunately, popular coins such as Litecoin only use a scratchpad size between 32kb and 128kb for their PoW mining algorithm. This scratch pad is small enough to trivially fit on an ASIC next to the math core. The implementation of the math core would be very similar to SHA, with similar efficiency gains. #### X11 and X16R * Potential ASIC efficiency gain ~ 1000X X11 (and similar X##) require an ASIC that has 11 unique hashing cores pipelined in a fixed sequence. Each individual hashing core would have similar efficiency to an individual SHA core, so the overall design will have the same efficiency gains. X16R requires the multiple hashing cores to interact through a simple sequencing state machine. Each individual core will have similar efficiency gains and the sequencing logic will take minimal power, area, or time. The Baikal BK-X is an existing ASIC with multiple hashing cores and a programmable sequencer. It has been upgraded to enable new algorithms that sequence the hashes in different orders. #### Equihash * Potential ASIC efficiency gain ~ 100X The ~150mb of state is large but possible on an ASIC. The binning, sorting, and comparing of bit strings could be implemented on an ASIC at extremely high speed. #### Cuckoo Cycle * Potential ASIC efficiency gain ~ 100X The amount of state required on-chip is not clear as there are Time/Memory Tradeoff attacks. A specialized graph traversal core would have similar efficiency gains to a SHA compute core. #### CryptoNight * Potential ASIC efficiency gain ~ 50X Compared to Scrypt, CryptoNight does much less compute and requires a full 2mb of scratch pad (there is no known Time/Memory Tradeoff attack). The large scratch pad will dominate the ASIC implementation and limit the number of hashing cores, limiting the absolute performance of the ASIC. An ASIC will consist almost entirely of just on-die SRAM. #### Ethash * Potential ASIC efficiency gain ~ 2X Ethash requires external memory due to the large size of the DAG. However that is all that it requires - there is minimal compute that is done on the result loaded from memory. As a result a custom ASIC could remove most of the complexity, and power, of a GPU and be just a memory interface connected to a small compute engine. ## Specification ProgPoW can be tuned using the following parameters. The proposed settings have been tuned for a range of existing, commodity GPUs: * `PROGPOW_PERIOD`: Number of blocks before changing the random program * `PROGPOW_LANES`: The number of parallel lanes that coordinate to calculate a single hash instance * `PROGPOW_REGS`: The register file usage size * `PROGPOW_DAG_LOADS`: Number of uint32 loads from the DAG per lane * `PROGPOW_CACHE_BYTES`: The size of the cache * `PROGPOW_CNT_DAG`: The number of DAG accesses, defined as the outer loop of the algorithm (64 is the same as Ethash) * `PROGPOW_CNT_CACHE`: The number of cache accesses per loop * `PROGPOW_CNT_MATH`: The number of math operations per loop The values of these parameters have been tweaked between the original version and the version proposed here for Ethereum adoption. See [this medium post](https://medium.com/@ifdefelse/progpow-progress-da5bb31a651b) for details. | Parameter | 0.9.2 | 0.9.3 | |-----------------------|-------|-------| | `PROGPOW_PERIOD` | `50` | `10` | | `PROGPOW_LANES` | `16` | `16` | | `PROGPOW_REGS` | `32` | `32` | | `PROGPOW_DAG_LOADS` | `4` | `4` | | `PROGPOW_CACHE_BYTES` | `16x1024` | `16x1024` | | `PROGPOW_CNT_DAG` | `64` | `64` | `64` | | `PROGPOW_CNT_CACHE` | `12` | `11` | `11` | | `PROGPOW_CNT_MATH` | `20` | `18` | `18` | | DAG Parameter | 0.9.2 | 0.9.3 | |--------------------------|-------|-------| | `ETHASH_DATASET_PARENTS` | `256` | `256` | The random program changes every `PROGPOW_PERIOD` blocks (default `10`, roughly 2 minutes) to ensure the hardware executing the algorithm is fully programmable. If the program only changed every DAG epoch (roughly 5 days) certain miners could have time to develop hand-optimized versions of the random sequence, giving them an undue advantage. Sample code is written in C++, this should be kept in mind when evaluating the code in the specification. All numerics are computed using unsigned 32 bit integers. Any overflows are trimmed off before proceeding to the next computation. Languages that use numerics not fixed to bit lengths (such as Python and JavaScript) or that only use signed integers (such as Java) will need to keep their languages' quirks in mind. The extensive use of 32 bit data values aligns with modern GPUs internal data architectures. ProgPoW uses a 32-bit variant of **FNV1a** for merging data. The existing Ethash uses a similar variant of FNV1 for merging, but FNV1a provides better distribution properties. Test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#fnv1a). ```cpp const uint32_t FNV_PRIME = 0x1000193; const uint32_t FNV_OFFSET_BASIS = 0x811c9dc5; uint32_t fnv1a(uint32_t h, uint32_t d) { return (h ^ d) * FNV_PRIME; } ``` ProgPow uses [KISS99](https://en.wikipedia.org/wiki/KISS_(algorithm)) for random number generation. This is the simplest (fewest instruction) random generator that passes the TestU01 statistical test suite. A more complex random number generator like Mersenne Twister can be efficiently implemented on a specialized ASIC, providing an opportunity for efficiency gains. Test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#kiss99). ```cpp typedef struct { uint32_t z, w, jsr, jcong; } kiss99_t; // KISS99 is simple, fast, and passes the TestU01 suite // https://en.wikipedia.org/wiki/KISS_(algorithm) // http://www.cse.yorku.ca/~oz/marsaglia-rng.html uint32_t kiss99(kiss99_t &st) { st.z = 36969 * (st.z & 65535) + (st.z >> 16); st.w = 18000 * (st.w & 65535) + (st.w >> 16); uint32_t MWC = ((st.z << 16) + st.w); st.jsr ^= (st.jsr << 17); st.jsr ^= (st.jsr >> 13); st.jsr ^= (st.jsr << 5); st.jcong = 69069 * st.jcong + 1234567; return ((MWC^st.jcong) + st.jsr); } ``` The `fill_mix` function populates an array of `int32` values used by each lane in the hash calculations. Test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#fill_mix). ```cpp void fill_mix( uint64_t seed, uint32_t lane_id, uint32_t mix[PROGPOW_REGS] ) { // Use FNV to expand the per-warp seed to per-lane // Use KISS to expand the per-lane seed to fill mix uint32_t fnv_hash = FNV_OFFSET_BASIS; kiss99_t st; st.z = fnv1a(fnv_hash, seed); st.w = fnv1a(fnv_hash, seed >> 32); st.jsr = fnv1a(fnv_hash, lane_id); st.jcong = fnv1a(fnv_hash, lane_id); for (int i = 0; i < PROGPOW_REGS; i++) mix[i] = kiss99(st); } ``` Like Ethash Keccak is used to seed the sequence per-nonce and to produce the final result. The keccak-f800 variant is used as the 32-bit word size matches the native word size of modern GPUs. The implementation is a variant of SHAKE with width=800, bitrate=576, capacity=224, output=256, and no padding. The result of keccak is treated as a 256-bit big-endian number - that is result byte 0 is the MSB of the value. As with Ethash the input and output of the keccak function are fixed and relatively small. This means only a single "absorb" and "squeeze" phase are required. For a pseudo-code implementation of the `keccak_f800_round` function see the `Round[b](A,RC)` function in the "Pseudo-code description of the permutations" section of the [official Keccak specs](https://keccak.team/keccak_specs_summary.html). ```cpp hash32_t keccak_f800_progpow(uint32_t* state) { // keccak_f800 call for the single absorb pass for (int r = 0; r < 22; r++) keccak_f800_round(st, r); // Squeeze phase for fixed 8 words of output hash32_t ret; for (int i=0; i<8; i++) ret.uint32s[i] = st[i]; return ret; } ``` The inner loop uses FNV and KISS99 to generate a random sequence from the `prog_seed`. This random sequence determines which mix state is accessed and what random math is performed. Since the `prog_seed` changes only once per `PROGPOW_PERIOD` (10 blocks or about 2 minutes) it is expected that while mining `progPowLoop` will be evaluated on the CPU to generate source code for that period's sequence. The source code will be compiled on the CPU before running on the GPU. You can see an example sequence and generated source code in [kernel.cu](https://github.com/ifdefelse/ProgPOW/blob/824cd791634204c4cc7e31f84bb76c0c84895bd3/test/kernel.cu). Test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#progpowinit). ```cpp kiss99_t progPowInit(uint64_t prog_seed, int mix_seq_dst[PROGPOW_REGS], int mix_seq_src[PROGPOW_REGS]) { kiss99_t prog_rnd; prog_rnd.z = fnv1a(FNV_OFFSET_BASIS, prog_seed); prog_rnd.w = fnv1a(prog_rnd.z, prog_seed >> 32); prog_rnd.jsr = fnv1a(prog_rnd.w, prog_seed); prog_rnd.jcong = fnv1a(prog_rnd.jsr, prog_seed >> 32); // Create a random sequence of mix destinations for merge() and mix sources for cache reads // guarantees every destination merged once // guarantees no duplicate cache reads, which could be optimized away // Uses Fisher-Yates shuffle for (int i = 0; i < PROGPOW_REGS; i++) { mix_seq_dst[i] = i; mix_seq_src[i] = i; } for (int i = PROGPOW_REGS - 1; i > 0; i--) { int j; j = kiss99(prog_rnd) % (i + 1); swap(mix_seq_dst[i], mix_seq_dst[j]); j = kiss99(prog_rnd) % (i + 1); swap(mix_seq_src[i], mix_seq_src[j]); } return prog_rnd; } ``` The math operations that merges values into the mix data are ones chosen to maintain entropy. Test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#math). ```cpp // Merge new data from b into the value in a // Assuming A has high entropy only do ops that retain entropy // even if B is low entropy // (IE don't do A&B) uint32_t merge(uint32_t a, uint32_t b, uint32_t r) { switch (r % 4) { case 0: return (a * 33) + b; case 1: return (a ^ b) * 33; // prevent rotate by 0 which is a NOP case 2: return ROTL32(a, ((r >> 16) % 31) + 1) ^ b; case 3: return ROTR32(a, ((r >> 16) % 31) + 1) ^ b; } } ``` The math operations chosen for the random math are ones that are easy to implement in CUDA and OpenCL, the two main programming languages for commodity GPUs. The [mul_hi](https://www.khronos.org/registry/OpenCL/sdk/1.1/docs/man/xhtml/mul_hi.html), [min](https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/integerMax.html), [clz](https://www.khronos.org/registry/OpenCL/sdk/1.1/docs/man/xhtml/clz.html), and [popcount](https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/popcount.html) functions match the corresponding OpenCL functions. ROTL32 matches the OpenCL [rotate](https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/rotate.html) function. ROTR32 is rotate right, which is equivalent to `rotate(i, 32-v)`. Test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#math). ```cpp // Random math between two input values uint32_t math(uint32_t a, uint32_t b, uint32_t r) { switch (r % 11) { case 0: return a + b; case 1: return a * b; case 2: return mul_hi(a, b); case 3: return min(a, b); case 4: return ROTL32(a, b); case 5: return ROTR32(a, b); case 6: return a & b; case 7: return a | b; case 8: return a ^ b; case 9: return clz(a) + clz(b); case 10: return popcount(a) + popcount(b); } } ``` The flow of the inner loop is: * Lane `(loop % LANES)` is chosen as the leader for that loop iteration * The leader's `mix[0]` value modulo the number of 256-byte DAG entries is used to select where to read from the full DAG * Each lane reads `DAG_LOADS` sequential words, using `(lane ^ loop) % LANES` as the starting offset within the entry. * The random sequence of math and cache accesses is performed * The DAG data read at the start of the loop is merged at the end of the loop `prog_seed` and `loop` come from the outer loop, corresponding to the current program seed (which is block_number/PROGPOW_PERIOD) and the loop iteration number. `mix` is the state array, initially filled by `fill_mix`. `dag` is the bytes of the Ethash DAG grouped into 32 bit unsigned ints in little-endian format. On little-endian architectures this is just a normal int32 pointer to the existing DAG. `DAG_BYTES` is set to the number of bytes in the current DAG, which is generated identically to the existing Ethash algorithm. Test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#progpowloop). ```cpp void progPowLoop( const uint64_t prog_seed, const uint32_t loop, uint32_t mix[PROGPOW_LANES][PROGPOW_REGS], const uint32_t *dag) { // dag_entry holds the 256 bytes of data loaded from the DAG uint32_t dag_entry[PROGPOW_LANES][PROGPOW_DAG_LOADS]; // On each loop iteration rotate which lane is the source of the DAG address. // The source lane's mix[0] value is used to ensure the last loop's DAG data feeds into this loop's address. // dag_addr_base is which 256-byte entry within the DAG will be accessed uint32_t dag_addr_base = mix[loop%PROGPOW_LANES][0] % (DAG_BYTES / (PROGPOW_LANES*PROGPOW_DAG_LOADS*sizeof(uint32_t))); for (int l = 0; l < PROGPOW_LANES; l++) { // Lanes access DAG_LOADS sequential words from the dag entry // Shuffle which portion of the entry each lane accesses each iteration by XORing lane and loop. // This prevents multi-chip ASICs from each storing just a portion of the DAG size_t dag_addr_lane = dag_addr_base * PROGPOW_LANES + (l ^ loop) % PROGPOW_LANES; for (int i = 0; i < PROGPOW_DAG_LOADS; i++) dag_entry[l][i] = dag[dag_addr_lane * PROGPOW_DAG_LOADS + i]; } // Initialize the program seed and sequences // When mining these are evaluated on the CPU and compiled away int mix_seq_dst[PROGPOW_REGS]; int mix_seq_src[PROGPOW_REGS]; int mix_seq_dst_cnt = 0; int mix_seq_src_cnt = 0; kiss99_t prog_rnd = progPowInit(prog_seed, mix_seq_dst, mix_seq_src); int max_i = max(PROGPOW_CNT_CACHE, PROGPOW_CNT_MATH); for (int i = 0; i < max_i; i++) { if (i < PROGPOW_CNT_CACHE) { // Cached memory access // lanes access random 32-bit locations within the first portion of the DAG int src = mix_seq_src[(mix_seq_src_cnt++)%PROGPOW_REGS]; int dst = mix_seq_dst[(mix_seq_dst_cnt++)%PROGPOW_REGS]; int sel = kiss99(prog_rnd); for (int l = 0; l < PROGPOW_LANES; l++) { uint32_t offset = mix[l][src] % (PROGPOW_CACHE_BYTES/sizeof(uint32_t)); mix[l][dst] = merge(mix[l][dst], dag[offset], sel); } } if (i < PROGPOW_CNT_MATH) { // Random Math // Generate 2 unique sources int src_rnd = kiss99(prog_rnd) % (PROGPOW_REGS * (PROGPOW_REGS-1)); int src1 = src_rnd % PROGPOW_REGS; // 0 <= src1 < PROGPOW_REGS int src2 = src_rnd / PROGPOW_REGS; // 0 <= src2 < PROGPOW_REGS - 1 if (src2 >= src1) ++src2; // src2 is now any reg other than src1 int sel1 = kiss99(prog_rnd); int dst = mix_seq_dst[(mix_seq_dst_cnt++)%PROGPOW_REGS]; int sel2 = kiss99(prog_rnd); for (int l = 0; l < PROGPOW_LANES; l++) { uint32_t data = math(mix[l][src1], mix[l][src2], sel1); mix[l][dst] = merge(mix[l][dst], data, sel2); } } } // Consume the global load data at the very end of the loop to allow full latency hiding // Always merge into mix[0] to feed the offset calculation for (int i = 0; i < PROGPOW_DAG_LOADS; i++) { int dst = (i==0) ? 0 : mix_seq_dst[(mix_seq_dst_cnt++)%PROGPOW_REGS]; int sel = kiss99(prog_rnd); for (int l = 0; l < PROGPOW_LANES; l++) mix[l][dst] = merge(mix[l][dst], dag_entry[l][i], sel); } } ``` The flow of the overall algorithm is: * A keccak hash of the header + nonce to create a digest of 256 bits from keccak_f800 (padding is consistent with custom one in ethash) * Use first two words of digest as seed to generate initial mix data * Loop multiple times, each time hashing random loads and random math into the mix data * Hash all the mix data into a single 256-bit value * A final keccak hash using carry-over digest from initial data + mix_data final 256 bit value (padding is consistent with custom one in ethash) * When mining this final value is compared against a `hash32_t` target ```cpp hash32_t progPowHash( const uint64_t prog_seed, // value is (block_number/PROGPOW_PERIOD) const uint64_t nonce, const hash32_t header, const uint32_t *dag // gigabyte DAG located in framebuffer - the first portion gets cached ) { hash32_t hash_init; hash32_t hash_final; uint32_t mix[PROGPOW_LANES][PROGPOW_REGS]; /* ======================================== Absorb phase for initial keccak pass ======================================== */ { uint32_t state[25] = {0x0}; // 1st fill with header data (8 words) for (int i = 0; i < 8; i++) state[i] = header.uint32s[i]; // 2nd fill with nonce (2 words) state[8] = nonce; state[9] = nonce >> 32; // 3rd apply padding state[10] = 0x00000001; state[18] = 0x80008081; // keccak(header..nonce) hash_init = keccak_f800_progpow(state); // get the seed to initialize mix seed = ((uint64_t)hash_init.uint32s[1] << 32) | hash_init.uint32s[0]); } // initialize mix for all lanes for (int l = 0; l < PROGPOW_LANES; l++) fill_mix(seed, l, mix[l]); // execute the randomly generated inner loop for (int i = 0; i < PROGPOW_CNT_DAG; i++) progPowLoop(prog_seed, i, mix, dag); // Reduce mix data to a per-lane 32-bit digest uint32_t digest_lane[PROGPOW_LANES]; for (int l = 0; l < PROGPOW_LANES; l++) { digest_lane[l] = FNV_OFFSET_BASIS; for (int i = 0; i < PROGPOW_REGS; i++) digest_lane[l] = fnv1a(digest_lane[l], mix[l][i]); } // Reduce all lanes to a single 256-bit digest for (int i = 0; i < 8; i++) digest.uint32s[i] = FNV_OFFSET_BASIS; for (int l = 0; l < PROGPOW_LANES; l++) digest.uint32s[l%8] = fnv1a(digest.uint32s[l%8], digest_lane[l]); /* ======================================== Absorb phase for final keccak pass ======================================== */ { uint32_t state[25] = {0x0}; // 1st fill with hash_init (8 words) for (int i = 0; i < 8; i++) state[i] = hash_init.uint32s[i]; // 2nd fill with digest from main loop for (int i = 8; i < 16; i++) state[i] = digest.uint32s[i - 8]; // 3rd apply padding state[17] = 0x00000001; state[24] = 0x80008081; // keccak(header..nonce) hash_final = keccak_f800_progpow(state); } // Compare hash final to target [...] } ``` ## Security Considerations This proposal has been software and hardware audited: * [Least Authority — ProgPoW Software Audit PDF](https://leastauthority.com/static/publications/LeastAuthority-ProgPow-Algorithm-Final-Audit-Report.pdf) * [Bob Rao - ProgPoW Hardware Audit PDF](https://github.com/ethereum-cat-herders/progpow-audit/raw/master/Bob%20Rao%20-%20ProgPOW%20Hardware%20Audit%20Report%20Final.pdf) Least Authority in their findings suggest a change to DAG generation -- modification of `ETHASH_DATASET_PARENTS` from a value of 256 to the new value of 512 -- in order to mitigate vulnerability to a "Light Evaluation" attack. Due to this the DAG memory file used by ProgPoW is would no longer compatible with the one used by Ethash (epoch length and size increase ratio remain the same though). We do not recommend implementing this fix at this time. Ethash will not be exploitable for years, and it's not clear ProgPoW will ever be exploitable. It's better to deploy the audited code. After the completion of the audits a clever finding by [Kik](https://github.com/kik/) disclosed a vulnerability to [bypassing ProgPoW memory hardness](https://github.com/kik/progpow-exploit). The vulnerability is present in Ethash as well but is near-impossible to exploit. In progPoW it is not possible to exploit -- it assumes the ability to create variants of the candidate block's header hash in a fashion similar to bitcoin, which is actually not possible in Ethereum. An attacker would need modified block headers, would need customized nodes able to accept the modified block headers, and uses extraNonce/extraData as entropy -- which isn’t the standard. And the required brute-force search would be difficult to accomplish in one blocktime. And even if supported by a customized node the block propagation of such mined blocks would be immediately blocked by other peers as the header hash is invalid. The authors have since found another vulnerability similar to Kik's, but it adds too much overhead to be ASIC-friendly. See Lanfranchi's full explanation [here](https://github.com/ifdefelse/ProgPOW/issues/51#issuecomment-690155355). To completely prevent such exploits we could change the condition modifying the input state of the last keccak pass from * header (256 bits) + * seed for mix initiator (64 bits) + * mix from main loop (256 bits) * no padding to * digest from initial keccak (256 bits) + * mix from main loop (256 bits) + * padding thus widening the constraint to target in keccak [brute force keccak linear searches](https://github.com/kik/progpow-exploit) from 64 to 256 bits. This fix is available as a PR to the reference implementation. Again, we do not recommend implementing this fix at this time. Kik's vulnerability and others like it cannot be exploited now and likely never will be. It's better to deploy the audited code. Note that these vulnerabilities cannot be exploited to deny service, double spend, or otherwise damage the network. They could at worst give their deployer an efficiency advantage over other miners. ## Test Cases The random sequence generated for block 30,000 (prog_seed 3,000) can been seen in [kernel.cu](https://github.com/ifdefelse/ProgPOW/blob/824cd791634204c4cc7e31f84bb76c0c84895bd3/test/kernel.cu). The algorithm run on block 30,000 produces the following digest and result: ``` Header : 0xffeeddccbbaa9988776655443322110000112233445566778899aabbccddeeff Nonce : 0x123456789abcdef0 Hash init : 0xee304846ddd0a47b98179e96b60ec5ceeae2727834367e593de780e3e6d1892f Mix seed : 0x7ba4d0dd464830ee Mix hash : 0x493c13e9807440571511b561132834bbd558dddaa3b70c09515080a6a1aff6d0 Hash final : 0x46b72b75f238bea3fcfd227e0027dc173dceaa1fb71744bd3d5e030ed2fed053 ``` Additional test vectors can be found [in the test vectors file](/assets/eip-1057/test-vectors#progpowhash). Machine-readable test vectors (T.B.D) ## Implementation The reference ProgPoW mining implementation is located at [the @ifdefelse ProgPOW repository](https://github.com/ifdefelse/ProgPOW). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). The reference ProgPoW mining implementation located at [ProgPOW](https://github.com/ifdefelse/ProgPOW) is a derivative of ethminer so retains the GPL license. Wed, 02 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1057 https://eips.ethereum.org/EIPS/eip-1057 Formalize IPFS hash into ENS(Ethereum Name Service) resolver Standards Track/ERC https://ethereum-magicians.org/t/eip-1062-formalize-ipfs-hash-into-ens-ethereum-name-service-resolver/281 ## Simple Summary To specify the mapping protocol between resources stored on IPFS and ENS(Ethereum Naming Service). ## Abstract The following standard details the implementation of how to combine the IPFS cryptographic hash unique fingerprint with ENS public resolver. This standard provides a functionality to get and set IPFS online resources to ENS resolver. We think that this implementation is not only aim to let more developers and communities to provide more use cases, but also leverage the human-readable features to gain more user adoption accessing decentralized resources. We considered the IPFS ENS resolver mapping standard a cornerstone for building future Web3.0 service. ## Motivation To build a fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages : - Address large amounts of data, and has unique cryptographic hash for every record. - Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, in a safer way and lower the millions of cost for the bandwidth. - IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network. Those features makes perfect match for integrating into ENS, and these make users can easily access content through ENS, and show up in the normal browser. ## Specification The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum uses hex in API to encode the binary data. So that need a way to process the condition requires not only we need to transfer from IPFS to Ethereum, but also need to convert it back. To solve these requirements, we can use binary buffer bridging that gap. When mapping the IPFS base58 string to ENS resolver, first we convert the Base58 to binary buffer, turn the buffer to hex encrypted format, and save to the contract. Once we want to get the IPFS resources address represented by the specific ENS, we can first find the mapping information stored as hex format before, extract the hex format to binary buffer, and finally turn that to IPFS Base58 address string. ## Rationale To implement the specification, need two methods from ENS public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the `setMultihash` method below : ```solidity function setMultihash(bytes32 node, bytes hash) public only_owner(node); ``` Whenever users need to visit the ENS content, we call the `multihash` method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use. ```solidity function multihash(bytes32 node) public view returns (bytes); ``` ## Test Cases To implement the way to transfer from base58 to hex format and the reverse one, using the ‘multihashes’ library to deal with the problem. The library link : [https://www.npmjs.com/package/multihashes](https://www.npmjs.com/package/multihashes) To implement the method transfer from IPFS(Base58) to hex format : ```javascript import multihash from 'multihashes' export const toHex = function(ipfsHash) { let buf = multihash.fromB58String(ipfsHash); return '0x' + multihash.toHexString(buf); } ``` To implement the method transfer from hex format to IPFS(Base58) : ```javascript import multihash from 'multihashes' export const toBase58 = function(contentHash) { let hex = contentHash.substring(2) let buf = multihash.fromHexString(hex); return multihash.toB58String(buf); } ``` ## Implementation The use case can be implemented as browser extension. Users can easily download the extension, and easily get decentralized resources by just typing the ENS just like we normally type the DNS to browser the website. Solve the current pain for normal people can not easily visit the total decentralized website. The workable implementation repository : [https://github.com/PortalNetwork/portal-network-browser-extension](https://github.com/PortalNetwork/portal-network-browser-extension) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 02 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1062 https://eips.ethereum.org/EIPS/eip-1062 Status Codes Standards Track/ERC https://ethereum-magicians.org/t/erc-1066-ethereum-status-codes-esc/ ## Simple Summary Broadly applicable status codes for smart contracts. ## Abstract This standard outlines a common set of status codes in a similar vein to HTTP statuses. This provides a shared set of signals to allow smart contracts to react to situations autonomously, expose localized error messages to users, and so on. The current state of the art is to either `revert` on anything other than a clear success (ie: require human intervention), or return a low-context `true` or `false`. Status codes are similar-but-orthogonal to `revert`ing with a reason, but aimed at automation, debugging, and end-user feedback (including translation). _They are fully compatible with both `revert` and `revert`-with-reason._ As is the case with HTTP, having a standard set of known codes has many benefits for developers. They remove friction from needing to develop your own schemes for every contract, makes inter-contract automation easier, and makes it easier to broadly understand which of the finite states your request produced. Importantly, it makes it much easier to distinguish between expected errors states, truly exceptional conditions that require halting execution, normal state transitions, and various success cases. ## Motivation ### Semantic Density HTTP status codes are widely used for this purpose. BEAM languages use atoms and tagged tuples to signify much the same information. Both provide a lot of information both to the programmer (debugging for instance), and to the program that needs to decide what to do next. Status codes convey a much richer set of information [than Booleans](https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/), and are able to be reacted to autonomously unlike arbitrary strings. ### User Experience (UX) _End users get little to no feedback, and there is no translation layer._ Since ERC1066 status codes are finite and known in advance, we can leverage [ERC-1444](/EIPS/eip-1444) to provide global, human-readable sets of status messages. These may also be translated into any language, differing levels of technical detail, added as `revert` messages, natspecs, and so on. Status codes convey a much richer set of information than Booleans, and are able to be reacted to autonomously unlike arbitrary strings. ### Developer Experience (DX) _Developers currently have very little context exposed by their smart contracts._ At time of writing, other than stepping through EVM execution and inspecting memory dumps directly, it is very difficult to understand what is happening during smart contract execution. By returning more context, developers can write well-decomposed tests and assert certain codes are returned as an expression of where the smart contract got to. This includes status codes as bare values, `event`s, and `revert`s. Having a fixed set of codes also makes it possible to write common helper functions to react in common ways to certain signals. This can live off- or on-chain library, lowering the overhead in building smart contracts, and helping raise code quality with trusted shared components. We also see a desire for this [in transactions](/EIPS/eip-658), and there's no reason that these status codes couldn't be used by the EVM itself. ### Smart Contract Autonomy _Smart contracts don’t know much about the result of a request beyond pass/fail; they can be smarter with more context._ Smart contracts are largely intended to be autonomous. While each contract may define a specific interface, having a common set of semantic codes can help developers write code that can react appropriately to various situations. While clearly related, status codes are complementary to `revert`-with-reason. Status codes are not limited to rolling back the transaction, and may represent known error states without halting execution. They may also represent off-chain conditions, supply a string to revert, signal time delays, and more. All of this enables contracts to share a common vocabulary of state transitions, results, and internal changes, without having to deeply understand custom status enums or the internal business logic of collaborator contracts. ## Specification ### Format Codes are returned either on their own, or as the first value of a multiple return. ```solidity // Status only function isInt(uint num) public pure returns (byte status) { return hex"01"; } // Status and value uint8 private counter; function safeIncrement(uint8 interval) public returns (byte status, uint8 newCounter) { uint8 updated = counter + interval; if (updated >= counter) { counter = updated; return (hex"01", updated); } else { return (hex"00", counter); } } ``` ### Code Table Codes break nicely into a 16x16 matrix, represented as a 2-digit hex number. The high nibble represents the code's kind or "category", and the low nibble contains the state or "reason". We present them below as separate tables per range for explanatory and layout reasons. **NB: Unspecified codes are _not_ free for arbitrary use, but rather open for further specification.** #### `0x0*` Generic General codes. These double as bare "reasons", since `0x01 == 1`. | Code | Description | |--------|-----------------------------------------| | `0x00` | Failure | | `0x01` | Success | | `0x02` | Awaiting Others | | `0x03` | Accepted | | `0x04` | Lower Limit or Insufficient | | `0x05` | Receiver Action Requested | | `0x06` | Upper Limit | | `0x07` | [reserved] | | `0x08` | Duplicate, Unnecessary, or Inapplicable | | `0x09` | [reserved] | | `0x0A` | [reserved] | | `0x0B` | [reserved] | | `0x0C` | [reserved] | | `0x0D` | [reserved] | | `0x0E` | [reserved] | | `0x0F` | Informational or Metadata | #### `0x1*` Permission & Control Also used for common state machine actions (ex. "stoplight" actions). | Code | Description | |--------|---------------------------------------------------| | `0x10` | Disallowed or Stop | | `0x11` | Allowed or Go | | `0x12` | Awaiting Other's Permission | | `0x13` | Permission Requested | | `0x14` | Too Open / Insecure | | `0x15` | Needs Your Permission or Request for Continuation | | `0x16` | Revoked or Banned | | `0x17` | [reserved] | | `0x18` | Not Applicable to Current State | | `0x19` | [reserved] | | `0x1A` | [reserved] | | `0x1B` | [reserved] | | `0x1C` | [reserved] | | `0x1D` | [reserved] | | `0x1E` | [reserved] | | `0x1F` | Permission Details or Control Conditions | #### `0x2*` Find, Inequalities & Range This range is broadly intended for finding and matching. Data lookups and order matching are two common use cases. | Code | Description | |--------|-------------------------------------| | `0x20` | Not Found, Unequal, or Out of Range | | `0x21` | Found, Equal or In Range | | `0x22` | Awaiting Match | | `0x23` | Match Request Sent | | `0x24` | Below Range or Underflow | | `0x25` | Request for Match | | `0x26` | Above Range or Overflow | | `0x27` | [reserved] | | `0x28` | Duplicate, Conflict, or Collision | | `0x29` | [reserved] | | `0x2A` | [reserved] | | `0x2B` | [reserved] | | `0x2C` | [reserved] | | `0x2D` | [reserved] | | `0x2E` | [reserved] | | `0x2F` | Matching Meta or Info | #### `0x3*` Negotiation & Governance Negotiation, and very broadly the flow of such transactions. Note that "other party" may be more than one actor (not necessarily the sender). | Code | Description | |--------|-----------------------------------------| | `0x30` | Sender Disagrees or Nay | | `0x31` | Sender Agrees or Yea | | `0x32` | Awaiting Ratification | | `0x33` | Offer Sent or Voted | | `0x34` | Quorum Not Reached | | `0x35` | Receiver's Ratification Requested | | `0x36` | Offer or Vote Limit Reached | | `0x37` | [reserved] | | `0x38` | Already Voted | | `0x39` | [reserved] | | `0x3A` | [reserved] | | `0x3B` | [reserved] | | `0x3C` | [reserved] | | `0x3D` | [reserved] | | `0x3E` | [reserved] | | `0x3F` | Negotiation Rules or Participation Info | #### `0x4*` Availability & Time Service or action availability. | Code | Description | |--------|------------------------------------------------------| | `0x40` | Unavailable | | `0x41` | Available | | `0x42` | Paused | | `0x43` | Queued | | `0x44` | Not Available Yet | | `0x45` | Awaiting Your Availability | | `0x46` | Expired | | `0x47` | [reserved] | | `0x48` | Already Done | | `0x49` | [reserved] | | `0x4A` | [reserved] | | `0x4B` | [reserved] | | `0x4C` | [reserved] | | `0x4D` | [reserved] | | `0x4E` | [reserved] | | `0x4F` | Availability Rules or Info (ex. time since or until) | #### `0x5*` Tokens, Funds & Finance Special token and financial concepts. Many related concepts are included in other ranges. | Code | Description | |--------|---------------------------------| | `0x50` | Transfer Failed | | `0x51` | Transfer Successful | | `0x52` | Awaiting Payment From Others | | `0x53` | Hold or Escrow | | `0x54` | Insufficient Funds | | `0x55` | Funds Requested | | `0x56` | Transfer Volume Exceeded | | `0x57` | [reserved] | | `0x58` | Funds Not Required | | `0x59` | [reserved] | | `0x5A` | [reserved] | | `0x5B` | [reserved] | | `0x5C` | [reserved] | | `0x5D` | [reserved] | | `0x5E` | [reserved] | | `0x5F` | Token or Financial Information | #### `0x6*` TBD Currently unspecified. (Full range reserved) #### `0x7*` TBD Currently unspecified. (Full range reserved) #### `0x8*` TBD Currently unspecified. (Full range reserved) #### `0x9*` TBD Currently unspecified. (Full range reserved) #### `0xA*` Application-Specific Codes Contracts may have special states that they need to signal. This proposal only outlines the broadest meanings, but implementers may have very specific meanings for each, as long as they are coherent with the broader definition. | Code | Description | |--------|----------------------------------------| | `0xA0` | App-Specific Failure | | `0xA1` | App-Specific Success | | `0xA2` | App-Specific Awaiting Others | | `0xA3` | App-Specific Acceptance | | `0xA4` | App-Specific Below Condition | | `0xA5` | App-Specific Receiver Action Requested | | `0xA6` | App-Specific Expiry or Limit | | `0xA7` | [reserved] | | `0xA8` | App-Specific Inapplicable Condition | | `0xA9` | [reserved] | | `0xAA` | [reserved] | | `0xAB` | [reserved] | | `0xAC` | [reserved] | | `0xAD` | [reserved] | | `0xAE` | [reserved] | | `0xAF` | App-Specific Meta or Info | #### `0xB*` TBD Currently unspecified. (Full range reserved) #### `0xC*` TBD Currently unspecified. (Full range reserved) #### `0xD*` TBD Currently unspecified. (Full range reserved) #### `0xE*` Encryption, Identity & Proofs Actions around signatures, cryptography, signing, and application-level authentication. The meta code `0xEF` is often used to signal a payload describing the algorithm or process used. | Code | Description | |--------|-------------------------------------| | `0xE0` | Decrypt Failure | | `0xE1` | Decrypt Success | | `0xE2` | Awaiting Other Signatures or Keys | | `0xE3` | Signed | | `0xE4` | Unsigned or Untrusted | | `0xE5` | Signature Required | | `0xE6` | Known to be Compromised | | `0xE7` | [reserved] | | `0xE8` | Already Signed or Not Encrypted | | `0xE9` | [reserved] | | `0xEA` | [reserved] | | `0xEB` | [reserved] | | `0xEC` | [reserved] | | `0xED` | [reserved] | | `0xEE` | [reserved] | | `0xEF` | Cryptography, ID, or Proof Metadata | #### `0xF*` Off-Chain For off-chain actions. Much like th `0x0*: Generic` range, `0xF*` is very general, and does little to modify the reason. Among other things, the meta code `0xFF` may be used to describe what the off-chain process is. | Code | Description | |--------|-----------------------------------| | `0xF0` | Off-Chain Failure | | `0xF1` | Off-Chain Success | | `0xF2` | Awaiting Off-Chain Process | | `0xF3` | Off-Chain Process Started | | `0xF4` | Off-Chain Service Unreachable | | `0xF5` | Off-Chain Action Required | | `0xF6` | Off-Chain Expiry or Limit Reached | | `0xF7` | [reserved] | | `0xF8` | Duplicate Off-Chain Request | | `0xF9` | [reserved] | | `0xFA` | [reserved] | | `0xFB` | [reserved] | | `0xFC` | [reserved] | | `0xFD` | [reserved] | | `0xFE` | [reserved] | | `0xFF` | Off-Chain Info or Meta | ### As a Grid | | `0x0*` General | `0x1*` Permission & Control | `0x2*` Find, Inequalities & Range | `0x3*` Negotiation & Governance | `0x4*` Availability & Time | `0x5*` Tokens, Funds & Finance | `0x6*` TBD | `0x7*` TBD | `0x8*` TBD | `0x9*` TBD | `0xA*` Application-Specific Codes | `0xB*` TBD | `0xC*` TBD | `0xD*` TBD | `0xE*` Encryption, Identity & Proofs | `0xF*` Off-Chain | |--------|------------------------------------------------|----------------------------------------------------------|--------------------------------------------|------------------------------------------------|-------------------------------------------------------------|----------------------------------------|-------------------|-------------------|-------------------|-------------------|-----------------------------------------------|-------------------|-------------------|-------------------|--------------------------------------------|------------------------------------------| | `0x*0` | `0x00` Failure | `0x10` Disallowed or Stop | `0x20` Not Found, Unequal, or Out of Range | `0x30` Sender Disagrees or Nay | `0x40` Unavailable | `0x50` Transfer Failed | `0x60` [reserved] | `0x70` [reserved] | `0x80` [reserved] | `0x90` [reserved] | `0xA0` App-Specific Failure | `0xB0` [reserved] | `0xC0` [reserved] | `0xD0` [reserved] | `0xE0` Decrypt Failure | `0xF0` Off-Chain Failure | | `0x*1` | `0x01` Success | `0x11` Allowed or Go | `0x21` Found, Equal or In Range | `0x31` Sender Agrees or Yea | `0x41` Available | `0x51` Transfer Successful | `0x61` [reserved] | `0x71` [reserved] | `0x81` [reserved] | `0x91` [reserved] | `0xA1` App-Specific Success | `0xB1` [reserved] | `0xC1` [reserved] | `0xD1` [reserved] | `0xE1` Decrypt Success | `0xF1` Off-Chain Success | | `0x*2` | `0x02` Awaiting Others | `0x12` Awaiting Other's Permission | `0x22` Awaiting Match | `0x32` Awaiting Ratification | `0x42` Paused | `0x52` Awaiting Payment From Others | `0x62` [reserved] | `0x72` [reserved] | `0x82` [reserved] | `0x92` [reserved] | `0xA2` App-Specific Awaiting Others | `0xB2` [reserved] | `0xC2` [reserved] | `0xD2` [reserved] | `0xE2` Awaiting Other Signatures or Keys | `0xF2` Awaiting Off-Chain Process | | `0x*3` | `0x03` Accepted | `0x13` Permission Requested | `0x23` Match Request Sent | `0x33` Offer Sent or Voted | `0x43` Queued | `0x53` Hold or Escrow | `0x63` [reserved] | `0x73` [reserved] | `0x83` [reserved] | `0x93` [reserved] | `0xA3` App-Specific Acceptance | `0xB3` [reserved] | `0xC3` [reserved] | `0xD3` [reserved] | `0xE3` Signed | `0xF3` Off-Chain Process Started | | `0x*4` | `0x04` Lower Limit or Insufficient | `0x14` Too Open / Insecure | `0x24` Below Range or Underflow | `0x34` Quorum Not Reached | `0x44` Not Available Yet | `0x54` Insufficient Funds | `0x64` [reserved] | `0x74` [reserved] | `0x84` [reserved] | `0x94` [reserved] | `0xA4` App-Specific Below Condition | `0xB4` [reserved] | `0xC4` [reserved] | `0xD4` [reserved] | `0xE4` Unsigned or Untrusted | `0xF4` Off-Chain Service Unreachable | | `0x*5` | `0x05` Receiver Action Required | `0x15` Needs Your Permission or Request for Continuation | `0x25` Request for Match | `0x35` Receiver's Ratification Requested | `0x45` Awaiting Your Availability | `0x55` Funds Requested | `0x65` [reserved] | `0x75` [reserved] | `0x85` [reserved] | `0x95` [reserved] | `0xA5` App-Specific Receiver Action Requested | `0xB5` [reserved] | `0xC5` [reserved] | `0xD5` [reserved] | `0xE5` Signature Required | `0xF5` Off-Chain Action Required | | `0x*6` | `0x06` Upper Limit | `0x16` Revoked or Banned | `0x26` Above Range or Overflow | `0x36` Offer or Vote Limit Reached | `0x46` Expired | `0x56` Transfer Volume Exceeded | `0x66` [reserved] | `0x76` [reserved] | `0x86` [reserved] | `0x96` [reserved] | `0xA6` App-Specific Expiry or Limit | `0xB6` [reserved] | `0xC6` [reserved] | `0xD6` [reserved] | `0xE6` Known to be Compromised | `0xF6` Off-Chain Expiry or Limit Reached | | `0x*7` | `0x07` [reserved] | `0x17` [reserved] | `0x27` [reserved] | `0x37` [reserved] | `0x47` [reserved] | `0x57` [reserved] | `0x67` [reserved] | `0x77` [reserved] | `0x87` [reserved] | `0x97` [reserved] | `0xA7` [reserved] | `0xB7` [reserved] | `0xC7` [reserved] | `0xD7` [reserved] | `0xE7` [reserved] | `0xF7` [reserved] | | `0x*8` | `0x08` Duplicate, Unnecessary, or Inapplicable | `0x18` Not Applicable to Current State | `0x28` Duplicate, Conflict, or Collision | `0x38` Already Voted | `0x48` Already Done | `0x58` Funds Not Required | `0x68` [reserved] | `0x78` [reserved] | `0x88` [reserved] | `0x98` [reserved] | `0xA8` App-Specific Inapplicable Condition | `0xB8` [reserved] | `0xC8` [reserved] | `0xD8` [reserved] | `0xE8` Already Signed or Not Encrypted | `0xF8` Duplicate Off-Chain Request | | `0x*9` | `0x09` [reserved] | `0x19` [reserved] | `0x29` [reserved] | `0x39` [reserved] | `0x49` [reserved] | `0x59` [reserved] | `0x69` [reserved] | `0x79` [reserved] | `0x89` [reserved] | `0x99` [reserved] | `0xA9` [reserved] | `0xB9` [reserved] | `0xC9` [reserved] | `0xD9` [reserved] | `0xE9` [reserved] | `0xF9` [reserved] | | `0x*A` | `0x0A` [reserved] | `0x1A` [reserved] | `0x2A` [reserved] | `0x3A` [reserved] | `0x4A` [reserved] | `0x5A` [reserved] | `0x6A` [reserved] | `0x7A` [reserved] | `0x8A` [reserved] | `0x9A` [reserved] | `0xAA` [reserved] | `0xBA` [reserved] | `0xCA` [reserved] | `0xDA` [reserved] | `0xEA` [reserved] | `0xFA` [reserved] | | `0x*B` | `0x0B` [reserved] | `0x1B` [reserved] | `0x2B` [reserved] | `0x3B` [reserved] | `0x4B` [reserved] | `0x5B` [reserved] | `0x6B` [reserved] | `0x7B` [reserved] | `0x8B` [reserved] | `0x9B` [reserved] | `0xAB` [reserved] | `0xBB` [reserved] | `0xCB` [reserved] | `0xDB` [reserved] | `0xEB` [reserved] | `0xFB` [reserved] | | `0x*C` | `0x0C` [reserved] | `0x1C` [reserved] | `0x2C` [reserved] | `0x3C` [reserved] | `0x4C` [reserved] | `0x5C` [reserved] | `0x6C` [reserved] | `0x7C` [reserved] | `0x8C` [reserved] | `0x9C` [reserved] | `0xAC` [reserved] | `0xBC` [reserved] | `0xCC` [reserved] | `0xDC` [reserved] | `0xEC` [reserved] | `0xFC` [reserved] | | `0x*D` | `0x0D` [reserved] | `0x1D` [reserved] | `0x2D` [reserved] | `0x3D` [reserved] | `0x4D` [reserved] | `0x5D` [reserved] | `0x6D` [reserved] | `0x7D` [reserved] | `0x8D` [reserved] | `0x9D` [reserved] | `0xAD` [reserved] | `0xBD` [reserved] | `0xCD` [reserved] | `0xDD` [reserved] | `0xED` [reserved] | `0xFD` [reserved] | | `0x*E` | `0x0E` [reserved] | `0x1E` [reserved] | `0x2E` [reserved] | `0x3E` [reserved] | `0x4E` [reserved] | `0x5E` [reserved] | `0x6E` [reserved] | `0x7E` [reserved] | `0x8E` [reserved] | `0x9E` [reserved] | `0xAE` [reserved] | `0xBE` [reserved] | `0xCE` [reserved] | `0xDE` [reserved] | `0xEE` [reserved] | `0xFE` [reserved] | | `0x*F` | `0x0F` Informational or Metadata | `0x1F` Permission Details or Control Conditions | `0x2F` Matching Meta or Info | `0x3F` Negotiation Rules or Participation Info | `0x4F` Availability Rules or Info (ex. time since or until) | `0x5F` Token or Financial Information | `0x6F` [reserved] | `0x7F` [reserved] | `0x8F` [reserved] | `0x9F` [reserved] | `0xAF` App-Specific Meta or Info | `0xBF` [reserved] | `0xCF` [reserved] | `0xDF` [reserved] | `0xEF` Cryptography, ID, or Proof Metadata | `0xFF` Off-Chain Info or Meta | ### Example Function Change ```solidity uint256 private startTime; mapping(address => uint) private counters; // Before function increase() public returns (bool _available) { if (now < startTime && counters[msg.sender] == 0) { return false; }; counters[msg.sender] += 1; return true; } // After function increase() public returns (byte _status) { if (now < start) { return hex"44"; } // Not yet available if (counters[msg.sender] == 0) { return hex"10"; } // Not authorized counters[msg.sender] += 1; return hex"01"; // Success } ``` ### Example Sequence Diagrams ``` 0x03 = Waiting 0x31 = Other Party (ie: not you) Agreed 0x41 = Available 0x44 = Not Yet Available Exchange AwesomeCoin DEX TraderBot + + + | | buy(AwesomeCoin) | | | <------------------------+ | buy() | | | <---------------------+ | | | | | Status [0x44] | | +---------------------> | Status [0x44] | | +------------------------> | | | | | | isDoneYet() | | | <------------------------+ | | | | | Status [0x44] | | +------------------------> | | | | | | | | Status [0x41] | | +---------------------> | | | | | | buy() | | | <---------------------+ | | | | | | | | Status [0x31] | | +---------------------> | Status [0x31] | | +------------------------> | | | | | | | | | | | | | + + + ``` ``` 0x01 = Generic Success 0x10 = Disallowed 0x11 = Allowed Token Validation Buyer RegulatedToken TokenValidator IDChecker SpendLimiter + + + + + | buy() | | | | +------------------------> | check() | | | | +-----------------------> | check() | | | | +-----------------------> | | | | | | | | | | Status [0x10] | | | | Status [0x10] | <-----------------------+ | | revert() | <-----------------------+ | | | <------------------------+ | | | | | | | | +---------------------------+ | | | | | | | | | | | Updates ID with provider | | | | | | | | | | | +---------------------------+ | | | | | | | | | | buy() | | | | +------------------------> | check() | | | | +-----------------------> | check() | | | | +-----------------------> | | | | | | | | | | Status [0x11] | | | | | <-----------------------+ | | | | | | | | | | check() | | | +-------------------------------------------> | | | | | | | | | | Status [0x11] | | | Status [0x11] | <-------------------------------------------+ | Status [0x01] | <-----------------------+ | | | <------------------------+ | | | | | | | | | | | | | | | | | | + + + + + ``` ## Rationale ### Encoding Status codes are encoded as a `byte`. Hex values break nicely into high and low nibbles: `category` and `reason`. For instance, `0x01` stands for general success (ie: `true`) and `0x00` for general failure (ie: `false`). As a general approach, all even numbers are blocking conditions (where the receiver does not have control), and odd numbers are nonblocking (the receiver is free to continue as they wish). This aligns both a simple bit check with the common encoding of Booleans. `bytes1` is very lightweight, portable, easily interoperable with `uint8`, cast from `enum`s, and so on. #### Alternatives Alternate schemes include `bytes32` and `uint8`. While these work reasonably well, they have drawbacks. `uint8` feels even more similar to HTTP status codes, and enums don't require as much casting. However does not break as evenly as a square table (256 doesn't look as nice in base 10). Packing multiple codes into a single `bytes32` is nice in theory, but poses additional challenges. Unused space may be interpreted as `0x00 Failure`, you can only efficiently pack four codes at once, and there is a challenge in ensuring that code combinations are sensible. Forcing four codes into a packed representation encourages multiple status codes to be returned, which is often more information than strictly necessarily. This can lead to paradoxical results (ex `0x00` and `0x01` together), or greater resources allocated to interpreting 256<sup>4</sup> (4.3 billion) permutations. ### Multiple Returns While there may be cases where packing a byte array of status codes may make sense, the simplest, most forwards-compatible method of transmission is as the first value of a multiple return. Familiarity is also a motivating factor. A consistent position and encoding together follow the principle of least surprise. It is both viewable as a "header" in the HTTP analogy, or like the "tag" in BEAM tagged tuples. ### Human Readable Developers should not be required to memorize 256 codes. However, they break nicely into a table. Cognitive load is lowered by organizing the table into categories and reasons. `0x10` and `0x11` belong to the same category, and `0x04` shares a reason with `0x24` While this repository includes helper enums, we have found working directly in the hex values to be quite natural. Status code `0x10` is just as comfortable as HTTP 401, for example. #### Localizations One commonly requested application of this spec is human-readable translations of codes. This has been moved to its own proposal: [ERC-1444](/EIPS/eip-1444), primarily due to a desire to keep both specs focused. ### Extensibility The `0xA` category is reserved for application-specific statuses. In the case that 256 codes become insufficient, `bytes1` may be embedded in larger byte arrays. ### EVM Codes The EVM also returns a status code in transactions; specifically `0x00` and `0x01`. This proposal both matches the meanings of those two codes, and could later be used at the EVM level. ### Empty Space Much like how HTTP status codes have large unused ranges, there are totally empty sections in this proposal. The intent is to not impose a complete set of codes up front, and to allow users to suggest uses for these spaces as time progresses. ### Beyond Errors This spec is intended to be much more than a set of common errors. One design goal is to enable easier contract-to-contract communication, protocols built on top of status codes, and flows that cross off-chain. Many of these cases include either expected kinds of exception state (as opposed to true errors), neutral states, time logic, and various successes. Just like how HTTP 200 has a different meaning from HTTP 201, ERC-1066 status codes can relay information between contract beyond simply pass or fail. They can be thought of as the edges in a graph that has smart contracts as nodes. ### Fully `revert`able _This spec is fully compatible with `revert`-with-reason and does not intend to supplant it in any way._ Both by reverting with a common code, the developer can determine what went wrong from a set of known error states. Further, by leveraging ERC-1066 and a translation table (such as in ERC-1444) in conjunction, developers and end users alike can receive fully automated human-readable error messages in the language and phrasing of their choice. ### Nibble Order Nibble order makes no difference to the machine, and is purely mnemonic. This design was originally in opposite order, but changed it for a few convenience factors. Since it's a different scheme from HTTP, it may feel strange initially, but becomes very natural after a couple hours of use. #### Short Forms Generic is `0x0*`, general codes are consistent with their integer representations ```solidity hex"1" == hex"01" == 1 // with casting ``` #### Contract Categories Many applications will always be part of the same category. For instance, validation will generally be in the `0x10` range. ```solidity contract Whitelist { mapping(address => bool) private whitelist; uint256 private deadline; byte constant private prefix = hex"10"; check(address _, address _user) returns (byte _status) { if (now >= deadline) { return prefix | 5; } if (whitelist[_user]) { return prefix | 1; } return prefix; } } ``` #### Helpers This above also means that working with app-specific enums is slightly easier, and also saves gas (fewer operations required). ```solidity enum Sleep { Awake, Asleep, BedOccupied, WindingDown } // From the helper library function appCode(Sleep _state) returns (byte code) { return byte(160 + _state); // 160 = 0xA0 } // Versus function appCode(Sleep _state) returns (byte code) { return byte((16 * _state) + 10); // 10 = 0xA } ``` ## Implementation Reference cases and helper libraries (Solidity and JS) can be found at: * [Source Code](https://github.com/fission-suite/fission-codes/) * [Package on npm](https://www.npmjs.com/package/fission-codes/) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 05 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1066 https://eips.ethereum.org/EIPS/eip-1066 Gas relay for contract calls Standards Track/ERC https://ethereum-magicians.org/t/erc1077-and-1078-the-magic-of-executable-signed-messages-to-login-and-do-actions/351 ## Simple Summary A standard interface for gas abstraction in top of smart contracts. Allows users to offer [EIP-20] token for paying the gas used in a call. ## Abstract A main barrier for the adoption of DApps is the requirement of multiple tokens for executing in chain actions. Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them can circumvent this problem, while ETH will always be required for ethereum transactions, it's possible for smart contract to take [EIP-191] signatures and forward a payment incentive to an untrusted party with ETH for executing the transaction. ## Motivation Standardizing a common format for them, as well as a way in which the user allows the transaction to be paid in tokens, gives app developers a lot of flexibility and can become the main way in which app users interact with the Blockchain. ## Specification ### Methods #### executeGasRelay Executes `_execData` with current `lastNonce()` and pays `msg.sender` the gas used in specified `_gasToken`. ```solidity function executeGasRelay(bytes calldata _execData, uint256 _gasPrice, uint256 _gasLimit, address _gasToken, address _gasRelayer, bytes calldata _signature) external; ``` ### executeGasRelayMsg Returns the `executeGasRelay` message used for signing messages.. ```solidity function executeGasRelayMsg(uint256 _nonce, bytes memory _execData, uint256 _gasPrice, uint256 _gasLimit, address _gasToken, address _gasRelayer) public pure returns (bytes memory); ``` #### executeGasRelayERC191Msg Returns the [EIP-191] of `executeGasRelayMsg` used for signing messages and for verifying the execution. ```solidity function executeGasRelayERC191Msg(uint256 _nonce, bytes memory _execData, uint256 _gasPrice, uint256 _gasLimit, address _gasToken, address _gasRelayer) public view returns (bytes memory); ``` #### lastNonce Returns the current nonce for the gas relayed messages. ```solidity function lastNonce() public returns (uint nonce); ``` ### Signed Message The signed message require the following fields: * Nonce: A nonce *or* a timestamp; * Execute Data: the bytecode to be executed by the account contract; * Gas Price: The gas price (paid in the selected token); * Gas Limit: The gas reserved to the relayed execution; * Gas Token: A token in which the gas will be paid (leave 0 for ether); * Gas Relayer: the beneficiary of gas refund for this call (leave 0 for `block.coinbase`) . #### Signing the message The message **MUST** be signed as [EIP-191] standard, and the called contract **MUST** also implement [EIP-1271] which must validate the signed messages. Messages **MUST** be signed by the owner of the account contract executing. If the owner is a contract, it must implement [EIP-1271] interface and forward validation to it. In order to be compliant, the transaction **MUST** request to sign a "messageHash" that is a concatenation of multiple fields. The fields **MUST** be constructed as this method: The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive the reward. The [EIP-191] message must be constructed as follows: ```solidity keccak256( abi.encodePacked( byte(0x19), //ERC-191 - the initial 0x19 byte byte(0x0), //ERC-191 - the version byte address(this), //ERC-191 - version data (validator address) chainID, bytes4( keccak256("executeGasRelay(uint256,bytes,uint256,uint256,address,address)") ), _nonce, _execData, _gasPrice, _gasLimit, _gasToken, _gasRelayer ) ) ``` ## Rationale User pain points: * users don't want to think about ether * users don't want to think about backing up private keys or seed phrases * users want to be able to pay for transactions using what they already have on the system, be apple pay, xbox points or even a credit card * Users don’t want to sign a new transaction at every move * Users don’t want to download apps/extensions (at least on the desktop) to connect to their apps App developer pain points: * Many apps use their own token and would prefer to use those as the main accounting * Apps want to be able to have apps in multiple platforms without having to share private keys between devices or have to spend transaction costs moving funds between them * Token developers want to be able for their users to be able to move funds and pay fees in the token * While the system provides fees and incentives for miners, there are no inherent business model for wallet developers (or other apps that initiate many transactions) Using signed messages, specially combined with an account contract that holds funds, and multiple disposable ether-less keys that can sign on its behalf, solves many of these pain points. ### Multiple signatures More than one signed transaction with the same parameter can be executed by this function at the same time, by passing all signatures in the `messageSignatures` field. That field will split the signature in multiple 72 character individual signatures and evaluate each one. This is used for cases in which one action might require the approval of multiple parties, in a single transaction. If multiple signatures are required, then all signatures should then be *ordered by account* and the account contract should implement signatures checks locally (`JUMP`) on [EIP-1271] interface which might forward (`STATIC_CALL`) the [EIP-1271] signature check to owner contract. ### Keep track of nonces: Note that `executeGasRelay` function does not take a `_nonce` as parameter. The contract knows what is the current nonce, and can only execute the transactions in order, therefore there is no reason Nonces work similarly to normal ethereum transactions: a transaction can only be executed if it matches the last nonce + 1, and once a transaction has occurred, the `lastNonce` will be updated to the current one. This prevents transactions to be executed out of order or more than once. Contracts may accept transactions without nonce (nonce = 0). The contract then must keep the full hash of the transaction to prevent it from being replayed. This would allows contracts to have more flexibilities as you can sign a transaction that can be executed out of order or not at all, but it uses more memory for each transaction. It can be used, for instance, for transactions that the user wants to schedule in the future but cannot know its future nonce, or transactions that are made for state channel contracts that are not guaranteed to be executed or are only executed when there's some dispute. ### Execute transaction After signature validation, the evaluation of `_execBytes` is up to the account contract implementation, it's role of the wallet to properly use the account contract and it's gas relay method. A common pattern is to expose an interface which can be only called by the contract itself. The `_execBytes` could entirely forward the call in this way, as example: `address(this).call.gas(_gasLimit)(_execData);` Where `_execData` could call any method of the contract itself, for example: - `call(address to, uint256 value, bytes data)`: allow any type of ethereum call be performed; - `create(uint256 value, bytes deployData)`: allows create contract - `create2(uint256 value, bytes32 salt, bytes deployData)`: allows create contract with deterministic address - `approveAndCall(address token, address to, uint256 value, bytes data)`: allows safe approve and call of an ERC20 token. - `delegatecall(address codeBase, bytes data)`: allows executing code stored on other contract - `changeOwner(address newOwner)`: Some account contracts might allow change of owner - `foo(bytes bar)`: Some account contracts might have custom methods of any format. The standardization of account contracts is not scope of this ERC, and is presented here only for illustration on possible implementations. Using a self call to evaluate `_execBytes` is not mandatory, depending on the account contract logic, the evaluation could be done locally. ### Gas accounting and refund The implementing contract must keep track of the gas spent. One way to do it is to first call `gasLeft()` at the beginning of the function and then after executing the desired action and compare the difference. The contract then will make a token transfer (or ether, if `tokenAddress` is nil) in the value of `gasSpent * gasPrice` to the `_gasRelayer`, that is the account that deployed the message. If `_gasRelayer` is zero, then the funds **MUST** go to `block.coinbase`. If there are not enough funds, or if the total surpasses `gasLimit` then the transaction **MUST** revert. If the executed transaction fails internally, nonces should still be updated and gas needs to be paid. Contracts are not obligated to support ether or any other token they don’t want and can be implemented to only accept refunds in a few tokens of their choice. ### Usage examples This scheme opens up a great deal of possibilities on interaction as well as different experiments on business models: * Apps can create individual identities contract for their users which holds the actual funds and then create a different private key for each device they log into. Other apps can use the same identity and just ask to add permissioned public keys to manage the device, so that if one individual key is lost, no ether is lost. * An app can create its own token and only charge their users in its internal currency for any ethereum transaction. The currency units can be rounded so it looks more similar to actual amount of transactions: a standard transaction always costs 1 token, a very complex transaction costs exactly 2, etc. Since the app is the issuer of the transactions, they can do their own Sybil verifications and give a free amount of currency units to new users to get them started. * A game company creates games with a traditional monthly subscription, either by credit card or platform-specific microtransactions. Private keys never leave the device and keep no ether and only the public accounts are sent to the company. The game then signs transactions on the device with gas price 0, sends them to the game company which checks who is an active subscriber and batches all transactions and pays the ether themselves. If the company goes bankrupt, the gamers themselves can set up similar subscription systems or just increase the gas price. End result is a **ethereum based game in which gamers can play by spending apple, google or xbox credits**. * A standard token is created that doesn’t require its users to have ether, and instead allows tokens to be transferred by paying in tokens. A wallet is created that signs messages and send them via whisper to the network, where other nodes can compete to download the available transactions, check the current gas price, and select those who are paying enough tokens to cover the cost. **The result is a token that the end users never need to keep any ether and can pay fees in the token itself.** * A DAO is created with a list of accounts of their employees. Employees never need to own ether, instead they sign messages, send them to whisper to a decentralized list of relayers which then deploy the transactions. The DAO contract then checks if the transaction is valid and sends ether to the deployers. Employees have an incentive not to use too many of the companies resources because they’re identifiable. The result is that the users of the DAO don't need to keep ether, and **the contract ends up paying for it's own gas usage**. ## Backwards Compatibility There is no issues with backwards compatibility, however for future upgrades, as `_execData` contains arbitrary data evaluated by the account contract, it's up to the contract to handle properly this data and therefore contracts can gas relay any behavior with the current interface. ## Test Cases TBD ## Implementation One initial implementation of such a contract can be found at [Status.im account-contracts repository](https://github.com/status-im/account-contracts/blob/develop/contracts/account/AccountGasAbstract.sol) Other version is implemented as Gnosis Safe variant in: https://github.com/status-im/safe-contracts ### Similar implementations The idea of using signed messages as executable intent has been around for a while and many other projects are taking similar approaches, which makes it a great candidate for a standard that guarantees interoperability: * [EIP-877](https://github.com/ethereum/EIPs/pull/877) An attempt of doing the same but with a change in the protocol * [Status](https://github.com/status-im/ideas/issues/73) * [Aragon](https://github.com/aragonlabs/pay-protocol) (this might not be the best link to show their work in this area) * [Token Standard Functions for Preauthorized Actions](https://github.com/ethereum/EIPs/issues/662) * [Token Standard Extension 865](https://github.com/ethereum/EIPs/issues/865) * [Iuri Matias: Transaction Relay](https://github.com/iurimatias/TransactionRelay) * [uPort: Meta transactions](https://github.com/uport-project/uport-identity#send-a-meta-tx) * [uPort: safe Identities](https://github.com/uport-project/uport-identity/blob/develop/docs/txRelay.md) * [Gnosis safe contracts](https://github.com/gnosis/safe-contracts) Swarm city uses a similar proposition for etherless transactions, called [Gas Station Service](https://github.com/swarmcity/SCLabs-gasstation-service), but it's a different approach. Instead of using signed messages, a traditional ethereum transaction is signed on an etherless account, the transaction is then sent to a service that immediately sends the exact amount of ether required and then publishes the transaction. ## Security Considerations Deployers of transactions (relayers) should be able to call untrusted contracts, which provides no guarantees that the contract they are interacting with correctly implements the standard and they will be reimbursed for gas. To prevent being fooled by bad implementations, relayers must **estimate the outcome of a transaction**, and only include/sign transactions which have a desired outcome. Is also interest of relayers to maintaining a private reputation of contracts they interact with, as well as keep track of which tokens and for which `gasPrice` they’re willing to deploy transactions. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). ## References * [Universal Logins talk at UX Unconf, Toronto](https://www.youtube.com/watch?v=qF2lhJzngto) [EIP-20]: /EIPS/eip-20 [EIP-191]: /EIPS/eip-191 [EIP-1271]: /EIPS/eip-1271 [EIP-1344]: /EIPS/eip-1344 Fri, 04 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1077 https://eips.ethereum.org/EIPS/eip-1077 Universal login / signup using ENS subdomains Standards Track/ERC https://ethereum-magicians.org/t/erc1077-and-1078-the-magic-of-executable-signed-messages-to-login-and-do-actions/351 ## Abstract This presents a method to replace the usual signup/login design pattern with a minimal ethereum native scheme, that doesn’t require passwords, backing up private keys nor typing seed phrases. From the user's point of view it will be very similar to patterns they’re already used to with second factor authentication (without relying in a central server), but for dapp developers it requires a new way to think about ethereum transactions. ## Simple Summary The unique identifier of the user is a contract that implements both Identity and the Executable Signed Messages ERCs. The user should not need to provide this address directly, only a ENS name pointing to it. These types of contracts are indirectly controlled by private keys that can sign messages indicating intents, which are then deployed to the contract by a third party (or a decentralized network of deployers). In this context, therefore, a device "logging into" an app using an identity, means that the device will generate a private key locally and then request an authorization to add that key as one of the signers of that identity, with a given set of permissions. Since that private key is only used for signing messages, it is not required to hold ether, tokens or assets, and if lost, it can be simply be replaced by a new one – the user's funds are kept on the identity contract. In this context, ethereum accounts are used in a manner more similar to auth tokens, rather than unique keys. The login process is as follows: #### 1) Request a name from the user The first step of the process is to request from the user the ENS name that points to their identity. If the user doesn’t have a login set up, the app should–if they have an integrated identity manager–provide an option to provide a subdomain or a name they own. **UX Note:** there are many ways to provide this interface, the app can ask if they want to signup/login before hand or simply directly ask them to type the name. Note that since it’s trivial to verify if a username exists, your app should adapt to it gracefully and not require the user to type their name twice. If they ask to signup and provide a name that exists then ask them if they want to login using that name, or similarly if they ask to connect to an existing name but type a non-existent name show them a nice alert and ask them if they want to create that name now. Don’t force them to type the same name twice in two different fields. #### 2.a) Create a new identity If the user doesn’t have an identity, the app should provide the option to create one for them. Each app must have one or more domains they control which they can create immediate subdomains on demand. The app therefore will make these actions on the background: 1. Generate a private key which it will keep saved locally on the device or browser, the safest way possible. 2. Create (or set up) an identity contract which supports both ERC720 and ERC1077 3. Register the private key created on step 1 as the *only* admin key of the contract (the app must not add any app-controlled key, except as a recovery option - see 5) 4. Register the requested subdomain and transfer its ownership to the contract (while the app controls the main domain and may keep the option to reassign them at will, the ownership of the subdomain itself should belong to the identity, therefore allowing them to transfer it) 5. (Optionally) Register a recovery method on the contract, which allows the user to regain access to the contract in case the main key is lost. All those steps can be designed to be set up in a single ethereum transaction. Since this step is not free, the app reserves the right to charge for registering users, or require the user to be verified in a sybil resistant manner of the app’s choosing (captcha, device ID registration, proof of work, etc) The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app that shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action. **Implementation note:** in order to save gas, some of these steps can be done in advance. The app can automatically deploy a small number of contracts when the gas price is low, and set up all their main variables to be 0xFFFFFF...FFFFF. These should be considered ‘vacant’ and when the user registers one, they will get a gas discount for freeing up space on the chain. This has the added benefit of allowing the user a choice in contract address/icon. #### 2.b) Connect to an existing identity If the user wants to connect with an existing identity, then the first thing the app needs to understand is what level of privilege it’s going to ask for: **Manager** the higher level, allows the key to initiate or sign transactions that change the identity itself, like adding or removing keys. An app should only require this level if it integrates an identity manager. Depending on how the identity is set up, it might require signature from more keys before these transactions can be deployed. **Action** this level allows the key to initiate or sign transactions on address other than itself. It can move funds, ether, assets etc. An app should only require this level of privilege if it’s a general purpose wallet or browser for sending ethereum transactions. Depending on how the identity is set up, it might require signature from more keys before these transactions can be deployed. **Encryption** the lower level has no right to initiate any transactions, but it can be used to represent the user in specific instances or off-chain signed messages. It’s the ideal level of privilege for games, chat or social media apps, as they can be used to sign moves, send messages, etc. If a game requires actual funds (say, to start a game with funds in stake) then it should still use the encryption level, and then require the main wallet/browser of the user to sign messages using the ethereum URI standard. Once the desired level is known, the app must take these steps: 1. **Generate a private key** which it will keep saved locally on the device or browser, the safest way possible. 2. **Query ens** to figure the existing address of the identity 3. **Generate the bytecode** for a transaction calling the function `addKey(PUBLICKEY,LEVEL)`. 4. **Broadcast a transaction request on a whisper channel** or some other decentralized network of peers. Details on this step require further discussions 1. **If web3 is available** then attempt calling web3.eth.sendTransaction. This can be automatic or prompted by user action. 1. **Attempt calling a URI** if the app supports [URL format for transaction requests EIP](/EIPS/eip-681) then attempt calling this. This can be automatic or prompted by user action. 1. **Show a QR code**: with an EIP681 formatted URL. That QR code can be clickable to attempt to retry the other options, but it should be done last: if step 1 works, the user should receive a notification on their compatible device and won't need to use the QR code. Here's an example of a EIP681 compatible address to add a public key generated locally in the app: `ethereum:bob.example.eth?function=addKey(address='0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef',uint=1)` If adding the new key requires multiple signatures, or if the app receiving that request exclusiveky deals with executable signed messages and has no ether on itself, then it should follow the steps in the next section on how to request transactions. As before, the user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app the shows the progress and then allow the user to interact with your app normally. #### 3) Request transactions After step 2, the end result should be that your app should have the identity address of the user, their main ens name and a private key, whose public account is listed on the identity as one of their keys, with roles being either manager, action or encryption. Now it can start using that information to sign and execute transactions. **Not all transactions need to be on chain**, actually most common uses of signed messages should be off chain. If you have a chat app, for instance, you can use the local key for signing messages and sending it to the other parties, and they can just query the identity contract to see if that key actually comes from the user. If you have a game with funds at stake, only the first transaction moving funds and setting up the initial game needs to be executed by the identity: at each turn the players can sign a hash of the current state of the board and at the end, the last two plays can be used to determine the winner. Notice that keys can be revoked at any time, so your app should take that in consideration, for instance saving all keys at the start of the game. Keys that only need this lower level of privilege, should be set at level 4 (encryption). Once you decided you actually need an on-chain transaction, follow these steps: 1. **Figure out the TO, FROM, VALUE and DATA**. These are the basics of any ethereum transaction. `from` is the compatible contract you want the transaction to be deployed from. 2. **Check the privilege level you need:** if the `to` and `from` fields are the same contract, ie, if the transaction requires the identity to act upon itself (for instance, when adding or removing a key) then you need level 1 (management), otherwise it's 2 (action). Verify if the key your app owns correspond to the required level. 3. **Verify how many keys are required** by calling `requiredSignatures(uint level)` on the target contract 4. **Figure out gasLimit**: Estimate the gas cost of the desired transaction, and add a margin (recommended: add 100k gas) 5. **Figure out gasToken and gasPrice**: Check the current gas price considering network congestions and the market price of the token the user is going to pay with. Leave gasToken as 0 for ether. Leave gasPrice as 0 if you are deploying it yourself and subsidizing the costs elsewhere. 6. **Sign an executable signed transaction** by following that standard. After having all the signed executable message, we need to deploy it to the chain. If the transaction only requires a single signature, then the app provider can deploy it themselves. Send the transaction to the `from` address and attempt to call the function `executeSigned`, using the parameters and signature you just collected. If the transaction need to collect more signatures or the app doesn't have a deployable server, the app should follow these steps: 1. **Broadcast the transaction on a whisper channel** or some other decentralized network of peers. Details on this step require further discussions 2. **If web3 is available** then attempt calling web3.eth.personal_sign. This can be automatic or prompted by user action. 3. **Show a QR code**: with the signed transaction and the new data to be signed. That QR code can be clickable to attempt to retry the other options, but it should be done last: if step 1 works, the user should receive a notification on their compatible device and won't need to use the QR code. The goal is to keep broadcasting signatures via whisper until a node that is willing to deploy them is able to collect all messages. Once you've followed the above steps, watch the transaction pool to any transaction to that address and then take the user to your app. Once you seen the desired transaction, you can stop showing the QR code and proceed with the app, while keeping some indication that the transaction is in progress. Subscribe to the event `ExecutedSigned` of the desired contract: once you see the transaction with the nonce, you can call it a success. If you see a different transaction with the same or higher nonce (or timestamp) then you consider the transaction permanently failed and restart the process. ### Implementation No working examples of this implementation exists, but many developers have expressed interest in adopting it. This section will be edited in the future to reflect that. ### Conclusion and future improvements This scheme would allow much more lighter apps, that don’t require holding ether, and can keep unlocked private keys on the device to be able to send messages and play games without requesting user prompt every time. More work is needed to standardize common decentralized messaging protocols as well as open source tools for deployment nodes, in order to create a decentralized and reliable layer for message deployment. ### References * [Universal Logins talk at UX Unconf, Toronto](https://www.youtube.com/watch?v=qF2lhJzngto) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 04 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1078 https://eips.ethereum.org/EIPS/eip-1078 Recoverable Token Standards Track/ERC https://ethereum-magicians.org/t/erc-1080-recoverabletoken-standard/364 ## Simple Summary A standard interface for tokens that support chargebacks, theft prevention, and lost & found resolutions. ## Abstract The following standard allows for the implementation of a standard API for tokens extending ERC-20 or ERC-791. This standard provides basic functionality to recover stolen or lost accounts, as well as provide for the chargeback of tokens. ## Motivation To mitigate the effects of reasonably provable token or asset loss or theft and to help resolve other conflicts. Ethereum's protocol should not be modified because of loss, theft, or conflicts, but it is possible to solve these problems in the smart contract layer. ## Specification ## RecoverableToken ### Methods #### claimLost Reports the `lostAccount` address as being lost. MUST trigger the `AccountClaimedLost` event. After the time configured in `getLostAccountRecoveryTimeInMinutes` the implementer MUST provide a mechanism for determining the correct owner of the tokens held and moving the tokens to a new account. Account recoveries must trigger the `AccountRecovered` event. ``` js function claimLost(address lostAccount) returns (bool success) ``` #### cancelLostClaim Reports the `msg.sender`'s account as being not being lost. MUST trigger the `AccountClaimedLostCanceled` event. MUST fail if an account recovery process has already begun. Otherwise, this method MUST stop a dispute from being started to recover funds. ``` js function claimLost() returns (bool success) ``` #### reportStolen Reports the current address as being stolen. MUST trigger the `AccountFrozen` event. Successful calls MUST result in the `msg.sender`'s tokens being frozen. The implementer MUST provide a mechanism for determining the correct owner of the tokens held and moving the tokens to a new account. Account recoveries must trigger the `AccountRecovered` event. ``` js function reportStolen() returns (bool success) ``` #### chargeback Requests a reversal of transfer on behalf of `msg.sender`. The implementer MUST provide a mechanism for determining the correct owner of the tokens disputed and moving the tokens to the correct account. MUST comply with sender's chargeback window as value configured by `setPendingTransferTimeInMinutes`. ``` js function chargeback(uint256 pendingTransferNumber) returns (bool success) ``` #### getPendingTransferTimeInMinutes Get the time an account has to chargeback a transfer. ``` js function getPendingTransferTime(address account) view returns (uint256 minutes) ``` #### setPendingTransferTimeInMinutes Sets the time `msg.sender`'s account has to chargeback a transfer. MUST NOT change the time if the account has any pending transfers. ``` js function setPendingTransferTime(uint256 minutes) returns (bool success) ``` #### getLostAccountRecoveryTimeInMinutes Get the time account has to wait before a lost account dispute can start. ``` js function getLostAccountRecoveryTimeInMinutes(address account) view returns (uint256 minutes) ``` #### setLostAccountRecoveryTimeInMinutes Sets the time `msg.sender`'s account has to sit before a lost account dispute can start. MUST NOT change the time if the account has open disputes. ``` js function setLostAccountRecoveryTimeInMinutes(uint256 minutes) returns (bool success) ``` ### Events #### AccountRecovered The recovery of an account that was lost or stolen. ``` js event AccountClaimedLost(address indexed account, address indexed newAccount) ``` #### AccountClaimedLostCanceled An account claimed as being lost. ``` js event AccountClaimedLost(address indexed account) ``` #### AccountClaimedLost An account claimed as being lost. ``` js event AccountClaimedLost(address indexed account) ``` #### PendingTransfer A record of a transfer pending. ``` js event PendingTransfer(address indexed from, address indexed to, uint256 value, uint256 pendingTransferNumber) ``` #### ChargebackRequested A record of a chargeback being requested. ``` js event ChargebackRequested(address indexed from, address indexed to, uint256 value, uint256 pendingTransferNumber) ``` #### Chargeback A record of a transfer being reversed. ``` js event Chargeback(address indexed from, address indexed to, uint256 value, uint256 indexed pendingTransferNumber) ``` #### AccountFrozen A record of an account being frozen. MUST trigger when an account is frozen. ``` js event AccountFrozen(address indexed reported) ``` ## Rationale * A recoverable token standard can provide configurable safety for users or contracts who desire this safety. * Implementations of this standard will give users the ability to select a dispute resolution process on an opt-in basis and benefit the community by decreasing the necessity of consideration of token recovery actions. ## Implementation Pending. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 02 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1080 https://eips.ethereum.org/EIPS/eip-1080 Standard Bounties Standards Track/ERC https://gitter.im/bounties-network/Lobby ## Simple Summary A standard contract and interface for issuing bounties on Ethereum, usable for any type of task, paying in any ERC20 token or in ETH. ## Abstract In order to encourage cross-platform interoperability of bounties on Ethereum, and for easier reputational tracking, StandardBounties can facilitate the administration of funds in exchange for deliverables corresponding to a completed task, in a publicly auditable and immutable fashion. ## Motivation In the absence of a standard for bounties on Ethereum, it would be difficult for platforms to collaborate and share the bounties which users create (thereby recreating the walled gardens which currently exist on Web2.0 task outsourcing platforms). A standardization of these interactions across task types also makes it far easier to track various reputational metrics (such as how frequently you pay for completed submissions, or how frequently your work gets accepted). ## Specification After studying bounties as they've existed for thousands of years (and after implementing and processing over 300 of them on main-net in beta), we've discovered that there are 3 core steps to every bounty: - a bounty is **issued**: an `issuer` specifies the requirements for the task, describing the desired outcome, and how much they would be willing to pay for the completion of that task (denoted in one or several tokens). - a bounty is **fulfilled**: a bounty `fulfiller` may see the bounty, complete the task, and produce a deliverable which is itself the desired outcome of the task, or simply a record that it was completed. Hashes of these deliverables should be stored immutably on-chain, to serve as proof after the fact. - a fulfillment is **accepted**: a bounty `issuer` or `arbiter` may select one or more submissions to be accepted, thereby releasing payment to the bounty fulfiller(s), and transferring ownership over the given deliverable to the `issuer`. To implement these steps, a number of functions are needed: - `initializeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This is used when deploying a new StandardBounty contract, and is particularly useful when applying the proxy design pattern, whereby bounties cannot be initialized in their constructors. Here, the data string should represent an IPFS hash, corresponding to a JSON object which conforms to the schema (described below). - `fulfillBounty(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data)`: This is called to submit a fulfillment, submitting a string representing an IPFS hash which contains the deliverable for the bounty. Initially fulfillments could only be submitted by one individual at a time, however users consistently told us they desired to be able to collaborate on fulfillments, thereby allowing the credit for submissions to be shared by several parties. The lines along which eventual payouts are split are determined by the fractions of the submission credited to each fulfiller (using the array of numerators and single denominator). Here, a bounty platform may also include themselves as a collaborator to collect a small fee for matching the bounty with fulfillers. - `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to be based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise. - `drainBounty(StandardToken[] _payoutTokens)`: This may be called by the `issuer` to drain a bounty of it's funds, if the need should arise. - `changeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This may be called by the `issuer` to change the `issuer`, `arbiter`, `data`, and `deadline` fields of their bounty. - `changeIssuer(address _issuer)`: This may be called by the `issuer` to change to a new `issuer` if need be - `changeArbiter(address _arbiter)`: This may be called by the `issuer` to change to a new `arbiter` if need be - `changeData(string _data)`: This may be called by the `issuer` to change just the `data` - `changeDeadline(uint _deadline)`: This may be called by the `issuer` to change just the `deadline` Optional Functions: - `acceptAndFulfill(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: During the course of the development of this standard, we discovered the desire for fulfillers to avoid paying gas fees on their own, entrusting the bounty's `issuer` to make the submission for them, and at the same time accept it. This is useful since it still immutably stores the exchange of tokens for completed work, but avoids the need for new bounty fulfillers to have any ETH to pay for gas costs in advance of their earnings. - `changeMasterCopy(StandardBounty _masterCopy)`: For `issuer`s to be able to change the masterCopy which their proxy contract relies on, if the proxy design pattern is being employed. - `refundableContribute(uint[] _amounts, StandardToken[] _tokens)`: While non-refundable contributions may be sent to a bounty simply by transferring those tokens to the address where it resides, one may also desire to contribute to a bounty with the option to refund their contribution, should the bounty never receive a correct submission which is paid out. `refundContribution(uint _contributionId)`: If a bounty hasn't yet paid out to any correct submissions and is past it's deadline, those individuals who employed the `refundableContribute` function may retrieve their funds from the contract. **Schemas** Persona Schema: ``` { name: // optional - A string representing the name of the persona email: // optional - A string representing the preferred contact email of the persona githubUsername: // optional - A string representing the github username of the persona address: // required - A string web3 address of the persona } ``` Bounty issuance `data` Schema: ``` { payload: { title: // A string representing the title of the bounty description: // A string representing the description of the bounty, including all requirements issuer: { // persona for the issuer of the bounty }, funders:[ // array of personas of those who funded the issue. ], categories: // an array of strings, representing the categories of tasks which are being requested tags: // an array of tags, representing various attributes of the bounty created: // the timestamp in seconds when the bounty was created tokenSymbol: // the symbol for the token which the bounty pays out tokenAddress: // the address for the token which the bounty pays out (0x0 if ETH) // ------- add optional fields here ------- sourceFileName: // A string representing the name of the file sourceFileHash: // The IPFS hash of the file associated with the bounty sourceDirectoryHash: // The IPFS hash of the directory which can be used to access the file webReferenceURL: // The link to a relevant web reference (ie github issue) }, meta: { platform: // a string representing the original posting platform (ie 'gitcoin') schemaVersion: // a string representing the version number (ie '0.1') schemaName: // a string representing the name of the schema (ie 'standardSchema' or 'gitcoinSchema') } } ``` Bounty `fulfillment` data Schema: ``` { payload: { description: // A string representing the description of the fulfillment, and any necessary links to works sourceFileName: // A string representing the name of the file being submitted sourceFileHash: // A string representing the IPFS hash of the file being submitted sourceDirectoryHash: // A string representing the IPFS hash of the directory which holds the file being submitted fulfillers: { // personas for the individuals whose work is being submitted } // ------- add optional fields here ------- }, meta: { platform: // a string representing the original posting platform (ie 'gitcoin') schemaVersion: // a string representing the version number (ie '0.1') schemaName: // a string representing the name of the schema (ie 'standardSchema' or 'gitcoinSchema') } } ``` ## Rationale The development of this standard began a year ago, with the goal of encouraging interoperability among bounty implementations on Ethereum. The initial version had significantly more restrictions: a bounty's `data` could not be changed after issuance (it seemed unfair for bounty `issuer`s to change the requirements after work is underway), and the bounty payout could not be changed (all funds needed to be deposited in the bounty contract before it could accept submissions). The initial version was also far less extensible, and only allowed for fixed payments to a given set of fulfillments. This new version makes it possible for funds to be split among several correct submissions, for submissions to be shared among several contributors, and for payouts to not only be in a single token as before, but in as many tokens as the `issuer` of the bounty desires. These design decisions were made after the 8+ months which Gitcoin, the Bounties Network, and Status Open Bounty have been live and meaningfully facilitating bounties for repositories in the Web3.0 ecosystem. ## Test Cases Tests for our implementation can be found here: https://github.com/Bounties-Network/StandardBounties/tree/develop/test ## Implementation A reference implementation can be found here: https://github.com/Bounties-Network/StandardBounties/blob/develop/contracts/StandardBounty.sol **Although this code has been tested, it has not yet been audited or bug-bountied, so we cannot make any assertions about it's correctness, nor can we presently encourage it's use to hold funds on the Ethereum mainnet.** ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 14 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1081 https://eips.ethereum.org/EIPS/eip-1081 Net gas metering for SSTORE operations Standards Track/Core https://ethereum-magicians.org/t/eip-net-storage-gas-metering-for-the-evm/383 ## Abstract This EIP proposes a change to how gas is charged for EVM `SSTORE` operations, in order to reduce excessive gas costs in situations where these are unwarranted, and to enable new use-cases for contract storage. ## Motivation Presently, `SSTORE` (`0x55`) operations are charged as follows: - 20,000 gas to set a slot from 0 to non-0 - 5,000 gas for any other change - A 10,000 gas refund when a slot is set from non-0 to 0. Refunds are applied at the end of the transaction. In situations where a single update is made to a storage value in a transaction, these gas costs have been determined to fairly reflect the resources consumed by the operation. However, this results in excessive gas costs for sequences of operations that make multiple updates. Some examples to illustrate the problem: - If a contract with empty storage sets slot 0 to 1, then back to 0, it will be charged `20000 + 5000 - 10000 = 15000` gas, despite this sequence of operations not requiring any disk writes. - A contract with empty storage that increments slot 0 5 times will be charged `20000 + 5 * 5000 = 45000` gas, despite this sequence of operations requiring no more disk activity than a single write, charged at 20000 gas. - A balance transfer from account A to account B followed by a transfer from B to C, with all accounts having nonzero starting and ending balances, will cost `5000 * 4 = 20000` gas. Addressing this issue would also enable new use-cases that are currently cost-prohibitive, where a sequence of operations results in no net change to storage at the end of the transaction. For instance, mutexes to prevent reentrancy, or context information passed between multiple calls to the same contract. One such example is an `approveAndCall` operation, which would permit sending to and calling a contract in a single transaction, without that contract having to be updated for a new token standard. ## Specification The following changes are made to the EVM: - A 'dirty map' for each transaction is maintained, tracking all storage slots in all contracts that have been modified in the current transaction. The dirty map is scoped in the same manner as updates to storage, meaning that changes to the dirty map in a call that later reverts are not retained. - When a storage slot is written to with the value it already contains, 200 gas is deducted. - When a storage slot's value is changed for the first time, the slot is marked as dirty. If the slot was previously set to 0, 20000 gas is deducted; otherwise, 5000 gas is deducted. - When a storage slot that is already in the dirty map is written to, 200 gas is deducted. - At the end of the transaction, for each slot in the dirty map: - If the slot was 0 before the transaction and is 0 now, refund 19800 gas. - If the slot was nonzero before the transaction and its value has not changed, refund 4800 gas. - If the slot was nonzero before the transaction and is 0 now, refund 15000 gas. After these changes, transactions that make only a single change to a storage slot will retain their existing costs. However, contracts that make multiple changes will see significantly reduced costs. Repeating the examples from the Motivation section: - If a contract with empty storage sets slot 0 to 1, then back to 0, it will be charged `20000 + 200 - 19800 = 400` gas, down from 15000. - A contract with empty storage that increments slot 0 5 times will be charged `20000 + 5 * 200 = 21000` gas, down from 45000. - A balance transfer from account A to account B followed by a transfer from B to C, with all accounts having nonzero starting and ending balances, will cost `5000 * 3 + 200 - 4800 = 10400` gas, down from 20000. ## Rationale We believe the proposed mechanism represents the simplest way to reduce storage gas costs in situations where they do not reflect the actual costs borne by nodes. Several alternative designs were considered and dismissed: - Charging a flat 200 gas for `SSTORE` operations, and an additional 19800 / 4800 at the end of a transaction for new or modified values is simpler, and removes the need for a dirty map, but pushes a significant source of gas consumption out of the EVM stack and applies it at the end of the transaction, which is likely to complicate debugging and reduces contracts' ability to limit the gas consumption of callees, as well as introducing a new mechanism to the EVM. - Keeping a separate refund counter for storage gas refunds would avoid the issue of refunds being limited to half the gas consumed (not necessary here), but would introduce additional complexity in tracking this value. - Refunding gas each time a storage slot is set back to its initial value would introduce a new mechanism (instant refunds) and complicate gas accounting for contracts calling other contracts; it would also permit the possibility of a contract call with negative execution cost. ## Backwards Compatibility This EIP requires a hard fork to implement. No contract should see an increase in gas cost for this change, and many will see decreased gas consumption, so no contract-layer backwards compatibility issues are anticipated. ## Test Cases - Writing x to a storage slot that contains 0, where x != 0 (20k gas, no refund) - Writing y to a storage slot that contained x, where x != y and x != 0 (5k gas, no refund) - Writing 0 to a storage slot that contains x, where x != 0 (5k gas, 10k refund) - Writing 0 to a storage slot that already contains zero (200 gas, no refund) - Writing x to a storage slot that already contains x, where x != 0 (200 gas, no refund) - Writing x, then y to a storage slot that contains 0, where x != y (20200 gas, no refund) - Writing x, then y to a storage slot that contains 0, where x != y != z and x != 0 (5200 gas, no refund) - Writing x, then 0 to a storage slot that contains 0, where x != 0 (20200 gas, 19800 refund) - Writing x, then y to a storage slot that contains y, where x != y != 0 (5200 gas, 4800 refund) - Writing x, then 0 to a storage slot that contains 0, then reverting the stack frame in which the writes occurred (20200 gas, no refund) - Writing x, then y to a storage slot that contains y, then reverting the stack frame in which the writes occurred (5200 gas, no refund) - In a nested frame, writing x to a storage slot that contains 0, then returning, and writing 0 to that slot (20200 gas, 19800 refund) ## Implementation TBD ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 17 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1087 https://eips.ethereum.org/EIPS/eip-1087 Opt-in account exposure Standards Track/Interface https://ethereum-magicians.org/t/eip-1102-opt-in-provider-access/414 ## Simple summary This proposal describes a communication protocol between dapps and Ethereum-enabled DOM environments that allows the Ethereum-enabled DOM environment to choose what information to supply the dapp with and when. ## Abstract The previous generation of Ethereum-enabled DOM environments follows a pattern of injecting a provider populated with accounts without user consent. This puts users of such environments at risk because malicious websites can use these accounts to view detailed account information and to arbitrarily initiate unwanted transactions on a user's behalf. This proposal outlines a protocol in which Ethereum-enabled DOM environments can choose to expose no accounts until the user approves account access. ## Specification ### Concepts #### RFC-2119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119](https://www.ietf.org/rfc/rfc2119.txt). #### `eth_requestAccounts` Providers exposed by Ethereum-enabled DOM environments define a new RPC method: `eth_requestAccounts`. Calling this method may trigger a user interface that allows the user to approve or reject account access for a given dapp. This method returns a `Promise` that is resolved with an `Array` of accounts or is rejected with an `Error` if accounts are not available. ```typescript ethereum.send('eth_requestAccounts'): Promise<Array<string>> ``` #### Provider#enable (DEPRECATED) **Note: This method is deprecated in favor of the RPC method [`eth_requestAccounts`](#eth_requestaccounts).** Providers exposed by Ethereum-enabled DOM environments define a new RPC method: `ethereum.enable()`. Calling this method triggers a user interface that allows the user to approve or reject account access for a given dapp. This method returns a `Promise` that is resolved with an `Array` of accounts if the user approves access or rejected with an `Error` if the user rejects access. ```typescript ethereum.enable(): Promise<any> ``` ### Protocol #### Legacy dapp initialization ``` START dapp IF web3 is defined CONTINUE dapp IF web3 is undefined STOP dapp ``` #### Proposed dapp initialization ``` START dapp IF provider is defined REQUEST[1] account access IF user approves RESOLVE[2] account access CONTINUE dapp IF user rejects REJECT[3] account access STOP dapp IF provider is undefined STOP dapp ``` ##### `[1] REQUEST` Dapps **MUST** request accounts by calling the `eth_requestAccounts` RPC method on the provider exposed at `window.ethereum`. Calling this method **MAY** trigger a user interface that allows the user to approve or reject account access for a given dapp. This method **MUST** return a `Promise` that is resolved with an array of one or more user accounts or rejected if no accounts are available (e.g., the user rejected account access). ##### `[2] RESOLVE` The `Promise` returned when calling the `eth_requestAccounts` RPC method **MUST** be resolved with an `Array` of user accounts. ##### `[3] REJECT` The `Promise` returned when calling the `eth_requestAccounts` RPC method **MUST** be rejected with an informative `Error` if no accounts are available for any reason. ### Example initialization ```js try { // Request account access if needed const accounts = await ethereum.send('eth_requestAccounts'); // Accounts now exposed, use them ethereum.send('eth_sendTransaction', { from: accounts[0], /* ... */ }) } catch (error) { // User denied account access } ``` ### Constraints * Browsers **MUST** expose a provider at `window.ethereum` . * Browsers **MUST** define an `eth_requestAccounts` RPC method. * Browsers **MAY** wait for a user interaction before resolving/rejecting the `eth_requestAccounts` promise. * Browsers **MUST** include at least one account if the `eth_requestAccounts` promise is resolved. * Browsers **MUST** reject the promise with an informative error if no accounts are available. ## Rationale The pattern of automatic account exposure followed by the previous generation of Ethereum-enabled DOM environments fails to protect user privacy and fails to maintain safe user experience: untrusted websites can both view detailed account information and arbitrarily initiate transactions on a user's behalf. Even though most users may reject unsolicited transactions on untrusted websites, a protocol for account access should make such unsolicited requests impossible. This proposal establishes a new pattern wherein dapps must request access to user accounts. This protocol directly strengthens user privacy by allowing the browser to hide user accounts and preventing unsolicited transaction requests on untrusted sites. ### Immediate value-add * Users can reject account access on untrusted sites to hide accounts. * Users can reject account access on untrusted sites to prevent unsolicited transactions. ### Long-term value-add * Dapps could request specific account information based on user consent. * Dapps could request specific user information based on user consent (uPort, DIDs). * Dapps could request a specific network based on user consent. * Dapps could request multiple instances of the above based on user consent. ## Backwards compatibility This proposal impacts dapp developers and requires that they request access to user accounts following the protocol outlined above. Similarly, this proposal impacts dapp browser developers and requires that they only expose user accounts following the protocol defined above. ## Implementation The MetaMask team [has implemented](https://github.com/MetaMask/metamask-extension/pull/4703) the strategy described above. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 04 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1102 https://eips.ethereum.org/EIPS/eip-1102 Reduce alt_bn128 precompile gas costs Standards Track/Core https://ethereum-magicians.org/t/eip-1108-reduce-alt-bn128-precompile-gas-costs/3206 ## Simple Summary The elliptic curve arithmetic precompiles are currently overpriced. Re-pricing the precompiles would greatly assist a number of privacy solutions and scaling solutions on Ethereum. ## Abstract Changes in 2018 to the underlying library used by the official Go reference implementation led to significant performance gains for the `ECADD`, `ECMUL`, and pairing check precompiled contracts on the `alt_bn128` elliptic curve. In the Parity client, field operations used by the precompile algorithms were optimized in 2018, and recent changes to the pairing algorithm used by the `bn` crate have brought considerable speedups. Faster operations on Ethereum clients should be reflected in reduced gas costs. ## Motivation Recently, the underlying library used by the [official Go reference implementation](https://github.com/ethereum/go-ethereum) to implement the `ECADD` (at address `0x06`), `ECMUL` (at address `0x07`), and pairing check (at address `0x08`) precompiled contracts was shifted to [Cloudflare's bn256 library](https://github.com/cloudflare/bn256). Based on the [initial PR that introduced this change](https://github.com/ethereum/go-ethereum/pull/16203), and corroborated in [a later note](https://github.com/ethereum/go-ethereum/pull/16301#issuecomment-372687543), the computational cost of `ECADD`, `ECMUL`, and pairing checks (excepting the constant) has dropped roughly an order of magnitude across the board. Also, optimizations in the bn library [in 2018](https://github.com/paritytech/bn/pull/9) and [2019](https://github.com/paritytech/bn/pull/14) used by the [Parity client](https://github.com/paritytech/parity-ethereum) led to a significant performance boost we [benchmarked](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53) and compared against the [previous results](https://gist.github.com/pdyraga/4649b74436940a01e8221d85e80bfeef). ## Specification Following is a table with the current gas cost and new gas cost: | Contract | Address | Current Gas Cost | Updated Gas Cost | | ------------- | --------- | ----------------------------- | ------------------- | | `ECADD` | `0x06` | 500<sup>[1]</sup> | 150 | | `ECMUL` | `0x07` | 40 000<sup>[1]</sup> | 6 000 | | Pairing check | `0x08` | 80 000 * k + 100 000<sup>[2]</sup>| 34 000 * k + 45 000 | The gas costs for `ECADD` and `ECMUL` are updates to the costs listed in EIP-196, while the gas costs for the pairing check are updates to the cost listed in EIP-197. Updated gas costs have been adjusted to the less performant client which is Parity, according to benchmarks<sup>[3]</sup>. To come up with these updates gas costs, the performance of the `ecrecover` precompile was measured at 116 microseconds per `ecrecover` invocation. Assuming the `ecrecover` gas price is fair at 3,000 gas, we get a price of 25.86 gas per microsecond of a precompile algorithm's runtime. With this in mind, the pairing precompile took 3,037 microseconds to compute 1 pairing, and 14,663 microseconds to compute 10 pairings. From this, the pairing algorithm has a fixed 'base' run-time of 1,745 microseconds, plus 1,292 microseconds per pairing. We can split the run-time into 'fixed cost' and 'linear cost per pairing' components because of the structure of the algorithm. Thus using a 'fair' price of 25.86 gas per microsecond, we get a gas formula of ~`35,000 * k + 45,000` gas, where `k` is the number of pairings being computed. [4] [1]- Per [EIP-196](/EIPS/eip-196). [2]- Per [EIP-197](/EIPS/eip-197). [3]- [Parity benchmarks.](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53) [4]- [PR comment clarifying gas cost math](https://github.com/ethereum/EIPs/pull/1987#discussion_r280977066). ## Rationale ### Existing protocols would benefit immensely from cheaper elliptic curve cryptography Fast elliptic curve cryptography is a keystone of a growing number of protocols built on top of Ethereum. To list a few: * [The AZTEC protocol](https://github.com/AztecProtocol/AZTEC) utilizes the elliptic curve precompiles to construct private tokens, with zero-knowledge transaction logic, via the [ERC-1723](https://github.com/ethereum/EIPs/issues/1723) and [ERC-1724](https://github.com/ethereum/EIPs/issues/1724) standard. * [Matter Labs](https://github.com/matter-labs/matter-network) utilizes the precompiles to implement Ignis, a scaling solution with a throughput of 500txns per second * [Rollup](https://github.com/rollup/rollup) utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is guaranteed by main-net, without an additional consensus layer * ZEther[^1] uses precompiles `ECADD` and `ECMUL` to construct confidential transactions [^1]: ```csl-json { "publisher-place": "Cham", "URL": "https://eprint.iacr.org/2019/191.pdf", "custom": { "additional-urls": [ "https://web.archive.org/web/20220819003610/https://crypto.stanford.edu/~buenz/papers/zether.pdf" ] }, "DOI": "10.1007/978-3-030-51280-4_23", "abstract": "Smart contract platforms such as Ethereum and Libra provide ways to seamlessly remove trust and add transparency to various distributed applications. Yet, these platforms lack mechanisms to guarantee user privacy, even at the level of simple payments, which are essential for most smart contracts.", "author": [ { "given": "Benedikt", "family": "Bünz" }, { "given": "Shashank", "family": "Agrawal" }, { "given": "Mahdi", "family": "Zamani" }, { "given": "Dan", "family": "Boneh" } ], "container-title": "Financial Cryptography and Data Security", "editor": [ { "given": "Joseph", "family": "Bonneau" }, { "given": "Nadia", "family": "Heninger" } ], "type": "paper-conference", "id": "10.1007/978-3-030-51280-4_23", "citation-key": "10.1007/978-3-030-51280-4_23", "ISBN": "978-3-030-51280-4", "issued": { "date-parts": [ [ 2020 ] ] }, "page": "423-443", "publisher": "Springer International Publishing", "title": "Zether: Towards Privacy in a Smart Contract World" } ``` These are all technologies that have been, or are in the process of being, deployed to main-net. These protocols would all benefit from reducing the gas cost of the precompiles. To give a concrete example, it currently costs `820,000` gas to validate the cryptography in a typical AZTEC confidential transaction. If the gas schedule for the precompiles correctly reflected their load on the Ethereum network, this cost would be `197,000` gas. This significantly increases the potential use cases for private assets on Ethereum. AZTEC is planning to deploy several cryptographic protocols Ethereum, but these are at the limits of what is practical given the current precompile costs: * Confidential weighted voting * Partial-order filling over encrypted orders, for private decentralized exchanges * Anonymous identity sharing proofs (e.g. proving you are on a whitelist, without revealing who you are) * Many-to-one payments and one-to-many confidential payments, as encrypted communication channels between main-net and L2 applications For zk-SNARK based protocols on Ethereum, EIP-1108 will not only reduce the gas costs of verifying zk-SNARKs substantially, but can also aid in [batching together multiple zk-SNARK proofs](https://github.com/matter-labs/Groth16BatchVerifier). This is also a technique that can be used to split up monolithic zk-SNARK circuits into a batch of zk-SNARKs with smaller individual circuit sizes, which makes zk-SNARKs both easier to construct and deploy. ZEther transactions currently cost ~`6,000,000` gas. This EIP would reduce this to ~`1,000,000` gas, which makes the protocol more practical. To summarise, there are several protocols that currently exist on main-net, that would benefit immensely from this EIP. Elliptic curve cryptography can provide valuable solutions for Ethereum, such as scaling and privacy, and the scope and scale of these solutions can be increased if the gas costs for the `bn128` precompiles accurately reflects their computational load on the network. ### Cheaper elliptic curve cryptography can be used to trade storage for computation Solutions such as Rollup and Ignis can be used to batch groups of individual transactions into a zk-SNARK proof, with the on-chain state being represented by a small Merkle root, instead of multiple account balances. If zk-SNARK verification costs are decreased, these solutions can be deployed for a wider range of use cases and more Rollup-style transactions can be processed per block. ### Parity and Geth already have fast algorithms that justify reduced gas costs This EIP does not require Parity or Geth to deploy new cryptographic libraries, as fast bn128 algorithms have already been integrated into these clients. This goal of proposing this EIP for Istanbul, is to supplement [EIP-1829](/EIPS/eip-1829) (arithmetic over generic elliptic curves), providing an immediate solution to the pressing problem of expensive cryptography, while more advanced solutions are developed, defined and deployed. ## Test Cases As no underlying algorithms are being changed, there are no additional test cases to specify. ## Implementation Both the Parity and Geth clients have already implemented cryptographic libraries that are fast enough to justify reducing the precompile gas costs. As a reference, here are a list of elliptic curve libraries, in `C++`, `golang` and `rust`, that support the `bn128` curve, and have run-times that are equal to or faster than the Parity benchmarks. * [Parity bn crate (rust)](https://github.com/paritytech/bn) * [Geth bn256 library (golang)](https://github.com/ethereum/go-ethereum/tree/master/crypto/bn256/cloudflare) * [MCL, a portable C++ pairing library](https://github.com/herumi/mcl) * [Libff, a C++ pairing library used in many zk-SNARK libraries](https://github.com/scipr-lab/libff) ## Additional References @vbuterin independently proposed a similar reduction after this EIP was originally created, with similar rationale, as [ethereum/EIPs#1187](https://github.com/ethereum/EIPs/issues/1187). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 21 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1108 https://eips.ethereum.org/EIPS/eip-1108 PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts) Standards Track/Core https://ethereum-magicians.org/t/eip-1109-remove-call-costs-for-precompiled-contracts/447 ## Simple Summary This EIP creates a specific opcode named `PRECOMPILEDCALL` to call Precompiled contracts without the costs of a normal `CALL`. ## Abstract This EIP tries to resolve the problem of high gas consumption when calling precompiled contracts with a small gas cost. Using this opcode for calling precompiled contracts allows to define precompiled contracts whose effective cost it is less than 700. ## Motivation Each precompiled contract has an already defined cost for calling it. It does not make sense to add the implicit extra gas cost of the CALL opcode. As an example, SHA256 precompiled contract costs 60 and ECADD costs 500 (proposed to costs only 50 in [EIP-1108](/EIPS/eip-1108) . When a precompiled contract is called, 700 gas is consumed just for the CALL opcode besides the costs of the precompiled contract. This makes no sense, and right now it's impossible to define a precompiled contract whose effective cost for using it, is less than 700. ## Specification If `block.number >= XXXXX`, define a new opcode named `PRECOMPILEDCALL` with code value `0xfb`. The gas cost of the OPCODE is 2 (Gbase) plus the Specific gas cost defined for each specific precompiled smart contract. The OPCODE takes 5 words from the stack and returns 1 word to the stack. The input stack values are: mu_s[0] = The address of the precompiled smart contract that is called. mu_s[1] = Pointer to memory for the input parameters. mu_s[2] = Length of the input parameters in bytes. mu_s[3] = Pointer to memory where the output is stored mu_s[4] = Length of the output buffer. The return will be 1 in case of success call and 0 in any of the next cases: 1.- mu_s[0] is an address of an undefined precompiled smart contract. 2.- The precompiled smart contract fails (as defined on each smart contract). Invalid input parameters for example. Precompiled smart contracts, does not execute opcodes, so there is no need to pass a gas parameter as a normal `CALL` (`0xf1`). If the available gas is less that 2 plus the required gas required for the specific precompiled smart contract, the context just STOPS executing with an "Out of Gas" error. There is no stack check for this call. The normal `CALL`s to the precompiled smart contracts continue to work with the exact same behavior. A `PRECOMPILEDCALL` to a regular address or regular smart contract, is considered a call to an "undefined smart contract", so the VM MUST not execute it and the opcode must return 0x0 . ## Rationale There was a first proposal for removing the gast consts for the `CALL`, but it looks that it's easier to implement and test a new opcode just for that. The code is just the next opcode available after the `STATICCALL` opcode. ## Backwards Compatibility This EIP is backwards compatible. Smart contracts that call precompiled contracts using this new opcode will cost less from now on. Old contracts that call precompiled smart contracts with the `CALL` method, will continue working. ## Test Cases - Normal call to a defined precompiled contract. - Call to undefined precompiled contract. - Call to a regular contract - Call to a regular account - Call to 0x0 smart contract (Does not exists). - Call with large values for the offste pointers and lengths - Call with the exact gas remaining needed to call smart contract. - Call with the exact gas remaining minus one needed to call smart contract. ## Implementation Not implemented yet. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 22 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1109 https://eips.ethereum.org/EIPS/eip-1109 Revised Ethereum Smart Contract Packaging Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1123 This ERC has been abandoned in favor of the EthPM V3 smart contract packaging standard defined in [ERC-2678](/EIPS/eip-2678) Simple Summary ============== A data format describing a smart contract software package. Abstract ========== This EIP defines a data format for *package manifest* documents, representing a package of one or more smart contracts, optionally including source code and any/all deployed instances across multiple networks. Package manifests are minified JSON objects, to be distributed via content addressable storage networks, such as IPFS. This document presents a natural language description of a formal specification for version **2** of this format. Motivation ========== This standard aims to encourage the Ethereum development ecosystem towards software best practices around code reuse. By defining an open, community-driven package data format standard, this effort seeks to provide support for package management tools development by offering a general-purpose solution that has been designed with observed common practices in mind. As version 2 of this specification, this standard seeks to address a number of areas of improvement found for the previous version (defined in [EIP-190](/EIPS/eip-190)). This version: - Generalizes storage URIs to represent any content addressable URI scheme, not only IPFS. - Renames *release lockfile* to *package manifest*. - Adds support for languages other than Solidity by generalizing the compiler information format. - Redefines link references to be more flexible, to represent arbitrary gaps in bytecode (besides only addresses), in a more straightforward way. - Forces format strictness, requiring that package manifests contain no extraneous whitespace, and sort object keys in alphabetical order, to prevent hash mismatches. <div id="package-specification"></div> Specification ============= This document defines the specification for an EthPM package manifest. A package manifest provides metadata about a [Package](#term-package), and in most cases should provide sufficient information about the packaged contracts and its dependencies to do bytecode verification of its contracts. > **Note** > > A [hosted > version](https://ethpm.github.io/ethpm-spec) of this > specification is available via GitHub Pages. This EIP and the hosted > HTML document were both autogenerated from the same documentation > source. Guiding Principles ------------------ This specification makes the following assumptions about the document lifecycle. 1. Package manifests are intended to be generated programmatically by package management software as part of the release process. 2. Package manifests will be consumed by package managers during tasks like installing package dependencies or building and deploying new releases. 3. Package manifests will typically **not** be stored alongside the source, but rather by package registries *or* referenced by package registries and stored in something akin to IPFS. Conventions ----------- ### RFC2119 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. - <https://www.ietf.org/rfc/rfc2119.txt> ### Prefixed vs Unprefixed A [prefixed](#term-prefixed) hexadecimal value begins with `0x`. [Unprefixed](#term-unprefixed) values have no prefix. Unless otherwise specified, all hexadecimal values **should** be represented with the `0x` prefix. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Prefixed</p></td> <td><p><code>0xdeadbeef</code></p></td> </tr> <tr class="even"> <td><p>Unprefixed</p></td> <td><p><code>deadbeef</code></p></td> </tr> </tbody> </table> Document Format --------------- The canonical format is a single JSON object. Packages **must** conform to the following serialization rules. - The document **must** be tightly packed, meaning no linebreaks or extra whitespace. - The keys in all objects must be sorted alphabetically. - Duplicate keys in the same object are invalid. - The document **must** use [UTF-8](https://en.wikipedia.org/wiki/UTF-8) encoding. - The document **must** not have a trailing newline. Document Specification ---------------------- The following fields are defined for the package. Custom fields **may** be included. Custom fields **should** be prefixed with `x-` to prevent name collisions with future versions of the specification. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>See Also</p></td> <td><p>Formalized (<a href="https://json-schema.org">JSON-Schema</a>) version of this specification: <a href="https://github.com/ethpm/ethpm-spec/tree/v2.0.0/spec/package.spec.json">package.spec.json</a></p></td> </tr> <tr class="even"> <td><p>Jump To</p></td> <td><p><a href="#definitions">Definitions</a></p></td> </tr> </tbody> </table> <div id="manifest-version"></div> ### EthPM Manifest Version: `manifest_version` The `manifest_version` field defines the specification version that this document conforms to. Packages **must** include this field. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>manifest_version</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="even"> <td><p>Allowed Values</p></td> <td><p><code>2</code></p></td> </tr> </tbody> </table> <div id="package-names"></div> ### Package Name: `package_name` The `package_name` field defines a human readable name for this package. Packages **must** include this field. Package names **must** begin with a lowercase letter and be comprised of only lowercase letters, numeric characters, and the dash character `-`. Package names **must** not exceed 214 characters in length. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>package_name</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="even"> <td><p>Format</p></td> <td><p><strong>must</strong> match the regular expression <code>^[a-zA-Z][a-zA-Z0-9_]{0,255}$</code></p></td> </tr> </tbody> </table> ### Package Meta: `meta` The `meta` field defines a location for metadata about the package which is not integral in nature for package installation, but may be important or convenient to have on-hand for other reasons. This field **should** be included in all Packages. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>meta</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p><a href="#package-meta-object">Package Meta Object</a></p></td> </tr> </tbody> </table> ### Version: `version` The `version` field declares the version number of this release. This value **must** be included in all Packages. This value **should** conform to the [semver](https://semver.org/) version numbering specification. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>version</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>String</p></td> </tr> </tbody> </table> ### Sources: `sources` The `sources` field defines a source tree that **should** comprise the full source tree necessary to recompile the contracts contained in this release. Sources are declared in a key/value mapping. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Key</p></td> <td><p><code>sources</code></p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object (String: String)</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>See Below.</p></td> </tr> </tbody> </table> #### Format Keys **must** be relative filesystem paths beginning with a `./`. Paths **must** resolve to a path that is within the current working directory. Values **must** conform to *one of* the following formats. - Source string. - [Content Addressable URI](#term-content-addressable-uri). When the value is a source string the key should be interpreted as a file path. - If the resulting document is a directory the key should be interpreted as a directory path. - If the resulting document is a file the key should be interpreted as a file path. ### Contract Types: `contract_types` The `contract_types` field holds the [Contract Types](#term-contract-type) which have been included in this release. [Packages](#term-package) **should** only include contract types that can be found in the source files for this package. Packages **should not** include contract types from dependencies. Packages **should not** include abstract contracts in the contract types section of a release. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Key</p></td> <td><p><code>contract_types</code></p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object (String: <a href="#contract-type-object">Contract Type Object</a>)</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>Keys <strong>must</strong> be valid <a href="#term-contract-alias">Contract Aliases</a>.</p> <p>Values <strong>must</strong> conform to the <a href="#contract-type-object">Contract Type Object</a> definition.</p></td> </tr> </tbody> </table> ### Deployments: `deployments` The `deployments` field holds the information for the chains on which this release has [Contract Instances](#term-contract-instance) as well as the [Contract Types](#term-contract-type) and other deployment details for those deployed contract instances. The set of chains defined by the `*BIP122 URI <#bip122-uris>*` keys for this object **must** be unique. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Key</p></td> <td><p><code>deployments</code></p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object (String: Object(String: <a href="#contract-instance-object">Contract Instance Object</a>))</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>See Below.</p></td> </tr> </tbody> </table> #### Format Keys **must** be a valid BIP122 URI chain definition. Values **must** be objects which conform to the following format. - Keys **must** be valid [Contract Instance Names](#term-contract-instance-name). - Values **must** be a valid [Contract Instance Object](#contract-instance-object). ### Build Dependencies: `build_dependencies` The `build_dependencies` field defines a key/value mapping of Ethereum [Packages](#term-package) that this project depends on. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>build_dependencies</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>Object (String: String)</p></td> </tr> <tr class="even"> <td><p>Format</p></td> <td><p>Keys <strong>must</strong> be valid <a href="#package-names">package names</a> matching the regular expression <code>[a-z][-a-z0-9]{0,213}</code>.</p> <p>Values <strong>must</strong> be valid IPFS URIs which resolve to a valid package.</p></td> </tr> </tbody> </table> Definitions ----------- Definitions for different objects used within the Package. All objects allow custom fields to be included. Custom fields **should** be prefixed with `x-` to prevent name collisions with future versions of the specification. <div id="link-reference-object"></div> ### The *Link Reference* Object A [Link Reference](#term-link-reference) object has the following key/value pairs. All link references are assumed to be associated with some corresponding [Bytecode](#term-bytecode). #### Offsets: `offsets` The `offsets` field is an array of integers, corresponding to each of the start positions where the link reference appears in the bytecode. Locations are 0-indexed from the beginning of the bytes representation of the corresponding bytecode. This field is invalid if it references a position that is beyond the end of the bytecode. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Array</p></td> </tr> </tbody> </table> #### Length: `length` The `length` field is an integer which defines the length in bytes of the link reference. This field is invalid if the end of the defined link reference exceeds the end of the bytecode. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Integer</p></td> </tr> </tbody> </table> #### Name: `name` The `name` field is a string which **must** be a valid [Identifier](#term-identifier). Any link references which **should** be linked with the same link value **should** be given the same name. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> conform to the <a href="#term-identifier">Identifier</a> format.</p></td> </tr> </tbody> </table> <div id="link-value-object"></div> ### The *Link Value* Object Describes a single [Link Value](#term-link-value). A **Link Value object** is defined to have the following key/value pairs. <div id="offset-offset-1"></div> #### Offsets: `offsets` The `offsets` field defines the locations within the corresponding bytecode where the `value` for this link value was written. These locations are 0-indexed from the beginning of the bytes representation of the corresponding bytecode. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Integer</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>See Below.</p></td> </tr> </tbody> </table> **Format** Array of integers, where each integer **must** conform to all of the following. - greater than or equal to zero - strictly less than the length of the unprefixed hexadecimal representation of the corresponding bytecode. #### Type: `type` The `type` field defines the `value` type for determining what is encoded when [linking](#term-linking) the corresponding bytecode. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Allowed Values</p></td> <td><p><code>&quot;literal&quot;</code> for bytecode literals</p> <p><code>&quot;reference&quot;</code> for named references to a particular <a href="#term-contract-instance">Contract Instance</a></p></td> </tr> </tbody> </table> #### Value: `value` The `value` field defines the value which should be written when [linking](#term-linking) the corresponding bytecode. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>Determined based on <code>type</code>, see below.</p></td> </tr> </tbody> </table> **Format** For static value *literals* (e.g. address), value **must** be a *byte string* To reference the address of a [Contract Instance](#term-contract-instance) from the current package the value should be the name of that contract instance. - This value **must** be a valid contract instance name. - The chain definition under which the contract instance that this link value belongs to must contain this value within its keys. - This value **may not** reference the same contract instance that this link value belongs to. To reference a contract instance from a [Package](#term-package) from somewhere within the dependency tree the value is constructed as follows. - Let `[p1, p2, .. pn]` define a path down the dependency tree. - Each of `p1, p2, pn` **must** be valid package names. - `p1` **must** be present in keys of the `build_dependencies` for the current package. - For every `pn` where `n > 1`, `pn` **must** be present in the keys of the `build_dependencies` of the package for `pn-1`. - The value is represented by the string `<p1>:<p2>:<...>:<pn>:<contract-instance>` where all of `<p1>`, `<p2>`, `<pn>` are valid package names and `<contract-instance>` is a valid [Contract Name](#term-contract-name). - The `<contract-instance>` value **must** be a valid [Contract Instance Name](#term-contract-instance-name). - Within the package of the dependency defined by `<pn>`, all of the following must be satisfiable: - There **must** be *exactly* one chain defined under the `deployments` key which matches the chain definition that this link value is nested under. - The `<contract-instance>` value **must** be present in the keys of the matching chain. ### The *Bytecode* Object A bytecode object has the following key/value pairs. #### Bytecode: `bytecode` The `bytecode` field is a string containing the `0x` prefixed hexadecimal representation of the bytecode. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><code>0x</code> prefixed hexadecimal.</p></td> </tr> </tbody> </table> #### Link References: `link_references` The `link_references` field defines the locations in the corresponding bytecode which require [linking](#term-linking). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Array</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>All values <strong>must</strong> be valid <a href="#link-reference-object">Link Reference objects</a>. See also below.</p></td> </tr> </tbody> </table> **Format** This field is considered invalid if *any* of the [Link References](#term-link-reference) are invalid when applied to the corresponding `bytecode` field, *or* if any of the link references intersect. Intersection is defined as two link references which overlap. #### Link Dependencies: `link_dependencies` The `link_dependencies` defines the [Link Values](#term-link-value) that have been used to link the corresponding bytecode. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Array</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>All values <strong>must</strong> be valid <a href="#link-value-object">Link Value objects</a>. See also below.</p></td> </tr> </tbody> </table> **Format** Validation of this field includes the following: - Two link value objects **must not** contain any of the same values for `offsets`. - Each [link value object](#link-value-object) **must** have a corresponding [link reference object](#link-reference-object) under the `link_references` field. - The length of the resolved `value` **must** be equal to the `length` of the corresponding [Link Reference](#term-link-reference). <div id="package-meta-object"></div> ### The *Package Meta* Object The *Package Meta* object is defined to have the following key/value pairs. #### Authors: `authors` The `authors` field defines a list of human readable names for the authors of this package. Packages **may** include this field. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>authors</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>Array (String)</p></td> </tr> </tbody> </table> #### License: `license` The `license` field declares the license under which this package is released. This value **should** conform to the [SPDX](https://en.wikipedia.org/wiki/Software_Package_Data_Exchange) format. Packages **should** include this field. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>license</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>String</p></td> </tr> </tbody> </table> #### Description: `description` The `description` field provides additional detail that may be relevant for the package. Packages **may** include this field. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>description</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>String</p></td> </tr> </tbody> </table> #### Keywords: `keywords` The `keywords` field provides relevant keywords related to this package. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>keywords</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>List of Strings</p></td> </tr> </tbody> </table> #### Links: `links` The `links` field provides URIs to relevant resources associated with this package. When possible, authors **should** use the following keys for the following common resources. - `website`: Primary website for the package. - `documentation`: Package Documentation - `repository`: Location of the project source code. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Key</p></td> <td><p><code>links</code></p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object (String: String)</p></td> </tr> </tbody> </table> <div id="contract-type-object"></div> ### The *Contract Type* Object A *Contract Type* object is defined to have the following key/value pairs. #### Contract Name: `contract_name` The `contract_name` field defines the [Contract Name](#term-contract-name) for this [Contract Type](#term-contract-type). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>If the <a href="#term-contract-name">Contract Name</a> and <a href="#term-contract-alias">Contract Alias</a> are not the same.</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> be a valid <a href="#term-contract-name">Contract Name</a>.</p></td> </tr> </tbody> </table> #### Deployment Bytecode: `deployment_bytecode` The `deployment_bytecode` field defines the bytecode for this [Contract Type](#term-contract-type). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> conform to <a href="#the-bytecode-object">the Bytecode Object</a> format.</p></td> </tr> </tbody> </table> #### Runtime Bytecode: `runtime_bytecode` The `runtime_bytecode` field defines the unlinked `0x`-prefixed runtime portion of [Bytecode](#term-bytecode) for this [Contract Type](#term-contract-type). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> conform to <a href="#the-bytecode-object">the Bytecode Object</a> format.</p></td> </tr> </tbody> </table> #### ABI: `abi` <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>List</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> conform to the <a href="https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#json">Ethereum Contract ABI JSON format</a>.</p></td> </tr> </tbody> </table> #### Natspec: `natspec` <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>The union of the <a href="https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format#user-documentation">UserDoc</a> and <a href="https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format#developer-documentation">DevDoc</a> formats.</p></td> </tr> </tbody> </table> #### Compiler: `compiler` <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> conform to <a href="#the-compiler-information-object">the Compiler Information object</a> format.</p></td> </tr> </tbody> </table> <div id="contract-instance-object"></div> ### The *Contract Instance* Object A **Contract Instance Object** represents a single deployed [Contract Instance](#term-contract-instance) and is defined to have the following key/value pairs. #### Contract Type: `contract_type` The `contract_type` field defines the [Contract Type](#term-contract-type) for this [Contract Instance](#term-contract-instance). This can reference any of the contract types included in this [Package](#term-package) *or* any of the contract types found in any of the package dependencies from the `build_dependencies` section of the [Package Manifest](#term-package-manifest). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>See Below.</p></td> </tr> </tbody> </table> **Format** Values for this field **must** conform to *one of* the two formats herein. To reference a contract type from this Package, use the format `<contract-alias>`. - The `<contract-alias>` value **must** be a valid [Contract Alias](#term-contract-alias). - The value **must** be present in the keys of the `contract_types` section of this Package. To reference a contract type from a dependency, use the format `<package-name>:<contract-alias>`. - The `<package-name>` value **must** be present in the keys of the `build_dependencies` of this Package. - The `<contract-alias>` value **must** be a valid [Contract Alias](#term-contract-alias). - The resolved package for `<package-name>` must contain the `<contract-alias>` value in the keys of the `contract_types` section. #### Address: `address` The `address` field defines the [Address](#term-address) of the [Contract Instance](#term-contract-instance). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p>Hex encoded <code>0x</code> prefixed Ethereum address matching the regular expression <code>0x[0-9a-fA-F]{40}</code>.</p></td> </tr> </tbody> </table> #### Transaction: `transaction` The `transaction` field defines the transaction hash in which this [Contract Instance](#term-contract-instance) was created. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><code>0x</code> prefixed hex encoded transaction hash.</p></td> </tr> </tbody> </table> #### Block: `block` The `block` field defines the block hash in which this the transaction which created this *contract instance* was mined. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>String</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><code>0x</code> prefixed hex encoded block hash.</p></td> </tr> </tbody> </table> <div id="runtime-bytecode-runtime-bytecode-1"></div> #### Runtime Bytecode: `runtime_bytecode` The `runtime_bytecode` field defines the runtime portion of bytecode for this [Contract Instance](#term-contract-instance). When present, the value from this field supersedes the `runtime_bytecode` from the [Contract Type](#term-contract-type) for this [Contract Instance](#term-contract-instance). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> conform to <a href="#the-bytecode-object">the Bytecode Object</a> format.</p></td> </tr> </tbody> </table> Every entry in the `link_references` for this bytecode **must** have a corresponding entry in the `link_dependencies` section. #### Compiler: `compiler` The `compiler` field defines the compiler information that was used during compilation of this [Contract Instance](#term-contract-instance). This field **should** be present in all [Contract Types](#term-contract-type) which include `bytecode` or `runtime_bytecode`. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Type</p></td> <td><p>Object</p></td> </tr> <tr class="odd"> <td><p>Format</p></td> <td><p><strong>must</strong> conform to the <a href="#compiler-information-object">Compiler Information Object</a> format.</p></td> </tr> </tbody> </table> <div id="compiler-information-object"></div> ### The *Compiler Information* Object The `compiler` field defines the compiler information that was used during compilation of this [Contract Instance](#term-contract-instance). This field **should** be present in all contract instances that locally declare `runtime_bytecode`. A *Compiler Information* object is defined to have the following key/value pairs. #### Name `name` The `name` field defines which compiler was used in compilation. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>name</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>String</p></td> </tr> </tbody> </table> #### Version: `version` The `version` field defines the version of the compiler. The field **should** be OS agnostic (OS not included in the string) and take the form of either the stable version in [semver](https://semver.org/) format or if built on a nightly should be denoted in the form of `<semver>-<commit-hash>` ex: `0.4.8-commit.60cc1668`. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>Yes</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>version</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>String</p></td> </tr> </tbody> </table> #### Settings: `settings` The `settings` field defines any settings or configuration that was used in compilation. For the `"solc"` compiler, this **should** conform to the [Compiler Input and Output Description](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#compiler-input-and-output-json-description). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Required</p></td> <td><p>No</p></td> </tr> <tr class="even"> <td><p>Key</p></td> <td><p><code>settings</code></p></td> </tr> <tr class="odd"> <td><p>Type</p></td> <td><p>Object</p></td> </tr> </tbody> </table> ### BIP122 URIs BIP122 URIs are used to define a blockchain via a subset of the [BIP-122](https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki) spec. blockchain://<genesis_hash>/block/<latest confirmed block hash> The `<genesis hash>` represents the blockhash of the first block on the chain, and `<latest confirmed block hash>` represents the hash of the latest block that’s been reliably confirmed (package managers should be free to choose their desired level of confirmations). Rationale ========= The following use cases were considered during the creation of this specification. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>owned</p></td> <td><p>A package which contains contracts which are not meant to be used by themselves but rather as base contracts to provide functionality to other contracts through inheritance.</p></td> </tr> <tr class="even"> <td><p>transferable</p></td> <td><p>A package which has a single dependency.</p></td> </tr> <tr class="odd"> <td><p>standard-token</p></td> <td><p>A package which contains a reusable contract.</p></td> </tr> <tr class="even"> <td><p>safe-math-lib</p></td> <td><p>A package which contains deployed instance of one of the package contracts.</p></td> </tr> <tr class="odd"> <td><p>piper-coin</p></td> <td><p>A package which contains a deployed instance of a reusable contract from a dependency.</p></td> </tr> <tr class="even"> <td><p>escrow</p></td> <td><p>A package which contains a deployed instance of a local contract which is linked against a deployed instance of a local library.</p></td> </tr> <tr class="odd"> <td><p>wallet</p></td> <td><p>A package with a deployed instance of a local contract which is linked against a deployed instance of a library from a dependency.</p></td> </tr> <tr class="even"> <td><p>wallet-with-send</p></td> <td><p>A package with a deployed instance which links against a deep dependency.</p></td> </tr> </tbody> </table> Each use case builds incrementally on the previous one. A full listing of [Use Cases](https://ethpm.github.io/ethpm-spec/use-cases.html) can be found on the hosted version of this specification. Glossary ========== <div id="term-abi"></div> ABI --- The JSON representation of the application binary interface. See the official [specification](https://solidity.readthedocs.io/en/develop/abi-spec.html) for more information. <div id="term-address"></div> Address ------- A public identifier for an account on a particular chain <div id="term-bytecode"></div> Bytecode -------- The set of EVM instructions as produced by a compiler. Unless otherwise specified this should be assumed to be hexadecimal encoded, representing a whole number of bytes, and [prefixed](#term-prefixed) with `0x`. Bytecode can either be linked or unlinked. (see [Linking](#term-linking)) <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Unlinked Bytecode</p></td> <td><p>The hexadecimal representation of a contract’s EVM instructions that contains sections of code that requires <a href="#term-linking">linking</a> for the contract to be functional.</p> <p>The sections of code which are unlinked <strong>must</strong> be filled in with zero bytes.</p> <p><strong>Example</strong>: <code>0x606060405260e06000730000000000000000000000000000000000000000634d536f</code></p></td> </tr> <tr class="even"> <td><p>Linked Bytecode</p></td> <td><p>The hexadecimal representation of a contract’s EVM instructions which has had all <a href="#term-link-reference">Link References</a> replaced with the desired <a href="#term-link-value">Link Values</a>.</p> <p><strong>Example</strong>: <code>0x606060405260e06000736fe36000604051602001526040518160e060020a634d536f</code></p></td> </tr> </tbody> </table> <div id="term-chain-definition"></div> Chain Definition ---------------- This definition originates from [BIP122 URI](https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki). A URI in the format `blockchain://<chain_id>/block/<block_hash>` - `chain_id` is the unprefixed hexadecimal representation of the genesis hash for the chain. - `block_hash` is the unprefixed hexadecimal representation of the hash of a block on the chain. A chain is considered to match a chain definition if the genesis block hash matches the `chain_id` and the block defined by `block_hash` can be found on that chain. It is possible for multiple chains to match a single URI, in which case all chains are considered valid matches <div id="term-content-addressable-uri"></div> Content Addressable URI ----------------------- Any URI which contains a cryptographic hash which can be used to verify the integrity of the content found at the URI. The URI format is defined in RFC3986 It is **recommended** that tools support IPFS and Swarm. <div id="term-contract-alias"></div> Contract Alias -------------- This is a name used to reference a specific [Contract Type](#term-contract-type). Contract aliases **must** be unique within a single [Package](#term-package). The contract alias **must** use *one of* the following naming schemes: - `<contract-name>` - `<contract-name>[<identifier>]` The `<contract-name>` portion **must** be the same as the [Contract Name](#term-contract-name) for this contract type. The `[<identifier>]` portion **must** match the regular expression `\[[-a-zA-Z0-9]{1,256}]`. <div id="term-contract-instance"></div> Contract Instance ----------------- A contract instance a specific deployed version of a [Contract Type](#term-contract-type). All contract instances have an [Address](#term-address) on some specific chain. <div id="term-contract-instance-name"></div> Contract Instance Name ---------------------- A name which refers to a specific [Contract Instance](#term-contract-instance) on a specific chain from the deployments of a single [Package](#term-package). This name **must** be unique across all other contract instances for the given chain. The name must conform to the regular expression `[a-zA-Z][a-zA-Z0-9_]{0,255}` In cases where there is a single deployed instance of a given [Contract Type](#term-contract-type), package managers **should** use the [Contract Alias](#term-contract-alias) for that contract type for this name. In cases where there are multiple deployed instances of a given contract type, package managers **should** use a name which provides some added semantic information as to help differentiate the two deployed instances in a meaningful way. <div id="term-contract-name"></div> Contract Name ------------- The name found in the source code that defines a specific [Contract Type](#term-contract-type). These names **must** conform to the regular expression `[a-zA-Z][-a-zA-Z0-9_]{0,255}`. There can be multiple contracts with the same contract name in a projects source files. <div id="term-contract-type"></div> Contract Type ------------- Refers to a specific contract in the package source. This term can be used to refer to an abstract contract, a normal contract, or a library. Two contracts are of the same contract type if they have the same bytecode. Example: contract Wallet { ... } A deployed instance of the `Wallet` contract would be of type `Wallet`. <div id="term-identifier"></div> Identifier ---------- Refers generally to a named entity in the [Package](#term-package). A string matching the regular expression `[a-zA-Z][-_a-zA-Z0-9]{0,255}` <div id="term-link-reference"></div> Link Reference -------------- A location within a contract’s bytecode which needs to be linked. A link reference has the following properties. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p><code>offset</code></p></td> <td><p>Defines the location within the bytecode where the link reference begins.</p></td> </tr> <tr class="even"> <td><p><code>length</code></p></td> <td><p>Defines the length of the reference.</p></td> </tr> <tr class="odd"> <td><p><code>name</code></p></td> <td><p>(optional.) A string to identify the reference</p></td> </tr> </tbody> </table> <div id="term-link-value"></div> Link Value ---------- A link value is the value which can be inserted in place of a [Link Reference](#term-link-reference) <div id="term-linking"></div> Linking ------- The act of replacing [Link References](#term-link-reference) with [Link Values](#term-link-value) within some [Bytecode](#term-bytecode). <div id="term-package"></div> Package ------- Distribution of an application’s source or compiled bytecode along with metadata related to authorship, license, versioning, et al. For brevity, the term **Package** is often used metonymously to mean [Package Manifest](#term-package-manifest). <div id="term-package-manifest"></div> Package Manifest ---------------- A machine-readable description of a package (See [Specification](#package-specification) for information about the format for package manifests.) <div id="term-prefixed"></div> Prefixed -------- [Bytecode](#term-bytecode) string with leading `0x`. <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Example</p></td> <td><p><code>0xdeadbeef</code></p></td> </tr> </tbody> </table> <div id="term-unprefixed"></div> Unprefixed ---------- Not [Prefixed](#term-prefixed). <table> <colgroup> <col style="width: 50%" /> <col style="width: 50%" /> </colgroup> <tbody> <tr class="odd"> <td><p>Example</p></td> <td><p><code>deadbeef</code></p></td> </tr> </tbody> </table> Backwards Compatibility ======================= This specification supports backwards compatibility by use of the [manifest\_version](#manifest-version) property. This specification corresponds to version `2` as the value for that field. Implementations =============== This submission aims to coincide with development efforts towards widespread implementation in commonly-used development tools. The following tools are known to have begun or are nearing completion of a supporting implementation. - [Truffle](https://trufflesuite.com/) - [Populus](https://populus.readthedocs.io/en/latest/) - [Embark](https://embark.status.im/) Full support in implementation **may** require [Further Work](#further-work), specified below. Further Work ============ This EIP addresses only the data format for package descriptions. Excluded from the scope of this specification are: - Package registry interface definition - Tooling integration, or how packages are stored on disk. These efforts **should** be considered separate, warranting future dependent EIP submssions. Acknowledgements ================ The authors of this document would like to thank the original authors of [EIP-190](/EIPS/eip-190), [ETHPrize](http://ethprize.io/) for their funding support, all community [contributors](https://github.com/ethpm/ethpm-spec/graphs/contributors), and the Ethereum community at large. Copyright ========= Copyright and related rights waived via [CC0](/LICENSE). Fri, 01 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1123 https://eips.ethereum.org/EIPS/eip-1123 Standardised DAPP announcements Standards Track/ERC https://ethereum-magicians.org/t/eip-sda-standardised-dapp-announcements/508?u=thunderdeliverer ## Simple Summary Standardisation of announcements in DAPPs and services on Ethereum network. This ERC provides proposed mechanics to increase the quality of service provided by DAPP developers and service providers, by setting a framework for announcements. Be it transitioning to a new smart contract or just freezing the service for some reason. ## Abstract The proposed ERC defines format on how to post announcements about the service as well as how to remove them. It also defines mechanics on posting permissions and human friendly interface. ## Motivation Currently there are no guidelines on how to notify the users of the service status in the DAPPs. This is especially obvious in ERC20 and it's derivates. If the service is impeded by any reason it is good practice to have some sort of guidelines on how to announce that to the user. The standardisation would also provide traceability of the service's status. ## Specification ### Structures #### Announcer Stores information about the announcement maker. The `allowedToPost` stores posting permissions and is used for modifiers limiting announcement posting only to authorised entities. The `name` is used for human friendly identifier of the author to be stored. ``` js struct Announcer{ bool allowedToPost; string name; } ``` #### Announcement Stores information about the individual announcement. The human friendly author identifier is stored in `author`. Ethereum address associated with the author is stored in `authorAddress`. The announcement itself is stored in `post`. ``` js struct Announcement{ string author; address authorAddress; string post; } ``` ### Methods #### the number of announcements Returns the number of announcements currently active. OPTIONAL - this method can be used to provide quicker information for the UI, but could also be retrieved from `numberOfMessages` variable. ``` js function theNumberOfAnnouncements() public constant returns(uint256 _numberOfAnnouncements) ``` #### read posts Returns the specified announcement as well as human friendly poster identificator (name or nickname). ``` js function readPosts(uint256 _postNumber) public constant returns(string _author, string _post) ``` #### give posting permission Sets posting permissions of the address `_newAnnouncer` to `_postingPrivileges` and can also be used to revoke those permissions. The `_posterName` is human friendly author identificator used in the announcement data. ``` js function givePostingPermission(address _newAnnouncer, bool _postingPrivileges, string _posterName) public onlyOwner returns(bool success) ``` #### can post Checks if the entity that wants to post an announcement has the posting privilieges. ``` js modifier canPost{ require(posterData[msg.sender].allowedToPost); _; } ``` #### post announcement Lets user post announcements, but only if they have their posting privileges set to `true`. The announcement is sent in `_message` variable. ``` js function postAnnouncement(string _message) public canPost ``` #### remove announcement Removes an announcement with `_messageNumber` announcement identifier and rearranges the mapping so there are no empty slots. The `_removalReason` is used to update users if the issue that caused the announcement is resolved or what are the next steps from the service provider / DAPP development team. ``` js function removeAnnouncement(uint256 _messageNumber, string _removalReason) public ``` ### Events #### New announcement MUST trigger when new announcement is created. Every time there is a new announcement it should be advertised in this event. It holds the information about author `author` and the announcement istelf `message`. ``` js event NewAnnouncement(string author, string message) ``` #### Removed announcement MUST trigger when an announcement is removed. Every time an announcement is removed it should be advertised in this event. It holds the information about author `author`, the announcement itself `message`, the reason for removal or explanation of the solution `reason` and the address of the entity that removed the announcement `remover`. ``` js event RemovedAnnouncement(string author, string message, string reason, address remover); ``` ## Rationale The proposed solution was designed with UX in mind . It provides mechanics that serve to present the announcements in the user friendly way. It is meant to be deployed as a Solidity smart contract on Ethereum network. ## Test Cases The proposed version is deployed on Ropsten testnet all of the information can be found [here](https://ropsten.etherscan.io/address/0xb04f67172b9733837e59ebaf03d277279635c8e6#readContract). ## Implementation ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 31 May 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1129 https://eips.ethereum.org/EIPS/eip-1129 Extending ERC20 with token locking capability Standards Track/ERC https://github.com/ethereum/EIPs/issues/1132 ## Simple Summary An extension to the ERC20 standard with methods for time-locking of tokens within a contract. ## Abstract This proposal provides basic functionality to time-lock tokens within an ERC20 smart contract for multiple utilities without the need of transferring tokens to an external escrow smart contract. It also allows fetching balance of locked and transferable tokens. Time-locking can also be achieved via staking (#900), but that requires transfer of tokens to an escrow contract / stake manager, resulting in the following six concerns: 1. additional trust on escrow contract / stake manager 2. additional approval process for token transfer 3. increased ops costs due to gas requirements in transfers 4. tough user experience as the user needs to claim the amount back from external escrows 5. inability for the user to track their true token balance / token activity 6. inability for the user to utilize their locked tokens within the token ecosystem. ## Motivation dApps often require tokens to be time-locked against transfers for letting members 1) adhere to vesting schedules and 2) show skin in the game to comply with the underlying business process. I realized this need while building Nexus Mutual and GovBlocks. In [Nexus Mutual](https://nexusmutual.io), claim assessors are required to lock their tokens before passing a vote for claims assessment. This is important as it ensures assessors’ skin in the game. The need here was that once a claim assessor locks his tokens for ‘n’ days, he should be able to cast multiple votes during that period of ‘n’ days, which is not feasible with staking mechanism. There are other scenarios like skills/identity verification or participation in gamified token curated registries where time-locked tokens are required as well. In [GovBlocks](https://govblocks.io), I wanted to allow dApps to lock member tokens for governance, while still allowing members to use those locked tokens for other activities within the dApp business. This is also the case with DGX governance model where they’ve proposed quarterly token locking for participation in governance activities of DGX. In addition to locking functionality, I have proposed a `Lock()` and `Unlock()` event, just like the `Transfer()` event , to track token lock and unlock status. From token holder’s perspective, it gets tough to manage token holdings if certain tokens are transferred to another account for locking, because whenever `balanceOf()` queries are triggered on token holder’s account – the result does not include locked tokens. A `totalBalanceOf()` function intends to solve this problem. The intention with this proposal is to enhance the ERC20 standard with token-locking capability so that dApps can time-lock tokens of the members without having to transfer tokens to an escrow / stake manager and at the same time allow members to use the locked tokens for multiple utilities. ## Specification I’ve extended the ERC20 interface with the following enhancements: ### Locking of tokens ```solidity /** * @dev Locks a specified amount of tokens against an address, * for a specified reason and time * @param _reason The reason to lock tokens * @param _amount Number of tokens to be locked * @param _time Lock time in seconds */ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (bool) ``` ### Fetching number of tokens locked under each utility ```solidity /** * @dev Returns tokens locked for a specified address for a * specified reason * * @param _of The address whose tokens are locked * @param _reason The reason to query the lock tokens for */ tokensLocked(address _of, bytes32 _reason) view returns (uint256 amount) ``` ### Fetching number of tokens locked under each utility at a future timestamp ```solidity /** * @dev Returns tokens locked for a specified address for a * specified reason at a specific time * * @param _of The address whose tokens are locked * @param _reason The reason to query the lock tokens for * @param _time The timestamp to query the lock tokens for */ function tokensLockedAtTime(address _of, bytes32 _reason, uint256 _time) public view returns (uint256 amount) ``` ### Fetching number of tokens held by an address ```solidity /** * @dev @dev Returns total tokens held by an address (locked + transferable) * @param _of The address to query the total balance of */ function totalBalanceOf(address _of) view returns (uint256 amount) ``` ### Extending lock period ```solidity /** * @dev Extends lock for a specified reason and time * @param _reason The reason to lock tokens * @param _time Lock extension time in seconds */ function extendLock(bytes32 _reason, uint256 _time) public returns (bool) ``` ### Increasing number of tokens locked ```solidity /** * @dev Increase number of tokens locked for a specified reason * @param _reason The reason to lock tokens * @param _amount Number of tokens to be increased */ function increaseLockAmount(bytes32 _reason, uint256 _amount) public returns (bool) ``` ### Fetching number of unlockable tokens under each utility ```solidity /** * @dev Returns unlockable tokens for a specified address for a specified reason * @param _of The address to query the unlockable token count of * @param _reason The reason to query the unlockable tokens for */ function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount) ``` ### Fetching number of unlockable tokens ```solidity /** * @dev Gets the unlockable tokens of a specified address * @param _of The address to query the unlockable token count of */ function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens) ``` ### Unlocking tokens ```solidity /** * @dev Unlocks the unlockable tokens of a specified address * @param _of Address of user, claiming back unlockable tokens */ function unlock(address _of) public returns (uint256 unlockableTokens) ``` ### Lock event recorded in the token contract `event Locked(address indexed _of, uint256 indexed _reason, uint256 _amount, uint256 _validity)` ### Unlock event recorded in the token contract `event Unlocked(address indexed _of, uint256 indexed _reason, uint256 _amount)` ## Test Cases Test cases are available at [https://github.com/nitika-goel/lockable-token](https://github.com/nitika-goel/lockable-token). ## Implementation - Complete implementation available at https://github.com/nitika-goel/lockable-token - [GovBlocks](https://govblocks.io) Project specific implementation available at https://github.com/somish/govblocks-protocol/blob/Locking/contracts/GBTStandardToken.sol ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 03 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1132 https://eips.ethereum.org/EIPS/eip-1132 Transient storage opcodes Standards Track/Core https://ethereum-magicians.org/t/eip-transient-storage-opcodes/553 ## Abstract This proposal introduces transient storage opcodes, which manipulate state that behaves identically to storage, except that transient storage is discarded after every transaction, and `TSTORE` is not subject to the gas stipend check as defined in [EIP-2200](/EIPS/eip-2200). In other words, the values of transient storage are never deserialized from storage or serialized to storage. Thus transient storage is cheaper since it never requires disk access. Transient storage is accessible to smart contracts via 2 new opcodes, `TLOAD` and `TSTORE`, where “T” stands for "transient:" ``` TLOAD (0x5c) TSTORE (0x5d) ``` ## Motivation Running a transaction in Ethereum can generate multiple nested frames of execution, each created by `CALL` (or similar) instructions. Contracts can be re-entered during the same transaction, in which case there are more than one frame belonging to one contract. Currently, these frames can communicate in two ways: via inputs/outputs passed via `CALL` instructions, and via storage updates. If there is an intermediate frame belonging to another untrusted contract, communication via inputs/outputs is not secure. Notable example is a reentrancy lock which cannot rely on the intermediate frame to pass through the state of the lock. Communication via storage (`SSTORE`/`SLOAD`) is costly. Transient storage is a dedicated and gas efficient solution to the problem of inter frame communication. Storage refunds accumulated due to inter frame communication are also limited to 20% of gas spent by a transaction due to [EIP-3529](/EIPS/eip-3529) (introduced in the London hard fork). This greatly reduces the refunds for transiently-set storage slots in otherwise low-cost transactions. For example, in order to receive the full refund of one re-entrancy lock, the transaction must spend ~80k gas on other operations. Language support could be added in relatively easy way. For example, in Solidity, a qualifier `transient` can be introduced (similar to the existing qualifiers `memory` and `storage`, and Java's own `transient` keyword with a similar meaning). Since the addressing scheme of `TSTORE` and `TLOAD` is the same as for `SSTORE` and `SLOAD`, code generation routines that exist for storage variables, can be easily generalised to also support transient storage. Potential use cases enabled or improved by this EIP include: 1. Reentrancy locks 2. On-chain computable CREATE2 addresses: constructor arguments are read from the factory contract instead of passed as part of init code hash 3. Single transaction [ERC-20](/EIPS/eip-20) approvals, e.g. `#temporaryApprove(address spender, uint256 amount)` 4. Fee-on-transfer contracts: pay a fee to a token contract to unlock transfers for the duration of a transaction 5. "Till" pattern: allowing users to perform all actions as part of a callback, and checking the "till" is balanced at the end 6. Proxy call metadata: pass additional metadata to an implementation contract without using calldata, e.g. values of immutable proxy constructor arguments These opcodes are more efficient to execute than the `SSTORE` and `SLOAD` opcodes because the original value never needs to be loaded from storage (i.e. is always 0). The gas accounting rules are also simpler, since no refunds are required. ## Specification Two new opcodes are added to EVM, `TLOAD` (`0x5c`) and `TSTORE` (`0x5d`). (Note that previous drafts of this EIP specified the values `0xb3` and `0xb4` for `TLOAD` and `TSTORE` respectively to avoid conflict with other EIPs. The conflict has since been removed.) They use the same arguments on stack as `SLOAD` (`0x54`) and `SSTORE` (`0x55`). `TLOAD` pops one 32-byte word from the top of the stack, treats this value as the address, fetches 32-byte word from the transient storage at that address, and pushes the value on top of the stack. `TSTORE` pops two 32-byte words from the top of the stack. The word on the top is the address, and the next is the value. `TSTORE` saves the value at the given address in the transient storage. Addressing is the same as `SLOAD` and `SSTORE`. i.e. each 32-byte address points to a unique 32-byte word. Gas cost for `TSTORE` is the same as a warm `SSTORE` of a dirty slot (i.e. original value is not new value and is not current value, currently 100 gas), and gas cost of `TLOAD` is the same as a hot `SLOAD` (value has been read before, currently 100 gas). Gas cost cannot be on par with memory access due to transient storage's interactions with reverts. All values in transient storage are discarded at the end of the transaction. Transient storage is private to the contract that owns it, in the same way as persistent storage. Only owning contract frames may access their transient storage. And when they do, all the frames access the same transient store, in the same way as persistent storage, but unlike memory. When transient storage is used in the context of `DELEGATECALL` or `CALLCODE`, then the owning contract of the transient storage is the contract that issued `DELEGATECALL` or `CALLCODE` instruction (the caller) as with persistent storage. When transient storage is used in the context of `CALL` or `STATICCALL`, then the owning contract of the transient storage is the contract that is the target of the `CALL` or `STATICCALL` instruction (the callee). If a frame reverts, all writes to transient storage that took place between entry to the frame and the return are reverted, including those that took place in inner calls. This mimics the behavior of persistent storage. If the `TSTORE` opcode is called within the context of a `STATICCALL`, it will result in an exception instead of performing the modification. `TLOAD` is allowed within the context of a `STATICCALL`. The behavior of the opcodes for transient storage differs from the opcodes for storage in that `TSTORE` does not require _gasleft_, as defined in [EIP-2200](/EIPS/eip-2200), to be less than or equal to the gas stipend (currently 2,300). ## Rationale Another option to solve the problem of inter-frame communication is repricing the `SSTORE` and `SLOAD` opcodes to be cheaper for the transient storage use case. This has already been done as of [EIP-2200](/EIPS/eip-2200). However, [EIP-3529](/EIPS/eip-3529) reduced the maximum refund to only 20% of the transaction gas cost, which means the use of transient storage is severely limited. Another approach is to keep the refund counter for transient storage separate from the refund counter for other storage uses, and remove the refund cap for transient storage. However, that approach is more complex to implement and understand. For example, the 20% refund cap must be applied to the gas used _after_ subtracting the uncapped gas refund. Otherwise, the refund amount available subject to the 20% refund cap could be increased by executing transient storage writes. Thus it is preferable to have a separate mechanism that does not interact with the refund counter. Future hard forks can remove the complex refund behavior meant to support the transient storage use case, encouraging migration to contracts that are more efficient for the Ethereum clients to execute. There is a known objection to the word-addressed storage-like interface of the `TSTORE` and `TLOAD` opcodes since transient storage is more akin to memory than storage in lifecycle. A byte-addressed memory-like interface is another option. The storage-like word-addressed interface is preferred due to the usefulness of mappings in combination with the transaction-scoped memory region. Often times, you will need to keep transient state with arbitrary keys, such as in the [ERC-20](/EIPS/eip-20) temporary approval use case which uses a mapping of `(owner, spender)` to `allowance`. Mappings are difficult to implement using linear memory, and linear memory must also have dynamic gas costs. It is also more complicated to handle reverts with a linear memory. It is possible to have a memory-like interface while the underlying implementation uses a map to allow for storage in arbitrary offsets, but this would result in a third memory-storage hybrid interface that would require new code paths in compilers. Some think that a unique transaction identifier may obviate the need for transient storage as described in this EIP. This is a misconception: a transaction identifier used in combination with regular storage has all the same issues that motivate this EIP. The two features are orthogonal. Relative cons of this transient storage EIP: - Does not address transient usages of storage in existing contracts - New code in the clients - New concept for the yellow paper (more to update) Relative pros of this transient storage EIP: - Transient storage opcodes are considered separately in protocol upgrades and not inadvertently broken (e.g. [EIP-3529](/EIPS/eip-3529)) - Clients do not need to load the original value - No upfront gas cost to account for non-transient writes - Does not change the semantics of the existing operations - No need to clear storage slots after usage - Simpler gas accounting rules - Future storage designs (e.g. Verkle tree) do not need to account for transient storage refunds ## Backwards Compatibility This EIP requires a hard fork to implement. Since this EIP does not change behavior of any existing opcodes, it is backwards compatible with all existing smart contracts. ## Test Cases A test suite for this EIP can be found [here](https://github.com/ethereum/execution-spec-tests/tree/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip1153_tstore). ## Reference Implementation Because the transient storage must behave almost identically to storage within the context of a single transaction with regards to revert behavior, it is necessary to be able to revert to a previous state of transient storage within a transaction. At the same time reverts are exceptional cases and loads, stores and returns should be cheap. A map of current state plus a journal of all changes and a list of checkpoints is recommended. This has the following time complexities: - On entry to a call frame, a call marker is added to the list - `O(1)` - New values are written to the current state, and the previous value is written to the journal - `O(1)` - When a call exits successfully, the marker to the journal index of when that call was entered is discarded - `O(1)` - On revert all entries are reverted up to the last checkpoint, in reverse - `O(N)` where `N` = number of journal entries since last checkpoint ```typescript interface JournalEntry { addr: string key: string prevValue: string } type Journal = JournalEntry[] type Checkpoints = Journal['length'][] interface Current { [addr: string]: { [key: string]: string } } const EMPTY_VALUE = '0x0000000000000000000000000000000000000000000000000000000000000000' class TransientStorage { /** * The current state of transient storage. */ private current: Current = {} /** * All changes are written to the journal. On revert, we apply the changes in reverse to the last checkpoint. */ private journal: Journal = [] /** * The length of the journal at the time of each checkpoint */ private checkpoints: Checkpoints = [0] /** * Returns the current value of the given contract address and key * @param addr The address of the contract * @param key The key of transient storage for the address */ public get(addr: string, key: string): string { return this.current[addr]?.[key] ?? EMPTY_VALUE } /** * Set the current value in the map * @param addr the address of the contract for which the key is being set * @param key the slot to set for the address * @param value the new value of the slot to set */ public put(addr: string, key: string, value: string) { this.journal.push({ addr, key, prevValue: this.get(addr, key), }) this.current[addr] = this.current[addr] ?? {} this.current[addr][key] = value; } /** * Commit all the changes since the last checkpoint */ public commit(): void { if (this.checkpoints.length === 0) throw new Error('Nothing to commit') this.checkpoints.pop() // The last checkpoint is discarded. } /** * To be called whenever entering a new context. If revert is called after checkpoint, all changes made after the latest checkpoint are reverted. */ public checkpoint(): void { this.checkpoints.push(this.journal.length) } /** * Revert transient storage to the state from the last call to checkpoint */ public revert() { const lastCheckpoint = this.checkpoints.pop() if (typeof lastCheckpoint === 'undefined') throw new Error('Nothing to revert') for (let i = this.journal.length - 1; i >= lastCheckpoint; i--) { const {addr, key, prevValue} = this.journal[i] // we can assume it exists, since it was written in the journal this.current[addr][key] = prevValue } this.journal.splice(lastCheckpoint, this.journal.length - lastCheckpoint) } } ``` The worst case time complexity can be produced by writing the maximum number of keys that can fit in one block, and then reverting. In this case, the client is required to do twice as many writes to apply all the entries in the journal. However, the same case applies to the state journaling implementation of existing clients, and cannot be DOS'd with the following code. ```solidity pragma solidity =0.8.13; contract TryDOS { uint256 slot; constructor() { slot = 1; } function tryDOS() external { uint256 i = 1; while (gasleft() > 5000) { unchecked { slot = i++; } } revert(); } } ``` ## Security Considerations `TSTORE` presents a new way to allocate memory on a node with linear cost. In other words, each TSTORE allows the developer to store 32 bytes for 100 gas, excluding any other required operations to prepare the stack. Given 30 million gas, the maximum amount of memory that can be allocated using TSTORE is: ``` 30M gas * 1 TSTORE / 100 gas * 32 bytes / 1 TSTORE * 1MB / 2^20 bytes ~= 9.15MB ``` Given the same amount of gas, the maximum amount of memory that can be allocated in a single context by `MSTORE` is ~3.75MB: ``` 30M gas = 3x + x^2 / 512 => x = ~123,169 32-byte words ~123,169 words * 32 bytes/word * 1MB / 2^20 bytes = 3.75MB ``` However, if you only spend 1M gas allocating memory in each context, and make calls to reset the memory expansion cost, you can allocate ~700KB per million gas, for a total of ~20MB of memory allocated: ``` 1M gas = 3x + x^2 / 512 => x = ~21,872 32-byte words 30M gas * ~21,872 words / 1M gas * 32 bytes/word * 1MB / 2^20 bytes = ~20MB ``` Smart contract developers should understand the lifetime of transient storage variables before use. Because transient storage is automatically cleared at the end of the transaction, smart contract developers may be tempted to avoid clearing slots as part of a call in order to save gas. However, this could prevent further interactions with the contract in the same transaction (e.g. in the case of re-entrancy locks) or cause other bugs, so smart contract developers should be careful to _only_ leave transient storage slots with nonzero values when those slots are intended to be used by future calls within the same transaction. Otherwise, these opcodes behave exactly the same as `SSTORE` and `SLOAD`, so all the usual security considerations apply especially in regard to reentrancy risk. Smart contract developers may also be tempted to use transient storage as an alternative to in-memory mappings. They should be aware that transient storage is not discarded when a call returns or reverts, as is memory, and should prefer memory for these use cases so as not to create unexpected behavior on reentrancy in the same transaction. The necessarily high cost of transient storage over memory should already discourage this usage pattern. Most usages of in-memory mappings can be better implemented with key-sorted lists of entries, and in-memory mappings are rarely required in smart contracts (i.e. the author knows of no known use cases in production). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 15 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1153 https://eips.ethereum.org/EIPS/eip-1153 Oracle Interface Standards Track/ERC https://github.com/ethereum/EIPs/issues/1161 ## Simple Summary A standard interface for oracles. ## Abstract In order for ethereum smart contracts to interact with off-chain systems, oracles must be used. These oracles report values which are normally off-chain, allowing smart contracts to react to the state of off-chain systems. A distinction and a choice is made between push and pull based oracle systems. Furthermore, a standard interface for oracles is described here, allowing different oracle implementations to be interchangeable. ## Motivation The Ethereum ecosystem currently has many different oracle implementations available, but they do not provide a unified interface. Smart contract systems would be locked into a single set of oracle implementations, or they would require developers to write adapters/ports specific to the oracle system chosen in a given project. Beyond naming differences, there is also the issue of whether or not an oracle report-resolving transaction _pushes_ state changes by calling affected contracts, or changes the oracle state allowing dependent contracts to _pull_ the updated value from the oracle. These differing system semantics could introduce inefficiencies when adapting between them. Ultimately, the value in different oracle systems comes from their underlying resolution mechanics, and points where these systems are virtually identical should be standardized. These oracles may be used for answering questions about "real-world events", where each ID can be correlated with a specification of a question and its answers (so most likely for prediction markets, basically). Another use case could be for decision-making processes, where the results given by the oracle represent decisions made by the oracle (e.g. futarchies). DAOs may require their use in decision making processes. Both the ID and the results are intentionally unstructured so that things like time series data (via splitting the ID) and different sorts of results (like one of a few, any subset of up to 256, or some value in a range with up to 256 bits of granularity) can be represented. ## Specification <dl> <dt>Oracle</dt> <dd>An entity which reports data to the blockchain.</dd> <dt>Oracle consumer</dt> <dd>A smart contract which receives data from an oracle.</dd> <dt>ID</dt> <dd>A way of indexing the data which an oracle reports. May be derived from or tied to a question for which the data provides the answer.</dd> <dt>Result</dt> <dd>Data associated with an id which is reported by an oracle. This data oftentimes will be the answer to a question tied to the id. Other equivalent terms that have been used include: answer, data, outcome.</dd> <dt>Report</dt> <dd>A pair (ID, result) which an oracle sends to an oracle consumer.</dd> </dl> ```solidity interface OracleConsumer { function receiveResult(bytes32 id, bytes result) external; } ``` `receiveResult` MUST revert if the `msg.sender` is not an oracle authorized to provide the `result` for that `id`. `receiveResult` MUST revert if `receiveResult` has been called with the same `id` before. `receiveResult` MAY revert if the `id` or `result` cannot be handled by the consumer. Consumers MUST coordinate with oracles to determine how to encode/decode results to and from `bytes`. For example, `abi.encode` and `abi.decode` may be used to implement a codec for results in Solidity. `receiveResult` SHOULD revert if the consumer receives a unexpected result format from the oracle. The oracle can be any Ethereum account. ## Rationale The specs are currently very similar to what is implemented by ChainLink (which can use any arbitrarily-named callback) and Oraclize (which uses `__callback`). With this spec, the oracle _pushes_ state to the consumer, which must react accordingly to the updated state. An alternate _pull_-based interface can be prescribed, as follows: ### Alternate Pull-based Interface Here are alternate specs loosely based on Gnosis prediction market contracts v1. Reality Check also exposes a similar endpoint (`getFinalAnswer`). ```solidity interface Oracle { function resultFor(bytes32 id) external view returns (bytes result); } ``` `resultFor` MUST revert if the result for an `id` is not available yet. `resultFor` MUST return the same result for an `id` after that result is available. ### Push vs Pull Note that push-based interfaces may be adapted into pull-based interfaces. Simply deploy an oracle consumer which stores the result received and implements `resultFor` accordingly. Similarly, every pull-based system can be adapted into a push-based system: just add a method on the oracle smart contract which takes an oracle consumer address and calls `receiveResult` on that address. In both cases, an additional transaction would have to be performed, so the choice to go with push or pull should be based on the dominant use case for these oracles. In the simple case where a single account has the authority to decide the outcome of an oracle question, there is no need to deploy an oracle contract and store the outcome on that oracle contract. Similarly, in the case where the outcome comes down to a vote, existing multisignature wallets can be used as the authorized oracle. #### Multiple Oracle Consumers In the case that many oracle consumers depend on a single oracle result and all these consumers expect the result to be pushed to them, the push and pull adaptations mentioned before may be combined if the pushing oracle cannot be trusted to send the same result to every consumer (in a sense, this forwards the trust to the oracle adaptor implementation). In a pull-based system, each of the consumers would have to be called to pull the result from the oracle contract, but in the proposed push-based system, the adapted oracle would have to be called to push the results to each of the consumers. Transaction-wise, both systems are roughly equivalent in efficiency in this scenario, but in the push-based system, there's a need for the oracle consumers to store the results again, whereas in the pull-based system, the consumers may continue to refer to the oracle for the results. Although this may be somewhat less efficient, requiring the consumers to store the results can also provide security guarantees, especially with regards to result immutability. #### Result Immutability In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical consumers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the consumer enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the consumer would also have to handle result immutability. For data which mutates over time, the `id` field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millennia). ## Implementation * [Tidbit](https://github.com/levelkdev/tidbit) tracks this EIP. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 13 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1154 https://eips.ethereum.org/EIPS/eip-1154 Multi Token Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1155 ## Simple Summary A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g. semi-fungible tokens). ## Abstract This standard outlines a smart contract interface that can represent any number of fungible and non-fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes. The `_id` argument contained in each function's argument set indicates a specific token or token type in a transaction. ## Motivation Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, ERC-1155 is not specific to games and many other applications can benefit from this flexibility. New functionality is possible with this design such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to "approve" individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. **Smart contracts implementing the ERC-1155 standard MUST implement all of the functions in the `ERC1155` interface.** **Smart contracts implementing the ERC-1155 standard MUST implement the ERC-165 `supportsInterface` function and MUST return the constant value `true` if `0xd9b67a26` is passed through the `interfaceID` argument.** ```solidity pragma solidity ^0.5.9; /** @title ERC-1155 Multi Token Standard @dev See https://eips.ethereum.org/EIPS/eip-1155 Note: The ERC-165 identifier for this interface is 0xd9b67a26. */ interface ERC1155 /* is ERC165 */ { /** @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard). The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). The `_from` argument MUST be the address of the holder whose balance is decreased. The `_to` argument MUST be the address of the recipient whose balance is increased. The `_id` argument MUST be the token type being transferred. The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). */ event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value); /** @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard). The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). The `_from` argument MUST be the address of the holder whose balance is decreased. The `_to` argument MUST be the address of the recipient whose balance is increased. The `_ids` argument MUST be the list of tokens being transferred. The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in _ids) the holder balance is decreased by and match what the recipient balance is increased by. When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). */ event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values); /** @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absence of an event assumes disabled). */ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); /** @dev MUST emit when the URI is updated for a token ID. URIs are defined in RFC 3986. The URI MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema". */ event URI(string _value, uint256 indexed _id); /** @notice Transfers `_value` amount of an `_id` from the `_from` address to the `_to` address specified (with safety call). @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see "Approval" section of the standard). MUST revert if `_to` is the zero address. MUST revert if balance of holder for token `_id` is lower than the `_value` sent. MUST revert on any other error. MUST emit the `TransferSingle` event to reflect the balance change (see "Safe Transfer Rules" section of the standard). After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). @param _from Source address @param _to Target address @param _id ID of the token type @param _value Transfer amount @param _data Additional data with no specified format, MUST be sent unaltered in call to `onERC1155Received` on `_to` */ function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external; /** @notice Transfers `_values` amount(s) of `_ids` from the `_from` address to the `_to` address specified (with safety call). @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see "Approval" section of the standard). MUST revert if `_to` is the zero address. MUST revert if length of `_ids` is not the same as length of `_values`. MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient. MUST revert on any other error. MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "Safe Transfer Rules" section of the standard). Balance changes and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc). After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). @param _from Source address @param _to Target address @param _ids IDs of each token type (order and length must match _values array) @param _values Transfer amounts per token type (order and length must match _ids array) @param _data Additional data with no specified format, MUST be sent unaltered in call to the `ERC1155TokenReceiver` hook(s) on `_to` */ function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external; /** @notice Get the balance of an account's tokens. @param _owner The address of the token holder @param _id ID of the token @return The _owner's balance of the token type requested */ function balanceOf(address _owner, uint256 _id) external view returns (uint256); /** @notice Get the balance of multiple account/token pairs @param _owners The addresses of the token holders @param _ids ID of the tokens @return The _owner's balance of the token types requested (i.e. balance for each (owner, id) pair) */ function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory); /** @notice Enable or disable approval for a third party ("operator") to manage all of the caller's tokens. @dev MUST emit the ApprovalForAll event on success. @param _operator Address to add to the set of authorized operators @param _approved True if the operator is approved, false to revoke approval */ function setApprovalForAll(address _operator, bool _approved) external; /** @notice Queries the approval status of an operator for a given owner. @param _owner The owner of the tokens @param _operator Address of authorized operator @return True if the operator is approved, false if not */ function isApprovedForAll(address _owner, address _operator) external view returns (bool); } ``` ### ERC-1155 Token Receiver **Smart contracts MUST implement all of the functions in the `ERC1155TokenReceiver` interface to accept transfers. See "Safe Transfer Rules" for further detail.** **Smart contracts MUST implement the ERC-165 `supportsInterface` function and signify support for the `ERC1155TokenReceiver` interface to accept transfers. See "ERC1155TokenReceiver ERC-165 rules" for further detail.** ```solidity pragma solidity ^0.5.9; /** Note: The ERC-165 identifier for this interface is 0x4e2312e0. */ interface ERC1155TokenReceiver { /** @notice Handle the receipt of a single ERC1155 token type. @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeTransferFrom` after the balance has been updated. This function MUST return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61) if it accepts the transfer. This function MUST revert if it rejects the transfer. Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller. @param _operator The address which initiated the transfer (i.e. msg.sender) @param _from The address which previously owned the token @param _id The ID of the token being transferred @param _value The amount of tokens being transferred @param _data Additional data with no specified format @return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` */ function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4); /** @notice Handle the receipt of multiple ERC1155 token types. @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeBatchTransferFrom` after the balances have been updated. This function MUST return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81) if it accepts the transfer(s). This function MUST revert if it rejects the transfer(s). Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller. @param _operator The address which initiated the batch transfer (i.e. msg.sender) @param _from The address which previously owned the token @param _ids An array containing ids of each token being transferred (order and length must match _values array) @param _values An array containing amounts of each token being transferred (order and length must match _ids array) @param _data Additional data with no specified format @return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` */ function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4); } ``` ### Safe Transfer Rules To be more explicit about how the standard `safeTransferFrom` and `safeBatchTransferFrom` functions MUST operate with respect to the `ERC1155TokenReceiver` hook functions, a list of scenarios and rules follows. #### Scenarios **_Scenario#1 :_** The recipient is not a contract. * `onERC1155Received` and `onERC1155BatchReceived` MUST NOT be called on an EOA (Externally Owned Account). **_Scenario#2 :_** The transaction is not a mint/transfer of a token. * `onERC1155Received` and `onERC1155BatchReceived` MUST NOT be called outside of a mint or transfer process. **_Scenario#3 :_** The receiver does not implement the necessary `ERC1155TokenReceiver` interface function(s). * The transfer MUST be reverted with the one caveat below. - If the token(s) being sent are part of a hybrid implementation of another standard, that particular standard's rules on sending to a contract MAY now be followed instead. See "Backwards Compatibility" section. **_Scenario#4 :_** The receiver implements the necessary `ERC1155TokenReceiver` interface function(s) but returns an unknown value. * The transfer MUST be reverted. **_Scenario#5 :_** The receiver implements the necessary `ERC1155TokenReceiver` interface function(s) but throws an error. * The transfer MUST be reverted. **_Scenario#6 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of one and only one balance change (e.g. `safeTransferFrom` called). * The balances for the transfer MUST have been updated before the `ERC1155TokenReceiver` hook is called on a recipient contract. * The transfer event MUST have been emitted to reflect the balance changes before the `ERC1155TokenReceiver` hook is called on the recipient contract. * One of `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient contract. * The `onERC1155Received` hook SHOULD be called on the recipient contract and its rules followed. - See "onERC1155Received rules" for further rules that MUST be followed. * The `onERC1155BatchReceived` hook MAY be called on the recipient contract and its rules followed. - See "onERC1155BatchReceived rules" for further rules that MUST be followed. **_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (e.g. `safeBatchTransferFrom` called). * All balance transfers that are referenced in a call to an `ERC1155TokenReceiver` hook MUST be updated before the `ERC1155TokenReceiver` hook is called on the recipient contract. * All transfer events MUST have been emitted to reflect current balance changes before an `ERC1155TokenReceiver` hook is called on the recipient contract. * `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for. - The return magic value for every hook call MUST be checked and acted upon as per "onERC1155Received rules" and "onERC1155BatchReceived rules". * The `onERC1155BatchReceived` hook SHOULD be called on the recipient contract and its rules followed. - See "onERC1155BatchReceived rules" for further rules that MUST be followed. * The `onERC1155Received` hook MAY be called on the recipient contract and its rules followed. - See "onERC1155Received rules" for further rules that MUST be followed. **_Scenario#8 :_** You are the creator of a contract that implements the `ERC1155TokenReceiver` interface and you forward the token(s) onto another address in one or both of `onERC1155Received` and `onERC1155BatchReceived`. * Forwarding should be considered acceptance and then initiating a new `safeTransferFrom` or `safeBatchTransferFrom` in a new context. - The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful. * The `_data` argument MAY be re-purposed for the new context. * If forwarding fails the transaction MAY be reverted. - If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so. **_Scenario#9 :_** You are transferring tokens via a non-standard API call i.e. an implementation specific API and NOT `safeTransferFrom` or `safeBatchTransferFrom`. * In this scenario all balance updates and events output rules are the same as if a standard transfer function had been called. - i.e. an external viewer MUST still be able to query the balance via a standard function and it MUST be identical to the balance as determined by `TransferSingle` and `TransferBatch` events alone. * If the receiver is a contract the `ERC1155TokenReceiver` hooks still need to be called on it and the return values respected the same as if a standard transfer function had been called. - However while the `safeTransferFrom` or `safeBatchTransferFrom` functions MUST revert if a receiving contract does not implement the `ERC1155TokenReceiver` interface, a non-standard function MAY proceed with the transfer. - See "Implementation specific transfer API rules". #### Rules **_safeTransferFrom rules:_** * Caller must be approved to manage the tokens being transferred out of the `_from` account (see "Approval" section). * MUST revert if `_to` is the zero address. * MUST revert if balance of holder for token `_id` is lower than the `_value` sent to the recipient. * MUST revert on any other error. * MUST emit the `TransferSingle` event to reflect the balance change (see "TransferSingle and TransferBatch event rules" section). * After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "onERC1155Received rules" section). - The `_data` argument provided by the sender for the transfer MUST be passed with its contents unaltered to the `onERC1155Received` hook function via its `_data` argument. **_safeBatchTransferFrom rules:_** * Caller must be approved to manage all the tokens being transferred out of the `_from` account (see "Approval" section). * MUST revert if `_to` is the zero address. * MUST revert if length of `_ids` is not the same as length of `_values`. * MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient. * MUST revert on any other error. * MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "TransferSingle and TransferBatch event rules" section). * The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc). * After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "onERC1155Received and onERC1155BatchReceived rules" section). - The `_data` argument provided by the sender for the transfer MUST be passed with its contents unaltered to the `ERC1155TokenReceiver` hook function(s) via their `_data` argument. **_TransferSingle and TransferBatch event rules:_** * `TransferSingle` SHOULD be used to indicate a single balance transfer has occurred between a `_from` and `_to` pair. - It MAY be emitted multiple times to indicate multiple balance changes in the transaction, but note that `TransferBatch` is designed for this to reduce gas consumption. - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). - The `_from` argument MUST be the address of the holder whose balance is decreased. - The `_to` argument MUST be the address of the recipient whose balance is increased. - The `_id` argument MUST be the token type being transferred. - The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. - When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". * `TransferBatch` SHOULD be used to indicate multiple balance transfers have occurred between a `_from` and `_to` pair. - It MAY be emitted with a single element in the list to indicate a singular balance change in the transaction, but note that `TransferSingle` is designed for this to reduce gas consumption. - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). - The `_from` argument MUST be the address of the holder whose balance is decreased for each entry pair in `_ids` and `_values`. - The `_to` argument MUST be the address of the recipient whose balance is increased for each entry pair in `_ids` and `_values`. - The `_ids` array argument MUST contain the ids of the tokens being transferred. - The `_values` array argument MUST contain the number of token to be transferred for each corresponding entry in `_ids`. - `_ids` and `_values` MUST have the same length. - When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". * The total value transferred from address `0x0` minus the total value transferred to `0x0` observed via the `TransferSingle` and `TransferBatch` events MAY be used by clients and exchanges to determine the "circulating supply" for a given token ID. * To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the `TransferSingle` event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0. * All `TransferSingle` and `TransferBatch` events MUST be emitted to reflect all the balance changes that have occurred before any call(s) to `onERC1155Received` or `onERC1155BatchReceived`. - To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract. **_onERC1155Received rules:_** - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). * The `_from` argument MUST be the address of the holder whose balance is decreased. - `_from` MUST be 0x0 for a mint. * The `_id` argument MUST be the token type being transferred. * The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. * The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered. - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` - If the return value is `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. - If the recipient contract throws/reverts the transaction MUST be reverted. * If the return value is anything other than `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` the transaction MUST be reverted. * `onERC1155Received` (and/or `onERC1155BatchReceived`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. * A contract MAY skip calling the `onERC1155Received` hook function if the transfer operation is transferring the token to itself. **_onERC1155BatchReceived rules:_** - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). * The `_from` argument MUST be the address of the holder whose balance is decreased. - `_from` MUST be 0x0 for a mint. * The `_ids` argument MUST be the list of tokens being transferred. * The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in `_ids`) the holder balance is decreased by and match what the recipient balance is increased by. * The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered. - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` - If the return value is `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. - If the recipient contract throws/reverts the transaction MUST be reverted. * If the return value is anything other than `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transaction MUST be reverted. * `onERC1155BatchReceived` (and/or `onERC1155Received`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. * A contract MAY skip calling the `onERC1155BatchReceived` hook function if the transfer operation is transferring the token(s) to itself. **_ERC1155TokenReceiver ERC-165 rules:_** * The implementation of the ERC-165 `supportsInterface` function SHOULD be as follows: ```solidity function supportsInterface(bytes4 interfaceID) external view returns (bool) { return interfaceID == 0x01ffc9a7 || // ERC-165 support (i.e. `bytes4(keccak256('supportsInterface(bytes4)'))`). interfaceID == 0x4e2312e0; // ERC-1155 `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). } ``` * The implementation MAY differ from the above but: - It MUST return the constant value `true` if `0x01ffc9a7` is passed through the `interfaceID` argument. This signifies ERC-165 support. - It MUST return the constant value `true` if `0x4e2312e0` is passed through the `interfaceID` argument. This signifies ERC-1155 `ERC1155TokenReceiver` support. - It MUST NOT consume more than 10,000 gas. - This keeps it below the ERC-165 requirement of 30,000 gas, reduces the gas reserve needs and minimises possible side-effects of gas exhaustion during the call. **_Implementation specific transfer API rules:_** * If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the `safeTransferFrom` or `safeBatchTransferFrom` (as appropriate) rules MUST still be followed if the receiver implements the `ERC1155TokenReceiver` interface. If it does not the non-standard implementation SHOULD revert but MAY proceed. * An example: 1. An approved user calls a function such as `function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);`. 2. `myTransferFrom` updates the balances for `_from` and `_to` addresses for all `_ids` and `_values`. 3. `myTransferFrom` emits `TransferBatch` with the details of what was transferred from address `_from` to address `_to`. 4. `myTransferFrom` checks if `_to` is a contract address and determines that it is so (if not, then the transfer can be considered successful). 5. `myTransferFrom` calls `onERC1155BatchReceived` on `_to` and it reverts or returns an unknown value (if it had returned `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer can be considered successful). 6. At this point `myTransferFrom` SHOULD revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the `onERC1155BatchReceived` function. 7. If however `myTransferFrom` wishes to continue it MUST call `supportsInterface(0x4e2312e0)` on `_to` and if it returns the constant value `true` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. - NOTE: You could have called `supportsInterface(0x4e2312e0)` at a previous step if you wanted to gather and act upon that information earlier, such as in a hybrid standards scenario. 8. If the above call to `supportsInterface(0x4e2312e0)` on `_to` reverts or returns a value other than the constant value `true` the `myTransferFrom` function MAY consider this transfer successful. - __NOTE__: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens. * The above example is not exhaustive but illustrates the major points (and shows that most are shared with `safeTransferFrom` and `safeBatchTransferFrom`): - Balances that are updated MUST have equivalent transfer events emitted. - A receiver address has to be checked if it is a contract and if so relevant `ERC1155TokenReceiver` hook function(s) have to be called on it. - Balances (and events associated) that are referenced in a call to an `ERC1155TokenReceiver` hook MUST be updated (and emitted) before the `ERC1155TokenReceiver` hook is called. - The return values of the `ERC1155TokenReceiver` hook functions that are called MUST be respected if they are implemented. - Only non-standard transfer functions MAY allow tokens to be sent to a recipient contract that does NOT implement the necessary `ERC1155TokenReceiver` hook functions. `safeTransferFrom` and `safeBatchTransferFrom` MUST revert in that case (unless it is a hybrid standards implementation see "Backwards Compatibility"). **_Minting/creating and burning/destroying rules:_** * A mint/create operation is essentially a specialized transfer and MUST follow these rules: - To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the `TransferSingle` event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0. - The "TransferSingle and TransferBatch event rules" MUST be followed as appropriate for the mint(s) (i.e. singles or batches) however the `_from` argument MUST be set to `0x0` (i.e. zero address) to flag the transfer as a mint to contract observers. - __NOTE:__ This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too. * A burn/destroy operation is essentially a specialized transfer and MUST follow these rules: - The "TransferSingle and TransferBatch event rules" MUST be followed as appropriate for the burn(s) (i.e. singles or batches) however the `_to` argument MUST be set to `0x0` (i.e. zero address) to flag the transfer as a burn to contract observers. - When burning/destroying you do not have to actually transfer to `0x0` (that is impl specific), only the `_to` argument in the event MUST be set to `0x0` as above. * The total value transferred from address `0x0` minus the total value transferred to `0x0` observed via the `TransferSingle` and `TransferBatch` events MAY be used by clients and exchanges to determine the "circulating supply" for a given token ID. * As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with custom transfer functions rather than `safeTransferFrom` or `safeBatchTransferFrom`. If so the "Implementation specific transfer API rules" section would be appropriate. - Even in a non-safe API and/or hybrid standards case the above event rules MUST still be adhered to when minting/creating or burning/destroying. * A contract MAY skip calling the `ERC1155TokenReceiver` hook function(s) if the mint operation is transferring the token(s) to itself. In all other cases the `ERC1155TokenReceiver` rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid). ##### A solidity example of the keccak256 generated constants for the various magic values (these MAY be used by implementation): ```solidity bytes4 constant public ERC1155_ERC165 = 0xd9b67a26; // ERC-165 identifier for the main token standard. bytes4 constant public ERC1155_ERC165_TOKENRECEIVER = 0x4e2312e0; // ERC-165 identifier for the `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). bytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // Return value from `onERC1155Received` call if a contract accepts receipt (i.e `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`). bytes4 constant public ERC1155_BATCH_ACCEPTED = 0xbc197c81; // Return value from `onERC1155BatchReceived` call if a contract accepts receipt (i.e `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). ``` ### Metadata The URI value allows for ID substitution by clients. If the string `{id}` exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for a large number of tokens to use the same on-chain string by defining a URI once, for that large number of tokens. * The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix. * The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary. Example of such a URI: `https://token-cdn-domain/{id}.json` would be replaced with `https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json` if the client is referring to token ID 314592/0x4CCE0. #### Metadata Extensions The optional `ERC1155Metadata_URI` extension can be identified with the [ERC-165 Standard Interface Detection](/EIPS/eip-165). If the optional `ERC1155Metadata_URI` extension is included: * The ERC-165 `supportsInterface` function MUST return the constant value `true` if `0x0e89341c` is passed through the `interfaceID` argument. * _Changes_ to the URI MUST emit the `URI` event if the change can be expressed with an event (i.e. it isn't dynamic/programmatic). - An implementation MAY emit the `URI` event during a mint operation but it is NOT mandatory. An observer MAY fetch the metadata uri at mint time from the `uri` function if it was not emitted. * The `uri` function SHOULD be used to retrieve values if no event was emitted. * The `uri` function MUST return the same value as the latest event for an `_id` if it was emitted. * The `uri` function MUST NOT be used to check for the existence of a token as it is possible for an implementation to return a valid string even if the token does not exist. ```solidity pragma solidity ^0.5.9; /** Note: The ERC-165 identifier for this interface is 0x0e89341c. */ interface ERC1155Metadata_URI { /** @notice A distinct Uniform Resource Identifier (URI) for a given token. @dev URIs are defined in RFC 3986. The URI MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema". @return URI string */ function uri(uint256 _id) external view returns (string memory); } ``` #### ERC-1155 Metadata URI JSON Schema This JSON schema is loosely based on the "ERC721 Metadata JSON Schema", but includes optional formatting to allow for ID substitution by clients. If the string `{id}` exists in any JSON value, it MUST be replaced with the actual token ID, by all client software that follows this standard. * The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix. * The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary. ```json { "title": "Token Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this token represents" }, "decimals": { "type": "integer", "description": "The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation." }, "description": { "type": "string", "description": "Describes the asset to which this token represents" }, "image": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." }, "properties": { "type": "object", "description": "Arbitrary properties. Values may be strings, numbers, object or arrays." } } } ``` An example of an ERC-1155 Metadata JSON file follows. The properties array proposes some SUGGESTED formatting for token-specific display properties and metadata. ```json { "name": "Asset Name", "description": "Lorem ipsum...", "image": "https:\/\/s3.amazonaws.com\/your-bucket\/images\/{id}.png", "properties": { "simple_property": "example value", "rich_property": { "name": "Name", "value": "123", "display_value": "123 Example Value", "class": "emphasis", "css": { "color": "#ffffff", "font-weight": "bold", "text-decoration": "underline" } }, "array_property": { "name": "Name", "value": [1,2,3,4], "class": "emphasis" } } } ``` ##### Localization Metadata localization should be standardized to increase presentation uniformity across all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a `localization` attribute, its content MAY be used to provide localized values for fields that need it. The `localization` attribute should be a sub-object with three attributes: `uri`, `default` and `locales`. If the string `{locale}` exists in any URI, it MUST be replaced with the chosen locale by all client software. ##### JSON Schema ```json { "title": "Token Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this token represents", }, "decimals": { "type": "integer", "description": "The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation." }, "description": { "type": "string", "description": "Describes the asset to which this token represents" }, "image": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." }, "properties": { "type": "object", "description": "Arbitrary properties. Values may be strings, numbers, object or arrays.", }, "localization": { "type": "object", "required": ["uri", "default", "locales"], "properties": { "uri": { "type": "string", "description": "The URI pattern to fetch localized data from. This URI should contain the substring `{locale}` which will be replaced with the appropriate locale value before sending the request." }, "default": { "type": "string", "description": "The locale of the default data within the base JSON" }, "locales": { "type": "array", "description": "The list of locales for which data is available. These locales should conform to those defined in the Unicode Common Locale Data Repository (http://cldr.unicode.org/)." } } } } } ``` ##### Localized Sample Base URI: ```json { "name": "Advertising Space", "description": "Each token represents a unique Ad space in the city.", "localization": { "uri": "ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT/{locale}.json", "default": "en", "locales": ["en", "es", "fr"] } } ``` es.json: ```json { "name": "Espacio Publicitario", "description": "Cada token representa un espacio publicitario único en la ciudad." } ``` fr.json: ```json { "name": "Espace Publicitaire", "description": "Chaque jeton représente un espace publicitaire unique dans la ville." } ``` ### Approval The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface](/EIPS/eip-1761) is suggested. The counterpart `isApprovedForAll` provides introspection into any status set by `setApprovalForAll`. An owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call `setApprovalForAll` to approve themselves as an operator before they can operate on them. ## Rationale ### Metadata Choices The `symbol` function (found in the ERC-20 and ERC-721 standards) was not included as we do not believe this is a globally useful piece of data to identify a generic virtual item / asset and are also prone to collisions. Short-hand symbols are used in tickers and currency trading, but they aren't as useful outside of that space. The `name` function (for human-readable asset names, on-chain) was removed from the standard to allow the Metadata JSON to be the definitive asset name and reduce duplication of data. This also allows localization for names, which would otherwise be prohibitively expensive if each language string was stored on-chain, not to mention bloating the standard interface. While this decision may add a small burden on implementers to host a JSON file containing metadata, we believe any serious implementation of ERC-1155 will already utilize JSON Metadata. ### Upgrades The requirement to emit `TransferSingle` or `TransferBatch` on balance change implies that a valid implementation of ERC-1155 redeploying to a new contract address MUST emit events from the new contract address to replicate the deprecated contract final state. It is valid to only emit a minimal number of events to reflect only the final balance and omit all the transactions that led to that state. The event emit requirement is to ensure that the current state of the contract can always be traced only through events. To alleviate the need to emit events when changing contract address, consider using the proxy pattern, such as described in [EIP-2535](/EIPS/eip-2535). This will also have the added benefit of providing a stable contract address for users. ### Design decision: Supporting non-batch The standard supports `safeTransferFrom` and `onERC1155Received` functions because they are significantly cheaper for single token-type transfers, which is arguably a common use case. ### Design decision: Safe transfers only The standard only supports safe-style transfers, making it possible for receiver contracts to depend on `onERC1155Received` or `onERC1155BatchReceived` function to be always called at the end of a transfer. ### Guaranteed log trace As the Ethereum ecosystem continues to grow, many dapps are relying on traditional databases and explorer API services to retrieve and categorize data. The ERC-1155 standard guarantees that event logs emitted by the smart contract will provide enough data to create an accurate record of all current token balances. A database or explorer may listen to events and be able to provide indexed and categorized searches of every ERC-1155 token in the contract. ### Approval The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts. Restricting approval to a certain set of token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](/EIPS/eip-1761) which is compatible with ERC-1155. ## Backwards Compatibility There have been requirements during the design discussions to have this standard be compatible with existing standards when sending to contract addresses, specifically ERC-721 at time of writing. To cater for this scenario, there is some leeway with the revert logic should a contract not implement the `ERC1155TokenReceiver` as per "Safe Transfer Rules" section above, specifically "Scenario#3 : The receiver does not implement the necessary `ERC1155TokenReceiver` interface function(s)". Hence in a hybrid ERC-1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to `onERC1155Received` or `onERC1155BatchReceived` are made. Order of operation MUST therefore be: 1. The implementation MUST call the function `supportsInterface(0x4e2312e0)` on the recipient contract, providing at least 10,000 gas. 2. If the function call succeeds and the return value is the constant value `true` the implementation proceeds as a regular ERC-1155 implementation, with the call(s) to the `onERC1155Received` or `onERC1155BatchReceived` hooks and rules associated. 3. If the function call fails or the return value is NOT the constant value `true` the implementation can assume the recipient contract is not an `ERC1155TokenReceiver` and follow its other standard's rules for transfers. *__Note that a pure implementation of a single standard is recommended__* rather than a hybrid solution, but an example of a hybrid ERC-1155/ERC-721 contract is linked in the references section under implementations. An important consideration is that even if the tokens are sent with another standard's rules the *__ERC-1155 transfer events MUST still be emitted.__* This is so the balances can still be determined via events alone as per ERC-1155 standard rules. ## Usage This standard can be used to represent multiple token types for an entire domain. Both fungible and non-fungible tokens can be stored in the same smart-contract. ### Batch Transfers The `safeBatchTransferFrom` function allows for batch transfers of multiple token IDs and values. The design of ERC-1155 makes batch transfers possible without the need for a wrapper contract, as with existing token standards. This reduces gas costs when more than one token type is included in a batch transfer, as compared to single transfers with multiple transactions. Another advantage of standardized batch transfers is the ability for a smart contract to respond to the batch transfer in a single operation using `onERC1155BatchReceived`. It is RECOMMENDED that clients and wallets sort the token IDs and associated values (in ascending order) when posting a batch transfer, as some ERC-1155 implementations offer significant gas cost savings when IDs are sorted. See [Horizon Games - Multi-Token Standard](https://github.com/horizon-games/multi-token-standard) "packed balance" implementation for an example of this. ### Batch Balance The `balanceOfBatch` function allows clients to retrieve balances of multiple owners and token IDs with a single call. ### Enumerating from events In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block. ERC-1155 contracts must therefore carefully emit `TransferSingle` or `TransferBatch` events in any instance where tokens are created, minted, transferred or destroyed. ### Non-Fungible Tokens The following strategies are examples of how you MAY mix fungible and non-fungible tokens together in the same contract. The standard does NOT mandate how an implementation must do this. ##### Split ID bits The top 128 bits of the uint256 `_id` parameter in any ERC-1155 function MAY represent the base token ID, while the bottom 128 bits MAY represent the index of the non-fungible to make it unique. Non-fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and a particular non-fungible within that set, `_id` could be passed as `<uint128: base token id><uint128: index of non-fungible>`. To identify a non-fungible set/category as a whole (or a fungible) you COULD just pass in the base id via the `_id` argument as `<uint128: base token id><uint128: zero>`. If your implementation uses this technique this naturally means the index of a non-fungible SHOULD be 1-based. Inside the contract code the two pieces of data needed to access the individual non-fungible can be extracted with uint128(~0) and the same mask shifted by 128. ```solidity uint256 baseTokenNFT = 12345 << 128; uint128 indexNFT = 50; uint256 baseTokenFT = 54321 << 128; balanceOf(msg.sender, baseTokenNFT); // Get balance of the base token for non-fungible set 12345 (this MAY be used to get balance of the user for all of this token set if the implementation wishes as a convenience). balanceOf(msg.sender, baseTokenNFT + indexNFT); // Get balance of the token at index 50 for non-fungible set 12345 (should be 1 if user owns the individual non-fungible token or 0 if they do not). balanceOf(msg.sender, baseTokenFT); // Get balance of the fungible base token 54321. ``` Note that 128 is an arbitrary number, an implementation MAY choose how they would like this split to occur as suitable for their use case. An observer of the contract would simply see events showing balance transfers and mints happening and MAY track the balances using that information alone. For an observer to be able to determine type (non-fungible or fungible) from an ID alone they would have to know the split ID bits format on a implementation by implementation basis. The [ERC-1155 Reference Implementation](https://github.com/enjin/erc-1155) is an example of the split ID bits strategy. ##### Natural Non-Fungible tokens Another simple way to represent non-fungibles is to allow a maximum value of 1 for each non-fungible token. This would naturally mirror the real world, where unique items have a quantity of 1 and fungible items have a quantity greater than 1. ## References **Standards** - [ERC-721 Non-Fungible Token Standard](/EIPS/eip-721) - [ERC-165 Standard Interface Detection](/EIPS/eip-165) - [ERC-1538 Transparent Contract Standard](/EIPS/eip-1538) - [JSON Schema](https://json-schema.org/) - [RFC 2119 Key words for use in RFCs to Indicate Requirement Levels](https://www.ietf.org/rfc/rfc2119.txt) **Implementations** - [ERC-1155 Reference Implementation](https://github.com/enjin/erc-1155) - [Horizon Games - Multi-Token Standard](https://github.com/horizon-games/multi-token-standard) - [Enjin Coin](https://enjincoin.io) ([GitHub](https://github.com/enjin)) - [The Sandbox - Dual ERC-1155/721 Contract](https://github.com/pixowl/thesandbox-contracts/tree/master/src/Asset) **Articles & Discussions** - [GitHub - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1155) - [ERC-1155 - The Crypto Item Standard](https://blog.enjincoin.io/erc-1155-the-crypto-item-standard-ac9cf1c5a226) - [Here Be Dragons - Going Beyond ERC-20 and ERC-721 To Reduce Gas Cost by ~80%](https://medium.com/horizongames/going-beyond-erc20-and-erc721-9acebd4ff6ef) - [Blockonomi - Ethereum ERC-1155 Token Perfect for Online Games, Possibly More](https://blockonomi.com/erc1155-gaming-token/) - [Beyond Gaming - Exploring the Utility of ERC-1155 Token Standard!](https://blockgeeks.com/erc-1155-token/) - [ERC-1155: A new standard for The Sandbox](https://medium.com/sandbox-game/erc-1155-a-new-standard-for-the-sandbox-c95ee1e45072) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 17 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1155 https://eips.ethereum.org/EIPS/eip-1155 Minimal Proxy Contract Standards Track/ERC https://github.com/optionality/clone-factory/issues/10 ## Simple Summary To simply and cheaply clone contract functionality in an immutable way, this standard specifies a minimal bytecode implementation that delegates all calls to a known, fixed address. ## Abstract By standardizing on a known minimal bytecode redirect implementation, this standard allows users and third party tools (e.g. Etherscan) to (a) simply discover that a contract will always redirect in a known manner and (b) depend on the behavior of the code at the destination contract as the behavior of the redirecting contract. Specifically, tooling can interrogate the bytecode at a redirecting address to determine the location of the code that will run - and can depend on representations about that code (verified source, third-party audits, etc). This implementation forwards all calls and 100% of the gas to the implementation contract and then relays the return value back to the caller. In the case where the implementation reverts, the revert is passed back along with the payload data (for revert with message). ## Motivation This standard supports use-cases wherein it is desirable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies. ## Specification The exact bytecode of the standard clone contract is this: `363d3d373d3d3d363d73bebebebebebebebebebebebebebebebebebebebe5af43d82803e903d91602b57fd5bf3` wherein the bytes at indices 10 - 29 (inclusive) are replaced with the 20 byte address of the master functionality contract. A reference implementation of this can be found at the [optionality/clone-factory](https://github.com/optionality/clone-factory) github repo. ## Rationale The goals of this effort have been the following: - inexpensive deployment (low gas to deploy clones) - support clone initialization in creation transaction (through factory contract model) - simple clone bytecode to encourage directly bytecode interrogation (see CloneProbe.sol in the clone-factory project) - dependable, locked-down behavior - this is not designed to handle upgradability, nor should it as the representation we are seeking is stronger. - small operational overhead - adds a single call cost to each call - handles error return bubbling for revert messages ## Backwards Compatibility There are no backwards compatibility issues. There may be some systems that are using earlier versions of the proxy contract bytecode. They will not be compliant with this standard. ## Test Cases Test cases include: - invocation with no arguments - invocation with arguments - invocation with fixed length return values - invocation with variable length return values - invocation with revert (confirming reverted payload is transferred) Tests for these cases are included in the reference implementation project. ## Implementation Deployment bytecode is not included in this specification. One approach is defined in the proxy-contract reference implementation. ### Standard Proxy The disassembly of the standard deployed proxy contract code (from r2 and edited to include stack visualization) ``` | 0x00000000 36 calldatasize cds | 0x00000001 3d returndatasize 0 cds | 0x00000002 3d returndatasize 0 0 cds | 0x00000003 37 calldatacopy | 0x00000004 3d returndatasize 0 | 0x00000005 3d returndatasize 0 0 | 0x00000006 3d returndatasize 0 0 0 | 0x00000007 36 calldatasize cds 0 0 0 | 0x00000008 3d returndatasize 0 cds 0 0 0 | 0x00000009 73bebebebebe. push20 0xbebebebe 0xbebe 0 cds 0 0 0 | 0x0000001e 5a gas gas 0xbebe 0 cds 0 0 0 | 0x0000001f f4 delegatecall suc 0 | 0x00000020 3d returndatasize rds suc 0 | 0x00000021 82 dup3 0 rds suc 0 | 0x00000022 80 dup1 0 0 rds suc 0 | 0x00000023 3e returndatacopy suc 0 | 0x00000024 90 swap1 0 suc | 0x00000025 3d returndatasize rds 0 suc | 0x00000026 91 swap2 suc 0 rds | 0x00000027 602b push1 0x2b 0x2b suc 0 rds | ,=< 0x00000029 57 jumpi 0 rds | | 0x0000002a fd revert | `-> 0x0000002b 5b jumpdest 0 rds \ 0x0000002c f3 return ``` NOTE: as an effort to reduce gas costs as much as possible, the above bytecode depends on EIP-211 specification that `returndatasize` returns zero prior to any calls within the call-frame. `returndatasize` uses 1 less gas than `dup*`. ### Vanity Address Optimization Proxy deployment can be further optimized by installing the master contract at a vanity contract deployment address with leading zero-bytes. By generating a master contract vanity address that includes Z leading 0 bytes in its address, you can shorten the proxy bytecode by replacing the `push20` opcode with `pushN` (where N is 20 - Z) followed by the N non-zero address bytes. The revert jump address is decremented by Z in this case. Here is an example where Z = 4: ``` | 0x00000000 36 calldatasize cds | 0x00000001 3d returndatasize 0 cds | 0x00000002 3d returndatasize 0 0 cds | 0x00000003 37 calldatacopy | 0x00000004 3d returndatasize 0 | 0x00000005 3d returndatasize 0 0 | 0x00000006 3d returndatasize 0 0 0 | 0x00000007 36 calldatasize cds 0 0 0 | 0x00000008 3d returndatasize 0 cds 0 0 0 | 0x00000009 6fbebebebebe. push16 0xbebebebe 0xbebe 0 cds 0 0 0 | 0x0000001a 5a gas gas 0xbebe 0 cds 0 0 0 | 0x0000001b f4 delegatecall suc 0 | 0x0000001c 3d returndatasize rds suc 0 | 0x0000001d 82 dup3 0 rds suc 0 | 0x0000001e 80 dup1 0 0 rds suc 0 | 0x0000001f 3e returndatacopy suc 0 | 0x00000020 90 swap1 0 suc | 0x00000021 3d returndatasize rds 0 suc | 0x00000022 91 swap2 suc 0 rds | 0x00000023 6027 push1 0x27 0x27 suc 0 rds | ,=< 0x00000025 57 jumpi 0 rds | | 0x00000026 fd revert | `-> 0x00000027 5b jumpdest 0 rds \ 0x00000028 f3 return ``` This saves 4 bytes of proxy contract size (savings on each deployment) and has zero impact on runtime gas costs. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 22 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1167 https://eips.ethereum.org/EIPS/eip-1167 Wallet & shop standard for all tokens (erc20) Standards Track/ERC https://github.com/ethereum/EIPs/issues/1182 # All tokens go to heaven ## Simple Summary Make wallets and shops created from certified contracts make erc20 tokens easy to use for commerce. ![wallet](/assets/eip-1175/wallet.png) ## Abstract The mutual trust between the wallet and the shop created by the authenticated contract allows you to pay for and purchase items at a simple process. ## Motivation New standards with improvements have been released, but the majority of tokens currently being developed are erc20 tokens. So I felt I needed a proposal to use old tokens in commerce. To use various erc20 tokens for trading, you need a custom contract. However, a single wallet with a variety of tokens, and a mutually trusted store, can make transactions that are simple and efficient. The erc20 token is traded through two calls, `approve (address _spender, uint256 _value)` and `transferFrom (address _from, address _to, uint256 _value)`, but when using the wallet contract, `paySafe (address _shop, uint256 _item)`will be traded only in one call. And if you only reuse the store interface, you can also trade using `payUnsafe (address _shop, uint256 _item)`. ## Specification ![workflow](/assets/eip-1175/workflow.png) ## WalletCenter ### Methods #### createWallet Create wallet contract and add to list. Returns the address of new wallet. ``` js function createWallet() public returns (address _wallet) ``` #### isWallet Returns true or false value for test this address is a created by createWallet. ``` js function isWallet(address _wallet) public constant returns (bool) ``` #### createShop Create Shop contract and add to list. Returns the address of new Shop with erc20 token address. ``` js function createShop(address _erc20) public returns (address _shop) ``` #### isShop Returns true or false value for test this address is a created by createWallet. ``` js function isShop(address _shop) public constant returns (bool) ``` ### Events #### Wallet Search for my wallet. ``` js event Wallet(address indexed _owner, address indexed _wallet) ``` #### Shop Search for my shop. ``` js event Shop(address indexed _owner, address indexed _shop, address indexed _erc20) ``` ## Wallet Wallet must be created by wallet center. ### Methods #### balanceOf Returns the account balance of Wallet. ``` js function balanceOf(address _erc20) public constant returns (uint256 balance) ``` #### withdrawal withdrawal `_value` amount of `_erc20` token to `_owner`. ``` js function withdrawal(address _erc20, uint256 _value) onlyOwner public returns (bool success) ``` #### paySafe Pay for safe shop (created by contract) item with item index `_item`. ``` js function paySafe(address _shop, uint256 _item) onlyOwner onlyShop(_shop) public payable returns (bool success) ``` #### payUnsafe Pay for unsafe shop (did not created by contract) item with item index `_item`. ``` js function payUnsafe(address _shop, uint256 _item) onlyOwner public payable returns (bool success) ``` #### payCancel Cancel pay and refund. (only weekly model) ``` js function payCancel(address _shop, uint256 _item) onlyOwner public returns (bool success) ``` #### refund Refund from shop with item index `_item`. ``` js function refund(uint256 _item, uint256 _value) public payable returns (bool success) ``` ### Events #### Pay ``` js event Pay(address indexed _shop, uint256 indexed _item, uint256 indexed _value) ``` #### Refund ``` js event Refund(address indexed _shop, uint256 indexed _item, uint256 indexed _value) ``` ## Shop Shop is created by wallet center or not. but Shop that created by wallet center is called safe shop. ### Methods #### balanceOf Returns the account balance of Shop. ``` js function balanceOf(address _erc20) public constant returns (uint256 balance) ``` #### withdrawal withdrawal `_value` amount of `_erc20` token to `_owner`. ``` js function withdrawal(address _erc20, uint256 _value) onlyOwner public returns (bool success) ``` #### pay Pay from buyer with item index `_item`. ``` js function pay(uint256 _item) onlyWallet(msg.sender) public payable returns (bool success) ``` #### refund refund token to `_to`. ``` js function refund(address _buyer, uint256 _item, uint256 _value) onlyWallet(_buyer) onlyOwner public payable returns (bool success) ``` #### resister Listing item for sell. ``` js function resister(uint8 _category, uint256 _price, uint256 _stock) onlyOwner public returns (uint256 _itemId) ``` #### update Update item state for sell. (change item `_price` or add item `_stock`) ``` js function update(uint256 _item, uint256 _price, uint256 _stock) onlyOwner public ``` #### price Get token address and price from buyer with item index `_item`. ``` js function price(uint256 _item) public constant returns (address _erc20, uint256 _value) ``` #### canBuy `_who` can Buy `_item`. ``` js function canBuy(address _who, uint256 _item) public constant returns (bool _canBuy) ``` #### isBuyer `_who` is buyer of `_item`. ``` js function isBuyer(address _who, uint256 _item) public constant returns (bool _buyer) ``` #### info Set shop information bytes. ``` js function info(bytes _msgPack) ``` #### upVote Up vote for this shop. ``` js function upVote() ``` #### dnVote Down vote for this shop. ``` js function dnVote() ``` #### about Get shop token, up vote and down vote. ``` js function about() view returns (address _erc20, uint256 _up, uint256 _down) ``` #### infoItem Set item information bytes. ``` js function infoItem(uint256 _item, bytes _msgPack) ``` #### upVoteItem Up vote for this item. ``` js function upVoteItem(uint256 _item) ``` #### dnVoteItem Down vote for this item. ``` js function dnVoteItem(uint256 _item) ``` #### aboutItem Get Item price, up vote and down vote. ``` js function aboutItem(uint256 _item) view returns (uint256 _price, uint256 _up, uint256 _down) ``` ### Events #### Pay ``` js event Pay(address indexed _buyer, uint256 indexed _item, uint256 indexed _value) ``` #### Refund ``` js event Refund(address indexed _to, uint256 indexed _item, uint256 indexed _value) ``` #### Item ``` js event Item(uint256 indexed _item, uint256 _price) ``` #### Info ``` js event Info(bytes _msgPack) ``` #### InfoItem ``` js event InfoItem(uint256 indexed _item, bytes _msgPack) ``` ## Implementation Sample token contract address is [0x393dd70ce2ae7b30501aec94727968c517f90d52](https://ropsten.etherscan.io/address/0x393dd70ce2ae7b30501aec94727968c517f90d52) WalletCenter contract address is [0x1fe0862a4a8287d6c23904d61f02507b5044ea31](https://ropsten.etherscan.io/address/0x1fe0862a4a8287d6c23904d61f02507b5044ea31) WalletCenter create shop contract address is [0x59117730D02Ca3796121b7975796d479A5Fe54B0](https://ropsten.etherscan.io/address/0x59117730D02Ca3796121b7975796d479A5Fe54B0) WalletCenter create wallet contract address is [0x39da7111844df424e1d0a0226183533dd07bc5c6](https://ropsten.etherscan.io/address/0x39da7111844df424e1d0a0226183533dd07bc5c6) ## Appendix ``` js pragma solidity ^0.4.24; contract ERC20Interface { function totalSupply() public constant returns (uint); function balanceOf(address tokenOwner) public constant returns (uint balance); function allowance(address tokenOwner, address spender) public constant returns (uint remaining); function transfer(address to, uint tokens) public returns (bool success); function approve(address spender, uint tokens) public returns (bool success); function transferFrom(address from, address to, uint tokens) public returns (bool success); event Transfer(address indexed from, address indexed to, uint tokens); event Approval(address indexed tokenOwner, address indexed spender, uint tokens); } contract SafeMath { function safeAdd(uint a, uint b) public pure returns (uint c) { c = a + b; require(c >= a); } function safeSub(uint a, uint b) public pure returns (uint c) { require(b <= a); c = a - b; } function safeMul(uint a, uint b) public pure returns (uint c) { c = a * b; require(a == 0 || c / a == b); } function safeDiv(uint a, uint b) public pure returns (uint c) { require(b > 0); c = a / b; } } contract _Base { address internal owner; address internal walletCenter; modifier onlyOwner { require(owner == msg.sender); _; } modifier onlyWallet(address _addr) { require(WalletCenter(walletCenter).isWallet(_addr)); _; } modifier onlyShop(address _addr) { require(WalletCenter(walletCenter).isShop(_addr)); _; } function balanceOf(address _erc20) public constant returns (uint256 balance) { if(_erc20==address(0)) return address(this).balance; return ERC20Interface(_erc20).balanceOf(this); } function transfer(address _to, address _erc20, uint256 _value) internal returns (bool success) { require((_erc20==address(0)?address(this).balance:ERC20Interface(_erc20).balanceOf(this))>=_value); if(_erc20==address(0)) _to.transfer(_value); else ERC20Interface(_erc20).approve(_to,_value); return true; } function withdrawal(address _erc20, uint256 _value) public returns (bool success); event Pay(address indexed _who, uint256 indexed _item, uint256 indexed _value); event Refund(address indexed _who, uint256 indexed _item, uint256 indexed _value); event Prize(address indexed _who, uint256 indexed _item, uint256 indexed _value); } contract _Wallet is _Base { constructor(address _who) public { owner = _who; walletCenter = msg.sender; } function pay(address _shop, uint256 _item) private { require(_Shop(_shop).canBuy(this,_item)); address _erc20; uint256 _value; (_erc20,_value) = _Shop(_shop).price(_item); transfer(_shop,_erc20,_value); _Shop(_shop).pay(_item); emit Pay(_shop,_item,_value); } function paySafe(address _shop, uint256 _item) onlyOwner onlyShop(_shop) public payable returns (bool success) { pay(_shop,_item); return true; } function payUnsafe(address _shop, uint256 _item) onlyOwner public payable returns (bool success) { pay(_shop,_item); return true; } function payCancel(address _shop, uint256 _item) onlyOwner public returns (bool success) { _Shop(_shop).payCancel(_item); return true; } function refund(address _erc20, uint256 _item, uint256 _value) public payable returns (bool success) { require((_erc20==address(0)?msg.value:ERC20Interface(_erc20).allowance(msg.sender,this))==_value); if(_erc20!=address(0)) ERC20Interface(_erc20).transferFrom(msg.sender,this,_value); emit Refund(msg.sender,_item,_value); return true; } function prize(address _erc20, uint256 _item, uint256 _value) public payable returns (bool success) { require((_erc20==address(0)?msg.value:ERC20Interface(_erc20).allowance(msg.sender,this))==_value); if(_erc20!=address(0)) ERC20Interface(_erc20).transferFrom(msg.sender,this,_value); emit Prize(msg.sender,_item,_value); return true; } function withdrawal(address _erc20, uint256 _value) onlyOwner public returns (bool success) { require((_erc20==address(0)?address(this).balance:ERC20Interface(_erc20).balanceOf(this))>=_value); if(_erc20==address(0)) owner.transfer(_value); else ERC20Interface(_erc20).transfer(owner,_value); return true; } } contract _Shop is _Base, SafeMath{ address erc20; constructor(address _who, address _erc20) public { owner = _who; walletCenter = msg.sender; erc20 = _erc20; } struct item { uint8 category; // 0 = disable, 1 = non Stock, non Expire, 2 = can Expire (after 1 week), 3 = stackable uint256 price; uint256 stockCount; mapping(address=>uint256) customer; } uint index; mapping(uint256=>item) items; function pay(uint256 _item) onlyWallet(msg.sender) public payable returns (bool success) { require(canBuy(msg.sender, _item)); require((erc20==address(0)?msg.value:ERC20Interface(erc20).allowance(msg.sender,this))==items[_item].price); if(erc20!=address(0)) ERC20Interface(erc20).transferFrom(msg.sender,this,items[_item].price); if(items[_item].category==1 || items[_item].category==2 && now > safeAdd(items[_item].customer[msg.sender], 1 weeks)) items[_item].customer[msg.sender] = now; else if(items[_item].category==2 && now < safeAdd(items[_item].customer[msg.sender], 1 weeks) ) items[_item].customer[msg.sender] = safeAdd(items[_item].customer[msg.sender], 1 weeks); else if(items[_item].category==3) { items[_item].customer[msg.sender] = safeAdd(items[_item].customer[msg.sender],1); items[_item].stockCount = safeSub(items[_item].stockCount,1); } emit Pay(msg.sender,_item,items[_item].customer[msg.sender]); return true; } function payCancel(uint256 _item) onlyWallet(msg.sender) public returns (bool success) { require (items[_item].category==2&&safeAdd(items[_item].customer[msg.sender],2 weeks)>now&&balanceOf(erc20)>=items[_item].price); items[_item].customer[msg.sender] = safeSub(items[_item].customer[msg.sender],1 weeks); transfer(msg.sender, erc20, items[_item].price); _Wallet(msg.sender).refund(erc20,_item,items[_item].price); emit Refund(msg.sender,_item,items[_item].price); return true; } function refund(address _to, uint256 _item) onlyWallet(_to) onlyOwner public payable returns (bool success) { require(isBuyer(_to,_item)&&items[_item].category>0&&(items[_item].customer[_to]>0||(items[_item].category==2&&safeAdd(items[_item].customer[_to],2 weeks)>now))); require((erc20==address(0)?address(this).balance:ERC20Interface(erc20).balanceOf(this))>=items[_item].price); if(items[_item].category==1) items[_item].customer[_to] = 0; else if(items[_item].category==2) items[_item].customer[_to] = safeSub(items[_item].customer[_to],1 weeks); else items[_item].customer[_to] = safeSub(items[_item].customer[_to],1); transfer(_to, erc20, items[_item].price); _Wallet(_to).refund(erc20,_item,items[_item].price); emit Refund(_to,_item,items[_item].price); return true; } event Item(uint256 indexed _item, uint256 _price); function resister(uint8 _category, uint256 _price, uint256 _stock) onlyOwner public returns (uint256 _itemId) { require(_category>0&&_category<4); require(_price>0); items[index] = item(_category,_price,_stock); index = safeAdd(index,1); emit Item(index,_price); return safeSub(index,1); } function update(uint256 _item, uint256 _price, uint256 _stock) onlyOwner public { require(items[_item].category>0); require(_price>0); uint256 temp = items[_item].price; items[_item].price = _price; items[_item].stockCount = safeAdd(items[_item].stockCount,_stock); if(temp!=items[_item].price) emit Item(index,items[_item].price); } function price(uint256 _item) public constant returns (address _erc20, uint256 _value) { return (erc20,items[_item].price); } function canBuy(address _who, uint256 _item) public constant returns (bool _canBuy) { return (items[_item].category>0) && !(items[_item].category==1&&items[_item].customer[_who]>0) && (items[_item].stockCount>0); } function isBuyer(address _who, uint256 _item) public constant returns (bool _buyer) { return (items[_item].category==1&&items[_item].customer[_who]>0)||(items[_item].category==2&&safeAdd(items[_item].customer[_who],1 weeks)>now)||(items[_item].category==3&&items[_item].customer[_who]>0); } uint lastWithdrawal; function withdrawal(address _erc20, uint256 _value) onlyOwner public returns (bool success) { require(safeAdd(lastWithdrawal,1 weeks)<=now); require((_erc20==address(0)?address(this).balance:ERC20Interface(_erc20).balanceOf(this))>=_value); if(_erc20==address(0)) owner.transfer(_value); else ERC20Interface(_erc20).transfer(owner,_value); lastWithdrawal = now; return true; } } contract WalletCenter { mapping(address=>bool) public wallet; event Wallet(address indexed _owner, address indexed _wallet); function createWallet() public returns (address _wallet) { _wallet = new _Wallet(msg.sender); wallet[_wallet] = true; emit Wallet(msg.sender,_wallet); return _wallet; } function isWallet(address _wallet) public constant returns (bool) { return wallet[_wallet]; } mapping(address=>bool) public shop; event Shop(address indexed _owner, address indexed _shop, address indexed _erc20); function createShop(address _erc20) public returns (address _shop) { _shop = new _Shop(msg.sender,_erc20); shop[_shop] = true; emit Shop(msg.sender,_shop,_erc20); return _shop; } function isShop(address _shop) public constant returns (bool) { return shop[_shop]; } } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 21 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1175 https://eips.ethereum.org/EIPS/eip-1175 Multi-class Token Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1179 ## Simple Summary A standard interface for multi-class fungible tokens. ## Abstract This standard allows for the implementation of a standard API for multi-class fungible tokens (henceforth referred to as "MCFTs") within smart contracts. This standard provides basic functionality to track and transfer ownership of MCFTs. ## Motivation Currently, there is no standard to support tokens that have multiple classes. In the real world, there are many situations in which defining distinct classes of the same token would be fitting (e.g. distinguishing between preferred/common/restricted shares of a company). Yet, such nuance cannot be supported in today's token standards. An ERC-20 token contract defines tokens that are all of one class while an ERC-721 token contract creates a class (defined by token_id) for each individual token. The ERC-1178 token standard proposes a new standard for creating multiple classes of tokens within one token contract. > Aside: In theory, while it is possible to implement tokens with classes using the properties of token structs in ERC-721 tokens, gas costs of implementing this in practice are prohibitive for any non-trivial application. ## Specification ### ERC-20 Compatibility (partial) **name** ```solidity function name() constant returns (string name) ``` *OPTIONAL - It is recommended that this method is implemented for enhanced usability with wallets and exchanges, but interfaces and other contracts MUST NOT depend on the existence of this method.* Returns the name of the aggregate collection of MCFTs managed by this contract. - e.g. `"My Company Tokens"`. **class name** ```solidity function className(uint256 classId) constant returns (string name) ``` *OPTIONAL - It is recommended that this method is implemented for enhanced usability with wallets and exchanges, but interfaces and other contracts MUST NOT depend on the existence of this method.* Returns the name of the class of MCFT managed by this contract. - e.g. `"My Company Preferred Shares Token"`. **symbol** ```solidity function symbol() constant returns (string symbol) ``` *OPTIONAL - It is recommend that this method is implemented for enhanced usability with wallets and exchanges, but interfaces and other contracts MUST NOT depend on the existence of this method.* Returns a short string symbol referencing the entire collection of MCFT managed in this contract. e.g. "MUL". This symbol SHOULD be short (3-8 characters is recommended), with no whitespace characters or new-lines and SHOULD be limited to the uppercase latin alphabet (i.e. the 26 letters used in English). **totalSupply** ```solidity function totalSupply() constant returns (uint256 totalSupply) ``` Returns the total number of all MCFTs currently tracked by this contract. **individualSupply** ```solidity function individualSupply(uint256 _classId) constant returns (uint256 individualSupply) ``` Returns the total number of MCFTs of class `_classId` currently tracked by this contract. **balanceOf** ```solidity function balanceOf(address _owner, uint256 _classId) constant returns (uint256 balance) ``` Returns the number of MCFTs of token class `_classId` assigned to address `_owner`. **classesOwned** ```solidity function classesOwned(address _owner) constant returns (uint256[] classes) ``` Returns an array of `_classId`'s of MCFTs that address `_owner` owns in the contract. > NOTE: returning an array is supported by `pragma experimental ABIEncoderV2` ## Basic Ownership **approve** ```solidity function approve(address _to, uint256 _classId, uint256 quantity) ``` Grants approval for address `_to` to take possession `quantity` amount of the MCFT with ID `_classId`. This method MUST `throw` if `balanceOf(msg.sender, _classId) < quantity`, or if `_classId` does not represent an MCFT class currently tracked by this contract, or if `msg.sender == _to`. Only one address can "have approval" at any given time for a given address and `_classId`. Calling `approve` with a new address and `_classId` revokes approval for the previous address and `_classId`. Calling this method with 0 as the `_to` argument clears approval for any address and the specified `_classId`. Successful completion of this method MUST emit an `Approval` event (defined below) unless the caller is attempting to clear approval when there is no pending approval. In particular, an Approval event MUST be fired if the `_to` address is zero and there is some outstanding approval. Additionally, an Approval event MUST be fired if `_to` is already the currently approved address and this call otherwise has no effect. (i.e. An `approve()` call that "reaffirms" an existing approval MUST fire an event.) <!-- ActionPrior State_to addressNew StateEventClear unset approvalClear0ClearNoneSet new approvalClearXSet to XApproval(owner, X, _classId)Change approvalSet to XYSet to YApproval(owner, Y, _classId)Reaffirm approvalSet to XXSet to XApproval(owner, X, _classId)Clear approvalSet to X0ClearApproval(owner, 0, _classId) Note: ANY change of ownership of an MCFT – whether directly through the `transfer` and `transferFrom` methods defined in this interface, or through any other mechanism defined in the conforming contract – MUST clear any and all approvals for the transferred MCFT. The implicit clearing of approval via ownership transfer MUST also fire the event `Approval(0, _classId)` if there was an outstanding approval. (i.e. All actions that transfer ownership must emit the same Approval event, if any, as would emitted by calling `approve(0, _classId)`.)--> **transfer** ```solidity function transfer(address _to, uint256 _classId, uint256 quantity) ``` Assigns the ownership of `quantity` MCFT's with ID `_classId` to `_to` if and only if `quantity == balanceOf(msg.sender, _classId)`. A successful transfer MUST fire the `Transfer` event (defined below). This method MUST transfer ownership to `_to` or `throw`, no other outcomes can be possible. Reasons for failure include (but are not limited to): * `msg.sender` is not the owner of `quantity` amount of tokens of `_classId`'s. * `_classId` does not represent an MCFT class currently tracked by this contract A conforming contract MUST allow the current owner to "transfer" a token to themselves, as a way of affirming ownership in the event stream. (i.e. it is valid for `_to == msg.sender` if `balanceOf(msg.sender, _classId) >= balance`.) This "no-op transfer" MUST be considered a successful transfer, and therefore MUST fire a `Transfer` event (with the same address for `_from` and `_to`). ## Advanced Ownership and Exchange ```solidity function approveForToken(uint256 classIdHeld, uint256 quantityHeld, uint256 classIdWanted, uint256 quantityWanted) ``` Allows holder of one token to allow another individual (or the smart contract itself) to approve the exchange of their tokens of one class for tokens of another class at their specified exchange rate (see sample implementation for more details). This is equivalent to posting a bid in a marketplace. ```solidity function exchange(address to, uint256 classIdPosted, uint256 quantityPosted, uint256 classIdWanted, uint256 quantityWanted) ``` Allows an individual to fill an existing bid (see above function) and complete the exchange of their tokens of one class for another. In the sample implementation, this function call should fail unless the callee has already approved the contract to transfer their tokens. Of course, it is possible to create an implementation where calling this function implicitly assumes approval and the transfer is completed in one step. ```solidity transferFrom(address from, address to, uint256 classId) ``` Allows a third party to initiate a transfer of tokens from `from` to `to` assuming the approvals have been granted. ## Events **Transfer** This event MUST trigger when MCFT ownership is transferred via any mechanism. Additionally, the creation of new MCFTs MUST trigger a Transfer event for each newly created MCFTs, with a `_from` address of 0 and a `_to` address matching the owner of the new MCFT (possibly the smart contract itself). The deletion (or burn) of any MCFT MUST trigger a Transfer event with a `_to` address of 0 and a `_from` address of the owner of the MCFT (now former owner!). NOTE: A Transfer event with `_from == _to` is valid. See the `transfer()` documentation for details. ```solidity event Transfer(address indexed _from, address indexed _to, uint256 _classId) ``` **Approval** This event MUST trigger on any successful call to `approve(_to, _classId, quantity)` (unless the caller is attempting to clear approval when there is no pending approval). ```solidity event Approval(address indexed _owner, address indexed _approved, uint256 _classId) ``` ## Rationale ### Current Limitations The design of this project was motivated when I tried to create different classes of fungible ERC-721 tokens (an oxymoron) but ran into gas limits from having to create each tokens individually and maintain them in an efficient data structure for access. Using the maximum gas amount one can send with a transaction on Metamask (a popular web wallet), I was only able to create around 46 ERC-721 tokens before exhausting all gas. This experience motivated the creation of the multi-class fungible token standard. ## Backwards Compatibility Adoption of the MCFT standard proposal would not pose backwards compatibility issues as it defines a new standard for token creation. This standard follows the semantics of ERC-721 as closely as possible, but can't be entirely compatible with it due to the fundamental differences between multi-class fungible and non-fungible tokens. For example, the `ownerOf`, `takeOwnership`, and `tokenOfOwnerByIndex` methods in the ERC-721 token standard cannot be implemented in this standard. Furthermore, the function arguments to `balanceOf`, `approve`, and `transfer` differ as well. ## Implementation A sample implementation can be found [here](https://github.com/achon22/ERC-1178/blob/master/erc1178-sample.sol) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 22 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1178 https://eips.ethereum.org/EIPS/eip-1178 Storage of DNS Records in ENS Standards Track/ERC https://ethereum-magicians.org/t/eip1185-dns-resolver-profile-for-ens/1589 ## Abstract This EIP defines a resolver profile for ENS that provides features for storage and lookup of DNS records. This allows ENS to be used as a store of authoritative DNS information. ## Motivation ENS is a highly desirable store for DNS information. It provides the distributed authority of DNS without conflating ownership and authoritative serving of information. With ENS, the owner of a domain has full control over their own DNS records. Also, ENS has the ability (through smart contracts) for a domain's subdomains to be irrevocably assigned to another entity. ## Specification The resolver profile to support DNS on ENS follows the resolver specification as defined in [ERC-137](/EIPS/eip-137). Traditionally, DNS is a zone-based system in that all of the records for a zone are kept together in the same file. This has the benefit of simplicity and atomicity of zone updates, but when transposed to ENS can result in significant gas costs for simple changes. As a result, the resolver works on the basis of record sets. A record set is uniquely defined by the tuple `(domain, name, resource record type)`, for example the tuple `(example.com, www.example.com, A)` defines the record set of `A` records for the name `www.example.com` in the domain `example.com`. A record set can contain 0 or more values, for example if `www.example.com` has `A` records `1.2.3.4` and `5.6.7.8` then the aforementioned tuple will have two values. The choice to work at the level of record sets rather than zones means that this specification cannot completely support some features of DNS, such as zone transfers and DNSSEC. It would be possible to build a different resolver profile that works at the zone level, however it would be very expensive to carry out updates and so is not considered further for this EIP. The DNS resolver interface consists of two functions to set DNS information and two functions to query DNS information. ### setDNSRecords(bytes32 node, bytes data) `setDNSRecords()` sets, updates or clears 1 or more DNS records for a given node. It has function signature `0x0af179d7`. The arguments for the function are as follows: - node: the namehash of the fully-qualified domain in ENS for which to set the records. Namehashes are defined in [ERC-137](/EIPS/eip-137) - data: 1 or more DNS records in DNS wire format. Any record that is supplied without a value will be cleared. Note that all records in the same RRset should be contiguous within the data; if not then the later RRsets will overwrite the earlier one(s) ### clearDNSZone(bytes32 node) `clearDNSZone()` removes all DNS records for the domain. It has function signature `0xad5780af`. Although it is possible to clear records individually with `setDNSRecords()` as described above this requires the owner to know all of the records that have been set (as the resolver has no methods to iterate over the records for a given domain), and might require multiple transactions. `clearDNSZone()` removes all zone information in a single operation. The arguments for the function is as follows: - node: the namehash of the fully-qualified domain in ENS for which to clear the records. Namehashes are defined in [ERC-137](/EIPS/eip-137) ### dnsRecords(bytes32 node, bytes32 name, uint16 resource) view returns (bytes) `dnsRecords()` obtains the DNS records for a given node, name and resource. It has function signature `0x2461e851`. The arguments for the function are as follows: - node: the namehash of the fully-qualified domain in ENS for which to set the records. Namehashes are defined in [ERC-137](/EIPS/eip-137) - name: the `keccak256()` hash of the name of the record in DNS wire format. - resource: the resource record ID. Resource record IDs are defined in RFC1035 and subsequent RFCs. The function returns all matching records in DNS wire format. If there are no records present the function will return nothing. ### hasDNSRecords(bytes32 node, bytes32 name) view returns (bool) `hasDNSRecords()` reports if there are any records for the provided name in the domain. It has function signature `0x4cbf6ba4`. This function is needed by DNS resolvers when working with wildcard resources as defined in RFC4592. The arguments for the function are as follows: - node: the namehash of the fully-qualified domain in ENS for which to set the records. Namehashes are defined in [ERC-137](/EIPS/eip-137) - name: the `keccak256()` hash of the name of the record in DNS wire format. The function returns `true` if there are any records for the provided node and name, otherwise `false`. ## Rationale DNS is a federated system of naming, and the higher-level entities control availability of everything beneath them (_e.g._ `.org` controls the availability of `ethereum.org`). A decentralized version of DNS would not have this constraint, and allow lookups directly for any domain with relevant records within ENS. ## Backwards Compatibility Not applicable. ## Reference Implementation The reference implementation of the DNS resolver is as follows: ```solidity pragma solidity ^0.7.4; import "../ResolverBase.sol"; import "@ensdomains/dnssec-oracle/contracts/RRUtils.sol"; abstract contract DNSResolver is ResolverBase { using RRUtils for *; using BytesUtils for bytes; bytes4 constant private DNS_RECORD_INTERFACE_ID = 0xa8fa5682; bytes4 constant private DNS_ZONE_INTERFACE_ID = 0x5c47637c; // DNSRecordChanged is emitted whenever a given node/name/resource's RRSET is updated. event DNSRecordChanged(bytes32 indexed node, bytes name, uint16 resource, bytes record); // DNSRecordDeleted is emitted whenever a given node/name/resource's RRSET is deleted. event DNSRecordDeleted(bytes32 indexed node, bytes name, uint16 resource); // DNSZoneCleared is emitted whenever a given node's zone information is cleared. event DNSZoneCleared(bytes32 indexed node); // DNSZonehashChanged is emitted whenever a given node's zone hash is updated. event DNSZonehashChanged(bytes32 indexed node, bytes lastzonehash, bytes zonehash); // Zone hashes for the domains. // A zone hash is an ERC-1577 content hash in binary format that should point to a // resource containing a single zonefile. // node => contenthash mapping(bytes32=>bytes) private zonehashes; // Version the mapping for each zone. This allows users who have lost // track of their entries to effectively delete an entire zone by bumping // the version number. // node => version mapping(bytes32=>uint256) private versions; // The records themselves. Stored as binary RRSETs // node => version => name => resource => data mapping(bytes32=>mapping(uint256=>mapping(bytes32=>mapping(uint16=>bytes)))) private records; // Count of number of entries for a given name. Required for DNS resolvers // when resolving wildcards. // node => version => name => number of records mapping(bytes32=>mapping(uint256=>mapping(bytes32=>uint16))) private nameEntriesCount; /** * Set one or more DNS records. Records are supplied in wire-format. * Records with the same node/name/resource must be supplied one after the * other to ensure the data is updated correctly. For example, if the data * was supplied: * a.example.com IN A 1.2.3.4 * a.example.com IN A 5.6.7.8 * www.example.com IN CNAME a.example.com. * then this would store the two A records for a.example.com correctly as a * single RRSET, however if the data was supplied: * a.example.com IN A 1.2.3.4 * www.example.com IN CNAME a.example.com. * a.example.com IN A 5.6.7.8 * then this would store the first A record, the CNAME, then the second A * record which would overwrite the first. * * @param node the namehash of the node for which to set the records * @param data the DNS wire format records to set */ function setDNSRecords(bytes32 node, bytes calldata data) external authorised(node) { uint16 resource = 0; uint256 offset = 0; bytes memory name; bytes memory value; bytes32 nameHash; // Iterate over the data to add the resource records for (RRUtils.RRIterator memory iter = data.iterateRRs(0); !iter.done(); iter.next()) { if (resource == 0) { resource = iter.dnstype; name = iter.name(); nameHash = keccak256(abi.encodePacked(name)); value = bytes(iter.rdata()); } else { bytes memory newName = iter.name(); if (resource != iter.dnstype || !name.equals(newName)) { setDNSRRSet(node, name, resource, data, offset, iter.offset - offset, value.length == 0); resource = iter.dnstype; offset = iter.offset; name = newName; nameHash = keccak256(name); value = bytes(iter.rdata()); } } } if (name.length > 0) { setDNSRRSet(node, name, resource, data, offset, data.length - offset, value.length == 0); } } /** * Obtain a DNS record. * @param node the namehash of the node for which to fetch the record * @param name the keccak-256 hash of the fully-qualified name for which to fetch the record * @param resource the ID of the resource as per https://en.wikipedia.org/wiki/List_of_DNS_record_types * @return the DNS record in wire format if present, otherwise empty */ function dnsRecord(bytes32 node, bytes32 name, uint16 resource) public view returns (bytes memory) { return records[node][versions[node]][name][resource]; } /** * Check if a given node has records. * @param node the namehash of the node for which to check the records * @param name the namehash of the node for which to check the records */ function hasDNSRecords(bytes32 node, bytes32 name) public view returns (bool) { return (nameEntriesCount[node][versions[node]][name] != 0); } /** * Clear all information for a DNS zone. * @param node the namehash of the node for which to clear the zone */ function clearDNSZone(bytes32 node) public authorised(node) { versions[node]++; emit DNSZoneCleared(node); } /** * setZonehash sets the hash for the zone. * May only be called by the owner of that node in the ENS registry. * @param node The node to update. * @param hash The zonehash to set */ function setZonehash(bytes32 node, bytes calldata hash) external authorised(node) { bytes memory oldhash = zonehashes[node]; zonehashes[node] = hash; emit DNSZonehashChanged(node, oldhash, hash); } /** * zonehash obtains the hash for the zone. * @param node The ENS node to query. * @return The associated contenthash. */ function zonehash(bytes32 node) external view returns (bytes memory) { return zonehashes[node]; } function supportsInterface(bytes4 interfaceID) virtual override public pure returns(bool) { return interfaceID == DNS_RECORD_INTERFACE_ID || interfaceID == DNS_ZONE_INTERFACE_ID || super.supportsInterface(interfaceID); } function setDNSRRSet( bytes32 node, bytes memory name, uint16 resource, bytes memory data, uint256 offset, uint256 size, bool deleteRecord) private { uint256 version = versions[node]; bytes32 nameHash = keccak256(name); bytes memory rrData = data.substring(offset, size); if (deleteRecord) { if (records[node][version][nameHash][resource].length != 0) { nameEntriesCount[node][version][nameHash]--; } delete(records[node][version][nameHash][resource]); emit DNSRecordDeleted(node, name, resource); } else { if (records[node][version][nameHash][resource].length == 0) { nameEntriesCount[node][version][nameHash]++; } records[node][version][nameHash][resource] = rrData; emit DNSRecordChanged(node, name, resource, rrData); } } } ``` ## Security Considerations Security of this solution would be dependent on security of the records within the ENS domain. This degenenrates to the security of the key(s) which have authority over that domain. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 26 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1185 https://eips.ethereum.org/EIPS/eip-1185 RPC-Method to get Merkle Proofs - eth_getProof Standards Track/Interface https://github.com/ethereum/EIPs/issues/1186 ## Simple Summary One of the great features of Ethereum is the fact, that you can verify all data of the state. But in order to allow verification of accounts outside the client, we need an additional function delivering us the required proof. These proofs are important to secure Layer2-Technologies. ## Abstract Ethereum uses a [Merkle Tree](https://github.com/ethereum/eth-wiki/blob/master/fundamentals/patricia-tree.md) to store the state of accounts and their storage. This allows verification of each value by simply creating a Merkle Proof. But currently, the standard RPC-Interface does not give you access to these proofs. This EIP suggests an additional RPC-Method, which creates Merkle Proofs for Accounts and Storage Values. Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. This allows especially IOT-Devices or even mobile apps which are not able to run a light client to verify responses from an untrusted source only given a trusted blockhash. ## Motivation In order to create a MerkleProof access to the full state db is required. The current RPC-Methods allow an application to access single values (`eth_getBalance`,`eth_getTransactionCount`,`eth_getStorageAt`,`eth_getCode`), but it is impossible to read the data needed for a MerkleProof through the standard RPC-Interface. (There are implementations using leveldb and accessing the data via filesystems, but this can not be used for production systems since it requires the client to be stopped first - See https://github.com/zmitton/eth-proof) Today MerkleProofs are already used internally. For example, the [Light Client Protocol](https://github.com/zsfelfoldi/go-ethereum/wiki/Light-Ethereum-Subprotocol-%28LES%29#on-demand-data-retrieval) supports a function creating MerkleProof, which is used in order to verify the requested account or storage-data. Offering these already existing function through the RPC-Interface as well would enable Applications to store and send these proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. This could be used to verify data in mobile applications or IOT-devices, which are currently only using a remote client. ## Specification As Part of the eth-Module, an additional Method called `eth_getProof` should be defined as follows: #### eth_getProof Returns the account- and storage-values of the specified account including the Merkle-proof. ##### Parameters 1. `DATA`, 20 Bytes - address of the account. 2. `ARRAY`, 32 Bytes - array of storage-keys which should be proofed and included. See [`eth_getStorageAt`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getstorageat) 3. `QUANTITY|TAG` - integer block number, or the string `"latest"` or `"earliest"`, see the [default block parameter](https://github.com/ethereum/wiki/wiki/JSON-RPC#the-default-block-parameter) ##### Returns `Object` - A account object: - `balance`: `QUANTITY` - the balance of the account. See [`eth_getBalance`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getbalance) - `codeHash`: `DATA`, 32 Bytes - hash of the code of the account. For a simple Account without code it will return `"0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"` - `nonce`: `QUANTITY`, - nonce of the account. See [`eth_getTransactionCount`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactioncount) - `storageHash`: `DATA`, 32 Bytes - SHA3 of the StorageRoot. All storage will deliver a MerkleProof starting with this rootHash. - `accountProof`: `ARRAY` - Array of rlp-serialized MerkleTree-Nodes, starting with the stateRoot-Node, following the path of the SHA3 (address) as key. - `storageProof`: `ARRAY` - Array of storage-entries as requested. Each entry is an object with these properties: - `key`: `QUANTITY` - the requested storage key - `value`: `QUANTITY` - the storage value - `proof`: `ARRAY` - Array of rlp-serialized MerkleTree-Nodes, starting with the storageHash-Node, following the path of the SHA3 (key) as path. ##### Example ```json { "id": 1, "jsonrpc": "2.0", "method": "eth_getProof", "params": [ "0x7F0d15C7FAae65896648C8273B6d7E43f58Fa842", [ "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421" ], "latest" ] } ``` The result will look like this: ```json { "id": 1, "jsonrpc": "2.0", "result": { "accountProof": [ "0xf90211a...0701bc80", "0xf90211a...0d832380", "0xf90211a...5fb20c80", "0xf90211a...0675b80", "0xf90151a0...ca08080" ], "balance": "0x0", "codeHash": "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470", "nonce": "0x0", "storageHash": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "storageProof": [ { "key": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "proof": [ "0xf90211a...0701bc80", "0xf90211a...0d832380" ], "value": "0x1" } ] } } ``` ## Rationale This one Method actually returns 3 different important data points: 1. The 4 fields of an account-object as specified in the yellow paper `[nonce, balance, storageHash, codeHash ]`, which allows storing a hash of the account-object in order to keep track of changes. 2. The MerkleProof for the account starting with a stateRoot from the specified block. 3. The MerkleProof for each requested storage entry starting with a storageHash from the account. Combining these in one Method allows the client to work very efficient since the required data are already fetched from the db. ### Proofs for non existent values In case an address or storage-value does not exist, the proof needs to provide enough data to verify this fact. This means the client needs to follow the path from the root node and deliver until the last matching node. If the last matching node is a branch, the proof value in the node must be an empty one. In case of leaf-type, it must be pointing to a different relative-path in order to proof that the requested path does not exist. ### possible Changes to be discussed: - instead of providing the blocknumber maybe the blockhash would be better since it would allow proofs of uncles-states. - in order to reduce data, the account-object may only provide the `accountProof` and `storageProof`. The Fields `balance`, `nonce`, `storageHash` and `codeHash` could be taken from the last Node in the proof by deserializing it. ## Backwards Compatibility Since this only adds a new Method there are no issues with Backwards Compatibility. ## Test Cases TODO: Tests still need to be implemented, but the core function creating the proof already exists inside the clients and are well tested. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 24 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1186 https://eips.ethereum.org/EIPS/eip-1186 Add chain id to mixed-case checksum address encoding Standards Track/ERC https://github.com/ethereum/EIPs/issues/1121 ## Simple Summary This EIP extends [EIP-55](/EIPS/eip-55) by optionally adding a chain id defined by [EIP-155](/EIPS/eip-155) to the checksum calculation. ## Abstract The [EIP-55](/EIPS/eip-55) was created to prevent users from losing funds by sending them to invalid addresses. This EIP extends [EIP-55](/EIPS/eip-55) to protect users from losing funds by sending them to addresses that are valid but that where obtained from a client of another network.For example, if this EIP is implemented, a wallet can alert the user that is trying to send funds to an Ethereum Testnet address from an Ethereum Mainnet wallet. ## Motivation The motivation of this proposal is to provide a mechanism to allow software to distinguish addresses from different Ethereum based networks. This proposal is necessary because Ethereum addresses are hashes of public keys and do not include any metadata. By extending the [EIP-55](/EIPS/eip-55) checksum algorithm it is possible to achieve this objective. ## Specification Convert the address using the same algorithm defined by [EIP-55](/EIPS/eip-55) but if a registered chain id is provided, add it to the input of the hash function. If the chain id passed to the function belongs to a network that opted for using this checksum variant, prefix the address with the chain id and the `0x` separator before calculating the hash. Then convert the address to hexadecimal, but if the ith digit is a letter (ie. it's one of `abcdef`) print it in uppercase if the 4*ith bit of the calculated hash is 1 otherwise print it in lowercase. ## Rationale Benefits: - By means of a minimal code change on existing libraries, users are protected from losing funds by mixing addresses of different Ethereum based networks. ## Implementation ```python #!/usr/bin/python3 from sha3 import keccak_256 import random """ addr (str): Hexadecimal address, 40 characters long with 2 characters prefix chainid (int): chain id from EIP-155 """ def eth_checksum_encode(addr, chainid=1): adopted_eip1191 = [30, 31] hash_input = str(chainid) + addr.lower() if chainid in adopted_eip1191 else addr[2:].lower() hash_output = keccak_256(hash_input.encode('utf8')).hexdigest() aggregate = zip(addr[2:].lower(),hash_output) out = addr[:2] + ''.join([c.upper() if int(a,16) >= 8 else c for c,a in aggregate]) return out ``` ## Test Cases ```python eth_mainnet = [ "0x27b1fdb04752bbc536007a920d24acb045561c26", "0x3599689E6292b81B2d85451025146515070129Bb", "0x42712D45473476b98452f434e72461577D686318", "0x52908400098527886E0F7030069857D2E4169EE7", "0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed", "0x6549f4939460DE12611948b3f82b88C3C8975323", "0x66f9664f97F2b50F62D13eA064982f936dE76657", "0x8617E340B3D01FA5F11F306F4090FD50E238070D", "0x88021160C5C792225E4E5452585947470010289D", "0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb", "0xdbF03B407c01E7cD3CBea99509d93f8DDDC8C6FB", "0xde709f2102306220921060314715629080e2fb77", "0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359", ] rsk_mainnet = [ "0x27b1FdB04752BBc536007A920D24ACB045561c26", "0x3599689E6292B81B2D85451025146515070129Bb", "0x42712D45473476B98452f434E72461577d686318", "0x52908400098527886E0F7030069857D2E4169ee7", "0x5aaEB6053f3e94c9b9a09f33669435E7ef1bEAeD", "0x6549F4939460DE12611948B3F82B88C3C8975323", "0x66F9664f97f2B50F62d13EA064982F936de76657", "0x8617E340b3D01Fa5f11f306f4090fd50E238070D", "0x88021160c5C792225E4E5452585947470010289d", "0xD1220A0Cf47c7B9BE7a2e6ba89F429762E7B9adB", "0xDBF03B407c01E7CD3cBea99509D93F8Dddc8C6FB", "0xDe709F2102306220921060314715629080e2FB77", "0xFb6916095cA1Df60bb79ce92cE3EA74c37c5d359", ] rsk_testnet = [ "0x27B1FdB04752BbC536007a920D24acB045561C26", "0x3599689e6292b81b2D85451025146515070129Bb", "0x42712D45473476B98452F434E72461577D686318", "0x52908400098527886E0F7030069857D2e4169EE7", "0x5aAeb6053F3e94c9b9A09F33669435E7EF1BEaEd", "0x6549f4939460dE12611948b3f82b88C3c8975323", "0x66f9664F97F2b50f62d13eA064982F936DE76657", "0x8617e340b3D01fa5F11f306F4090Fd50e238070d", "0x88021160c5C792225E4E5452585947470010289d", "0xd1220a0CF47c7B9Be7A2E6Ba89f429762E7b9adB", "0xdbF03B407C01E7cd3cbEa99509D93f8dDDc8C6fB", "0xDE709F2102306220921060314715629080e2Fb77", "0xFb6916095CA1dF60bb79CE92ce3Ea74C37c5D359", ] test_cases = {30 : rsk_mainnet, 31 : rsk_testnet, 1 : eth_mainnet} for chainid, cases in test_cases.items(): for addr in cases: assert ( addr == eth_checksum_encode(addr,chainid) ) ``` ## Usage ### Usage Table | Network | Chain id | Supports this EIP | |-|-|-| | RSK Mainnet | 30 | Yes | | RSK Testnet | 31 | Yes | ### Implementation Table | Project | EIP Usage | Implementation | |-|-|-| | MyCrypto | Yes | [JavaScript](https://github.com/MyCryptoHQ/MyCrypto/blob/develop/common/utils/formatters.ts#L126) | | MyEtherWallet | Yes | [JavaScript](https://github.com/MyEtherWallet/MyEtherWallet/blob/73c4a24f8f67c655749ac990c5b62efd92a2b11a/src/helpers/addressUtils.js#L22) | | Ledger | Yes | [C](https://github.com/LedgerHQ/ledger-app-eth/blob/master/src_common/ethUtils.c#L203) | | Trezor | Yes | [Python](https://github.com/trezor/trezor-core/blob/270bf732121d004a4cd1ab129adaccf7346ff1db/src/apps/ethereum/get_address.py#L32) and [C](https://github.com/trezor/trezor-crypto/blob/4153e662b60a0d83c1be15150f18483a37e9092c/address.c#L62) | | Web3.js | Yes | [JavaScript](https://github.com/ethereum/web3.js/blob/aaf26c8806bc9fb60cf6dcb6658104963c6c7fc7/packages/web3-utils/src/Utils.js#L140) | | EthereumJS-util | Yes | [JavaScript](https://github.com/ethereumjs/ethereumjs-util/pull/204/commits/cdf0b3c996b05ac5b1f758f17ea9f9ed1847c1eb) | | ENS address-encoder | Yes | [TypeScript](https://github.com/ensdomains/address-encoder/commit/5bf53b13fa014646ea28c9e5f937361dc9b40590) | ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 18 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1191 https://eips.ethereum.org/EIPS/eip-1191 Ethereum Provider JavaScript API Standards Track/Interface https://github.com/ethereum/EIPs/issues/2319 ## Summary A JavaScript Ethereum Provider API for consistency across clients and applications. ## Abstract A common convention in the Ethereum web application ("dapp") ecosystem is for key management software ("wallets") to expose their API via a JavaScript object in the web page. This object is called "the Provider". Historically, Provider implementations have exhibited conflicting interfaces and behaviors between wallets. This EIP formalizes an Ethereum Provider API to promote wallet interoperability. The API is designed to be minimal, event-driven, and agnostic of transport and RPC protocols. Its functionality is easily extended by defining new RPC methods and `message` event types. Historically, Providers have been made available as `window.ethereum` in web browsers, but this convention is not part of the specification. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119](https://www.ietf.org/rfc/rfc2119.txt). > Comments like this are non-normative. ### Definitions _This section is non-normative._ - Provider - A JavaScript object made available to a consumer, that provides access to Ethereum by means of a Client. - Client - An endpoint that receives Remote Procedure Call (RPC) requests from the Provider, and returns their results. - Wallet - An end-user application that manages private keys, performs signing operations, and acts as a middleware between the Provider and the Client. - Remote Procedure Call (RPC) - A Remote Procedure Call (RPC), is any request submitted to a Provider for some procedure that is to be processed by a Provider, its Wallet, or its Client. ### Connectivity The Provider is said to be "connected" when it can service RPC requests to at least one chain. The Provider is said to be "disconnected" when it cannot service RPC requests to any chain at all. > To service an RPC request, the Provider must successfully submit the request to the remote location, and receive a response. > In other words, if the Provider is unable to communicate with its Client, for example due to network issues, the Provider is disconnected. ### API > The Provider API is specified using TypeScript. > The authors encourage implementers to declare their own types and interfaces, using the ones in this section as a basis. > > For consumer-facing API documentation, see [Appendix I](#appendix-i-consumer-facing-api-documentation) The Provider **MUST** implement and expose the API defined in this section. All API entities **MUST** adhere to the types and interfaces defined in this section. #### request > The `request` method is intended as a transport- and protocol-agnostic wrapper function for Remote Procedure Calls (RPCs). ```typescript interface RequestArguments { readonly method: string; readonly params?: readonly unknown[] | object; } Provider.request(args: RequestArguments): Promise<unknown>; ``` The Provider **MUST** identify the requested RPC method by the value of `RequestArguments.method`. If the requested RPC method takes any parameters, the Provider **MUST** accept them as the value of `RequestArguments.params`. RPC requests **MUST** be handled such that the returned Promise either resolves with a value per the requested RPC method's specification, or rejects with an error. If resolved, the Promise **MUST** resolve with a result per the RPC method's specification. The Promise **MUST NOT** resolve with any RPC protocol-specific response objects, unless the RPC method's return type is so defined. If the returned Promise rejects, it **MUST** reject with a `ProviderRpcError` as specified in the [RPC Errors](#rpc-errors) section below. The returned Promise **MUST** reject if any of the following conditions are met: - An error is returned for the RPC request. - If the returned error is compatible with the `ProviderRpcError` interface, the Promise **MAY** reject with that error directly. - The Provider encounters an error or fails to process the request for any reason. > If the Provider implements any kind of authorization logic, the authors recommend rejecting with a `4100` error in case of authorization failures. The returned Promise **SHOULD** reject if any of the following conditions are met: - The Provider is disconnected. - If rejecting for this reason, the Promise rejection error `code` **MUST** be `4900`. - The RPC request is directed at a specific chain, and the Provider is not connected to that chain, but is connected to at least one other chain. - If rejecting for this reason, the Promise rejection error `code` **MUST** be `4901`. See the section [Connectivity](#connectivity) for the definitions of "connected" and "disconnected". ### Supported RPC Methods A "supported RPC method" is any RPC method that may be called via the Provider. All supported RPC methods **MUST** be identified by unique strings. Providers **MAY** support whatever RPC methods required to fulfill their purpose, standardized or otherwise. If an RPC method defined in a finalized EIP is not supported, it **SHOULD** be rejected with a `4200` error per the [Provider Errors](#provider-errors) section below, or an appropriate error per the RPC method's specification. #### RPC Errors ```typescript interface ProviderRpcError extends Error { code: number; data?: unknown; } ``` - `message` - **MUST** be a human-readable string - **SHOULD** adhere to the specifications in the [Error Standards](#error-standards) section below - `code` - **MUST** be an integer number - **SHOULD** adhere to the specifications in the [Error Standards](#error-standards) section below - `data` - **SHOULD** contain any other useful information about the error ##### Error Standards `ProviderRpcError` codes and messages **SHOULD** follow these conventions, in order of priority: 1. The errors in the [Provider Errors](#provider-errors) section below 2. Any errors mandated by the erroring RPC method's specification 3. The [`CloseEvent` status codes](https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes) #### Provider Errors | Status code | Name | Description | | ----------- | --------------------- | ------------------------------------------------------------------------ | | 4001 | User Rejected Request | The user rejected the request. | | 4100 | Unauthorized | The requested method and/or account has not been authorized by the user. | | 4200 | Unsupported Method | The Provider does not support the requested method. | | 4900 | Disconnected | The Provider is disconnected from all chains. | | 4901 | Chain Disconnected | The Provider is not connected to the requested chain. | > `4900` is intended to indicate that the Provider is disconnected from all chains, while `4901` is intended to indicate that the Provider is disconnected from a specific chain only. > In other words, `4901` implies that the Provider is connected to other chains, just not the requested one. ### Events The Provider **MUST** implement the following event handling methods: - `on` - `removeListener` These methods **MUST** be implemented per the Node.js [`EventEmitter` API](https://nodejs.org/api/events.html). > To satisfy these requirements, Provider implementers should consider simply extending the Node.js `EventEmitter` class and bundling it for the target environment. #### message > The `message` event is intended for arbitrary notifications not covered by other events. When emitted, the `message` event **MUST** be emitted with an object argument of the following form: ```typescript interface ProviderMessage { readonly type: string; readonly data: unknown; } ``` ##### Subscriptions If the Provider supports Ethereum RPC subscriptions, e.g. [`eth_subscribe`](https://geth.ethereum.org/docs/rpc/pubsub), the Provider **MUST** emit the `message` event when it receives a subscription notification. If the Provider receives a subscription message from e.g. an `eth_subscribe` subscription, the Provider **MUST** emit a `message` event with a `ProviderMessage` object of the following form: ```typescript interface EthSubscription extends ProviderMessage { readonly type: 'eth_subscription'; readonly data: { readonly subscription: string; readonly result: unknown; }; } ``` #### connect See the section [Connectivity](#connectivity) for the definition of "connected". If the Provider becomes connected, the Provider **MUST** emit the event named `connect`. This includes when: - The Provider first connects to a chain after initialization. - The Provider connects to a chain after the `disconnect` event was emitted. This event **MUST** be emitted with an object of the following form: ```typescript interface ProviderConnectInfo { readonly chainId: string; } ``` `chainId` **MUST** specify the integer ID of the connected chain as a hexadecimal string, per the [`eth_chainId`](/EIPS/eip-695) Ethereum RPC method. #### disconnect See the section [Connectivity](#connectivity) for the definition of "disconnected". If the Provider becomes disconnected from all chains, the Provider **MUST** emit the event named `disconnect` with value `error: ProviderRpcError`, per the interfaced defined in the [RPC Errors](#rpc-errors) section. The value of the error's `code` property **MUST** follow the [status codes for `CloseEvent`](https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes). #### chainChanged If the chain the Provider is connected to changes, the Provider **MUST** emit the event named `chainChanged` with value `chainId: string`, specifying the integer ID of the new chain as a hexadecimal string, per the [`eth_chainId`](/EIPS/eip-695) Ethereum RPC method. #### accountsChanged If the accounts available to the Provider change, the Provider **MUST** emit the event named `accountsChanged` with value `accounts: string[]`, containing the account addresses per the `eth_accounts` Ethereum RPC method. The "accounts available to the Provider" change when the return value of `eth_accounts` changes. ## Rationale The purpose of a Provider is to _provide_ a consumer with access to Ethereum. In general, a Provider must enable an Ethereum web application to do two things: - Make Ethereum RPC requests - Respond to state changes in the Provider's Ethereum chain, Client, and Wallet The Provider API specification consists of a single method and five events. The `request` method and the `message` event alone, are sufficient to implement a complete Provider. They are designed to make arbitrary RPC requests and communicate arbitrary messages, respectively. The remaining four events can be separated into two categories: - Changes to the Provider's ability to make RPC requests - `connect` - `disconnect` - Common Client and/or Wallet state changes that any non-trivial application must handle - `chainChanged` - `accountsChanged` These events are included due to the widespread production usage of related patterns, at the time of writing. ## Backwards Compatibility Many Providers adopted a draft version of this specification before it was finalized. The current API is designed to be a strict superset of the legacy version, and this specification is in that sense fully backwards compatible. See [Appendix III](#appendix-iii-legacy-provider-api) for the legacy API. Providers that only implement this specification will not be compatible with Ethereum web applications that target the legacy API. ## Implementations At the time of writing, the following projects have working implementations: - [buidler.dev](https://github.com/nomiclabs/buidler/pull/608) - [ethers.js](https://github.com/ethers-io/ethers.js/blob/56af4413b1dd1787db68985e0b612b63d86fdf7c/packages/providers/src.ts/web3-provider.ts) - [eth-provider](https://www.npmjs.com/package/eth-provider) - [MetaMask](https://github.com/MetaMask/inpage-provider) - [WalletConnect](https://github.com/WalletConnect/walletconnect-monorepo/blob/d33fd2070d7a67f74de50fd10ca4217f4e2f22f3/packages/providers/web3-provider/README.md) - [web3.js](https://web3js.readthedocs.io/) ## Security Considerations The Provider is intended to pass messages between an Ethereum Client and an Ethereum application. It is _not_ responsible for private key or account management; it merely processes RPC messages and emits events. Consequently, account security and user privacy need to be implemented in middlewares between the Provider and its Ethereum Client. In practice, we call these middleware applications "Wallets," and they usually manage the user's private keys and accounts. The Provider can be thought of as an extension of the Wallet, exposed in an untrusted environment, under the control of some third party (e.g. a website). ### Handling Adversarial Behavior Since it is a JavaScript object, consumers can generally perform arbitrary operations on the Provider, and all its properties can be read or overwritten. Therefore, it is best to treat the Provider object as though it is controlled by an adversary. It is paramount that the Provider implementer protects the user, Wallet, and Client by ensuring that: - The Provider does not contain any private user data. - The Provider and Wallet programs are isolated from each other. - The Wallet and/or Client rate-limit requests from the Provider. - The Wallet and/or Client validate all data sent from the Provider. ### Chain Changes Since all Ethereum operations are directed at a particular chain, it's important that the Provider accurately reflects the Client's configured chain, per the `eth_chainId` Ethereum RPC method (see [EIP-695](/EIPS/eip-695)). This includes ensuring that `eth_chainId` has the correct return value, and that the `chainChanged` event is emitted whenever that value changes. ### User Account Exposure and Account Changes Many Ethereum write operations (e.g. `eth_sendTransaction`) require a user account to be specified. Provider consumers access these accounts via the `eth_accounts` RPC method, and by listening for the `accountsChanged` event. As with `eth_chainId`, it is critical that `eth_accounts` has the correct return value, and that the `accountsChanged` event is emitted whenever that value changes. The return value of `eth_accounts` is ultimately controlled by the Wallet or Client. In order to protect user privacy, the authors recommend not exposing any accounts by default. Instead, Providers should support RPC methods for explicitly requesting account access, such as `eth_requestAccounts` (see [EIP-1102](/EIPS/eip-1102)) or `wallet_requestPermissions` (see [EIP-2255](/EIPS/eip-2255)). ## References - [Initial discussion in `ethereum/interfaces`](https://github.com/ethereum/interfaces/issues/16) - [Deprecated Ethereum Magicians thread](https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640) - [Continuing discussion](https://github.com/ethereum/EIPs/issues/2319) - Related EIPs - [EIP-1102: Opt-in Account Exposure](/EIPS/eip-1102) - [EIP-1474: Remote Procedure Call Specification](/EIPS/eip-1474) - [EIP-1767: GraphQL Interface to Ethereum Node Data](/EIPS/eip-1767) - [EIP-2255: Wallet Permissions](/EIPS/eip-2255) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). ## Appendix I: Consumer-Facing API Documentation ### request Makes an Ethereum RPC method call. ```typescript interface RequestArguments { readonly method: string; readonly params?: readonly unknown[] | object; } Provider.request(args: RequestArguments): Promise<unknown>; ``` The returned Promise resolves with the method's result or rejects with a [`ProviderRpcError`](#errors). For example: ```javascript Provider.request({ method: 'eth_accounts' }) .then((accounts) => console.log(accounts)) .catch((error) => console.error(error)); ``` Consult each Ethereum RPC method's documentation for its `params` and return type. You can find a list of common methods [here](/EIPS/eip-1474). #### RPC Protocols Multiple RPC protocols may be available. For examples, see: - [EIP-1474](/EIPS/eip-1474), the Ethereum JSON-RPC API - [EIP-1767](/EIPS/eip-1767), the Ethereum GraphQL schema ### Events Events follow the conventions of the Node.js [`EventEmitter` API](https://nodejs.org/api/events.html). #### connect The Provider emits `connect` when it: - first connects to a chain after being initialized. - first connects to a chain, after the `disconnect` event was emitted. ```typescript interface ProviderConnectInfo { readonly chainId: string; } Provider.on('connect', listener: (connectInfo: ProviderConnectInfo) => void): Provider; ``` The event emits an object with a hexadecimal string `chainId` per the `eth_chainId` Ethereum RPC method, and other properties as determined by the Provider. #### disconnect The Provider emits `disconnect` when it becomes disconnected from all chains. ```typescript Provider.on('disconnect', listener: (error: ProviderRpcError) => void): Provider; ``` This event emits a [`ProviderRpcError`](#errors). The error `code` follows the table of [`CloseEvent` status codes](https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes). #### chainChanged The Provider emits `chainChanged` when connecting to a new chain. ```typescript Provider.on('chainChanged', listener: (chainId: string) => void): Provider; ``` The event emits a hexadecimal string `chainId` per the `eth_chainId` Ethereum RPC method. #### accountsChanged The Provider emits `accountsChanged` if the accounts returned from the Provider (`eth_accounts`) change. ```typescript Provider.on('accountsChanged', listener: (accounts: string[]) => void): Provider; ``` The event emits with `accounts`, an array of account addresses, per the `eth_accounts` Ethereum RPC method. #### message The Provider emits `message` to communicate arbitrary messages to the consumer. Messages may include JSON-RPC notifications, GraphQL subscriptions, and/or any other event as defined by the Provider. ```typescript interface ProviderMessage { readonly type: string; readonly data: unknown; } Provider.on('message', listener: (message: ProviderMessage) => void): Provider; ``` ##### Subscriptions [`eth_` subscription methods](https://geth.ethereum.org/docs/rpc/pubsub) and [`shh_` subscription methods](https://github.com/ethereum/go-ethereum/wiki/Whisper-v6-RPC-API#shh_subscribe) rely on this event to emit subscription updates. For e.g. `eth_subscribe` subscription updates, `ProviderMessage.type` will equal the string `'eth_subscription'`, and the subscription data will be the value of `ProviderMessage.data`. ### Errors ```typescript interface ProviderRpcError extends Error { message: string; code: number; data?: unknown; } ``` ## Appendix II: Examples These examples assume a web browser environment. ```javascript // Most Providers are available as window.ethereum on page load. // This is only a convention, not a standard, and may not be the case in practice. // Please consult the Provider implementation's documentation. const ethereum = window.ethereum; // Example 1: Log chainId ethereum .request({ method: 'eth_chainId' }) .then((chainId) => { console.log(`hexadecimal string: ${chainId}`); console.log(`decimal number: ${parseInt(chainId, 16)}`); }) .catch((error) => { console.error(`Error fetching chainId: ${error.code}: ${error.message}`); }); // Example 2: Log last block ethereum .request({ method: 'eth_getBlockByNumber', params: ['latest', true], }) .then((block) => { console.log(`Block ${block.number}:`, block); }) .catch((error) => { console.error( `Error fetching last block: ${error.message}. Code: ${error.code}. Data: ${error.data}` ); }); // Example 3: Log available accounts ethereum .request({ method: 'eth_accounts' }) .then((accounts) => { console.log(`Accounts:\n${accounts.join('\n')}`); }) .catch((error) => { console.error( `Error fetching accounts: ${error.message}. Code: ${error.code}. Data: ${error.data}` ); }); // Example 4: Log new blocks ethereum .request({ method: 'eth_subscribe', params: ['newHeads'], }) .then((subscriptionId) => { ethereum.on('message', (message) => { if (message.type === 'eth_subscription') { const { data } = message; if (data.subscription === subscriptionId) { if ('result' in data && typeof data.result === 'object') { const block = data.result; console.log(`New block ${block.number}:`, block); } else { console.error(`Something went wrong: ${data.result}`); } } } }); }) .catch((error) => { console.error( `Error making newHeads subscription: ${error.message}. Code: ${error.code}. Data: ${error.data}` ); }); // Example 5: Log when accounts change const logAccounts = (accounts) => { console.log(`Accounts:\n${accounts.join('\n')}`); }; ethereum.on('accountsChanged', logAccounts); // to unsubscribe ethereum.removeListener('accountsChanged', logAccounts); // Example 6: Log if connection ends ethereum.on('disconnect', (code, reason) => { console.log(`Ethereum Provider connection closed: ${reason}. Code: ${code}`); }); ``` ## Appendix III: Legacy Provider API This section documents the legacy Provider API, which is extensively used in production at the time of writing. As it was never fully standardized, significant deviations occur in practice. The authors recommend against implementing it except to support legacy Ethereum applications. ### sendAsync (DEPRECATED) This method is superseded by [`request`](#request). `sendAsync` is like `request`, but with JSON-RPC objects and a callback. ```typescript Provider.sendAsync(request: Object, callback: Function): void; ``` Historically, the request and response object interfaces have followed the [Ethereum JSON-RPC specification](/EIPS/eip-1474). ### send (DEPRECATED) This method is superseded by [`request`](#request). ```typescript Provider.send(...args: unknown[]): unknown; ``` ### Legacy Events #### close (DEPRECATED) This event is superseded by [`disconnect`](#disconnect). #### networkChanged (DEPRECATED) The event `networkChanged` is superseded by [`chainChanged`](#chainchanged). For details, see [EIP-155: Simple replay attack protection](/EIPS/eip-155) and [EIP-695: Create eth_chainId method for JSON-RPC](/EIPS/eip-695). #### notification (DEPRECATED) This event is superseded by [`message`](#message). Historically, this event has been emitted with e.g. `eth_subscribe` subscription updates of the form `{ subscription: string, result: unknown }`. Sat, 30 Jun 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1193 https://eips.ethereum.org/EIPS/eip-1193 Voting Interface Standards Track/ERC https://ethereum-magicians.org/t/eip-1202-voting-interface/11484 ## Abstract This EIP defines an API for implementing voting with smart contracts. This standard provides functionality for voting, viewing vote results, and setting voting status. ## Motivation Voting is one of the earliest examples of EVM programming and is also a key part of DAO and organizational governance processes. We expect many DAOs will ultimately need to leverage voting as an important part of their governance. By creating a voting standard for smart contracts and tokens, we can have the following benefits: ### Benefits of having a standard 1. Allow general UIs and applications to be built on top of a standardized voting interface so that more users can participate, and encourage more dApps and DAOs to think about their governance. 2. Allow delegated voting, smart-contract voting, and automatic voting. 3. Allow voting results to be recorded on-chain in a standard way, and allow DAOs and dApps to honor the voting results programmatically. 4. Allow compatibility with token standards such as [ERC-20](/EIPS/eip-20) and newer standards such as [ERC-777](/EIPS/eip-777), as well as item standards such as [ERC-721](/EIPS/eip-721). 5. Create massive potential for interoperability within Ethereum ecosystems and other systems. 6. Allow setting voting deadlines, determining single or multiple options, and requiring voting order. (The trade-off is interface complexity; we might need an [ERC-20](/EIPS/eip-20)-style approach first and later an [ERC-777](/EIPS/eip-777)-style approach for advanced voting.) 7. Record voting weights based on token amounts. 8. Possibly allow trustworthy, privacy-safe voting and anonymous voting (with the voter address not being associated with the vote they cast, given a list of randomized or obfuscated voting options). 9. Possibly allow rewards based on voting participation or voting results. ### Non-Goal / Out of Scope 1. **Delegation**: We intentionally leave delegation out of scope. A separate EIP could be proposed to address this particular use case. 2. **Eligibility or Weights**: Some implementations may want voting weights or voting eligibility to be configurable. For example, OpenZeppelin's implementation of GovernorBravo uses snapshots. Weight calculations such as quadratic voting are also outside the scope of this EIP. This EIP is intended to be flexible enough for current and future voting-weight calculations. 3. **Proposal**: We intentionally leave proposals out of scope. Proposals are identified by `proposalId`, but the information included in a proposal, whether it is on-chain or off-chain, and whether it is executable are all left out of this proposal. A separate EIP could be proposed to address this particular use case. See one such proposal: [ERC-5247](/EIPS/eip-5247). 4. **Signature Aggregations / Endorsement**: When implementing contracts want to allow users to submit their vote or vote approval offline and have another account generate the transaction, signature aggregations or endorsements are outside the scope of this EIP. A separate EIP could be proposed to address this particular use case. See one such proposal here: [ERC-5453](/EIPS/eip-5453). ### Use-cases 1. Decide on issuing a new token, issuing more tokens, or issuing a sub-token. 2. Decide on creating a new item under [ERC-721](/EIPS/eip-721). 3. Decide on electing a certain person or smart contract to be the delegated leader for a project or subproject. 4. Decide on audit-result ownership that allows migration of a smart-contract proxy address. ## Specification 1. Compliant contracts MUST implement the `IERC1202Core` below ```solidity interface IERC1202Core { event VoteCast( address indexed voter, uint256 indexed proposalId, uint8 support, uint256 weight, string reason, bytes extraParams ); function castVote( uint256 proposalId, uint8 support, uint256 weight, string calldata reasonUri, bytes calldata extraParams ) external payable returns; function castVoteFrom( address from, uint256 proposalId, uint8 support, uint256 weight, string calldata reasonUri, bytes calldata extraParams ) external payable returns; function execute(uint256 proposalId, bytes memory extraParams) payable external; } ``` 2. Compliant contracts MAY implement the `IERC1202MultiVote` Interface. If the intention is for multi-options to be supported, e.g. for ranked-choices or variant weights voting, Compliant contracts MUST implement `IERC1202MultiVote` Interface. ```solidity interface IERC1202MultiVote { event MultiVoteCast( address indexed voter, uint256 indexed proposalId, uint8[] support, uint256[] weight, string reason, bytes extraParams ); function castMultiVote( uint256 proposalId, uint8[] support, uint256[] weight, string calldata reasonUri, bytes calldata extraParams ) external payable; } ``` 3. The compliant contract SHOULD implement the [ERC-5269](/EIPS/eip-5269) interface. ### Getting Info: Voting Period, Eligibility, Weight ```solidity interface IERC1202Info { function votingPeriodFor(uint256 proposalId) external view returns (uint256 startPointOfTime, uint256 endPointOfTime); function eligibleVotingWeight(uint256 proposalId, address voter) external view returns (uint256); } ``` ## Rationale We made the following design decisions, and here are the rationales. ### Granularity and Anonymity We created a `view` function, `ballotOf`, primarily to make it easier for people to check the vote from a certain address. This has the following assumptions: - It is possible to check someone's vote directly given an address. If implementers do not want to make this so easy, they can simply reject all calls to this function. We want to make sure that we support both anonymous and non-anonymous voting. However, since all calls to a smart contract are logged in block history, there is not much secrecy unless cryptographic techniques are used. I am not sufficiently cryptography-savvy to comment on that possibility. Please see "Second Feedback Questions 2018" for a related topic. - It assumes that each individual address can vote for only one decision. Users can distribute their available voting power at a more granular level. If implementers want to allow this, they can ask the user to create another wallet address and grant that new address a certain amount of power. For example, in token-based voting where voting weight is determined by the amount of tokens held by a voter, a voter who wants to distribute their voting power across two different options (or option sets) can transfer some of the tokens to the new account and cast votes from both accounts. ### Weights We assume votes have `weight`, which can be checked by calling `eligibleVotingWeight(proposalId, address voter)`, and that the weight distribution is either determined internally or set by the constructor. ## Backwards Compatibility 1. The `support` options are chosen to be `uint8` for the purpose of being backward-compatible with GovernorBravo. This can be increased in the future. ## Security Considerations We expect the voting standard to be used in connection with other contracts such as token distributions, actions conducted by consensus or on behalf of an entity, multi-signature wallets, and similar systems. The major security consideration is ensuring that the standard interface is used only for performing downstream actions or receiving upstream input (vote casting). We expect future audit tools to be based on standard interfaces. It is also important to note, as discussed in this standard, that for the sake of simplicity this EIP is kept in a very basic form. It can be extended to support many different implementation variations. Such variations might contain different assumptions about the behavior and interpretation of actions. One example is: what does it mean if someone votes multiple times through `vote`? - Would that mean the voter is increasing their weight? - Would that mean they vote for multiple options in the meantime? - Does the latter vote override the previous vote? Because of the flexible nature of voting, we expect that many subsequent standards will need to be created as extensions of this EIP. We suggest that any extension or implementation of this standard be thoroughly audited before being included in large-scale or high-asset-volume applications. The third consideration is non-triviality. Some voting applications assume **_anonymity_**, **_randomness_**, **_time-based deadline_**, **_ordering_**, etc. These requirements are known to be non-trivial to achieve on Ethereum. We suggest that any applications or organizations rely on audited and time-proven shared libraries when these requirements need to be enforced in their applications. The fourth consideration is potential abuse. When voting is standardized and put on-chain, it is possible to write another contract that rewards a voter for voting in a certain way. This creates potential issues of bribery and conflict-of-interest abuse that were previously hard to implement. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 08 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1202 https://eips.ethereum.org/EIPS/eip-1202 ERC-1203 Multi-Class Token Standard (ERC-20 Extension) Standards Track/ERC https://github.com/ethereum/EIPs/issues/1203 ## Simple Summary A standard interface for multi-class tokens (MCTs). ## Abstract The following standard allows for the implementation of a standard API for MCTs within smart contracts. This standard provides basic functionality to track, transfer, and convert MCTs. ## Motivation This standard is heavily inspired by ERC-20 Token Standard and ERC-721 Non-Fungible Token Standard. However, whereas these standards are chiefly concerned with representation of items/value in a single class, fungible or note, this proposed standard focus on that of a more complexed, multi-class system. It is fair to think of MCTs as a hybrid of fungible tokens (FT) and non-fungible tokens (NFTs), that is tokens are fungible within the same class but non-fungible with that from a different class. And conversions between classes may be optionally supported. MCTs are useful in representing various structures with heterogeneous components, such as: - **Abstract Concepts:** A company may have different classes of stocks (e.g. senior preferred, junior preferred, class A common, class B common) that together make up its outstanding equities. A shareholder's position of such company composites of zero or more shares in each class. - **Virtual Items:** A sandbox computer game may have many types of resources (e.g. rock, wood, berries, cows, meat, knife, etc.) that together make up that virtual world. A player's inventory has any combination and quantity of these resources - **Physical Items:** A supermarket may have many SKUs it has available for purchase (e.g. eggs, milk, beef jerky, beer, etc.). Things get added or removed from a shopper's cart as it moves down the aisle. It's sometimes possible, especially with regard to abstract concepts or virtual items, to convert from one class to another, at a specified conversion ratio. When it comes to physical items, such conversion essentially is the implementation of bartering. Though it might generally be easier to introduce a common intermediary class, i.e. money. ## Specification ```solidity contract ERC20 { function totalSupply() public view returns (uint256); function balanceOf(address _owner) public view returns (uint256); function transfer(address _to, uint256 _value) public returns (bool); function approve(address _spender, uint256 _value) public returns (bool); function allowance(address _owner, address _spender) public view returns (uint256); function transferFrom(address _from, address _to, uint256 _value) public returns (bool); event Transfer(address indexed _from, address indexed _to, uint256 _value); event Approval(address indexed _owner, address indexed _spender, uint256 _value); } contract ERC1203 is ERC20 { function totalSupply(uint256 _class) public view returns (uint256); function balanceOf(address _owner, uint256 _class) public view returns (uint256); function transfer(address _to, uint256 _class, uint256 _value) public returns (bool); function approve(address _spender, uint256 _class, uint256 _value) public returns (bool); function allowance(address _owner, address _spender, uint256 _class) public view returns (uint256); function transferFrom(address _from, address _to, uint256 _class, uint256 _value) public returns (bool); function fullyDilutedTotalSupply() public view returns (uint256); function fullyDilutedBalanceOf(address _owner) public view returns (uint256); function fullyDilutedAllowance(address _owner, address _spender) public view returns (uint256); function convert(uint256 _fromClass, uint256 _toClass, uint256 _value) public returns (bool); event Transfer(address indexed _from, address indexed _to, uint256 _class, uint256 _value); event Approval(address indexed _owner, address indexed _spender, uint256 _class, uint256 _value); event Convert(uint256 indexed _fromClass, uint256 indexed _toClass, uint256 _value); } ``` ### ERC-20 Methods and Events (fully compatible) Please see [ERC-20 Token Standard](/EIPS/eip-20) for detailed specifications. Do note that these methods and events only work on the "default" class of an MCT. ```solidity function totalSupply() public view returns (uint256); function balanceOf(address _owner) public view returns (uint256); function transfer(address _to, uint256 _value) public returns (bool); function approve(address _spender, uint256 _value) public returns (bool); function allowance(address _owner, address _spender) public view returns (uint256); function transferFrom(address _from, address _to, uint256 _value) public returns (bool); event Transfer(address indexed _from, address indexed _to, uint256 _value); event Approval(address indexed _owner, address indexed _spender, uint256 _value); ``` ### Tracking and Transferring **totalSupply** Returns the total number of tokens in the specified `_class` ```solidity function totalSupply(uint256 _class) public view returns (uint256); ``` **balanceOf** Returns the number of tokens of a specified `_class` that the `_owner` has ```solidity function balanceOf(address _owner, uint256 _class) public view returns (uint256); ``` **transfer** Transfer `_value` tokens of `_class` to address specified by `_to`, return `true` if successful ```solidity function transfer(address _to, uint256 _class, uint256 _value) public returns (bool); ``` **approve** Grant `_spender` the right to transfer `_value` tokens of `_class`, return `true` if successful ```solidity function approve(address _spender, uint256 _class, uint256 _value) public returns (bool); ``` **allowance** Return the number of tokens of `_class` that `_spender` is authorized to transfer on the behalf of `_owner` ```solidity function allowance(address _owner, address _spender, uint256 _class) public view returns (uint256); ``` **transferFrom** Transfer `_value` tokens of `_class` from address specified by `_from` to address specified by `_to` as previously approved, return `true` if successful ```solidity function transferFrom(address _from, address _to, uint256 _class, uint256 _value) public returns (bool); ``` **Transfer** Triggered when tokens are transferred or created, including zero value transfers ```solidity event Transfer(address indexed _from, address indexed _to, uint256 _class, uint256 _value); ``` **Approval** Triggered on successful `approve` ```solidity event Approval(address indexed _owner, address indexed _spender, uint256 _class, uint256 _value); ``` ### Conversion and Dilution **fullyDilutedTotalSupply** Return the total token supply as if all converted to the lowest common denominator class ```solidity function fullyDilutedTotalSupply() public view returns (uint256); ``` **fullyDilutedBalanceOf** Return the total token owned by `_owner` as if all converted to the lowest common denominator class ```solidity function fullyDilutedBalanceOf(address _owner) public view returns (uint256); ``` **fullyDilutedAllowance** Return the total token `_spender` is authorized to transfer on behalf of `_owner` as if all converted to the lowest common denominator class ```solidity function fullyDilutedAllowance(address _owner, address _spender) public view returns (uint256); ``` **convert** Convert `_value` of `_fromClass` to `_toClass`, return `true` if successful ```solidity function convert(uint256 _fromClass, uint256 _toClass, uint256 _value) public returns (bool); ``` **Conversion** Triggered on successful `convert` ```solidity event Conversion(uint256 indexed _fromClass, uint256 indexed _toClass, uint256 _value); ``` ## Rationale This standard purposely extends ERC-20 Token Standard so that new MCTs following or existing ERC-20 tokens extending this standard are fully compatible with current wallets and exchanges. In addition, new methods and events are kept as closely to ERC-20 conventions as possible for ease of adoption. We have considered alternative implementations to support the multi-class structure, as discussed below, and we found current token standards incapable or inefficient in deal with such structures. **Using multiple ERC-20 tokens** It is certainly possible to create an ERC-20 token for each class, and a separate contract to coordinate potential conversions, but the short coming in this approach is clearly evident. The rationale behind this standard is to have a single contract to manage multiple classes of tokens. **Shoehorning ERC-721 token** Treating each token as unique, the non-fungible token standard offers maximum representational flexibility arguably at the expense of convenience. The main challenge of using ERC-721 to represent multi-class token is that separate logic is required to keep track of which tokens belongs to which class, a hacky and unnecessary endeavor. **Using ERC-1178 token** We came across ERC-1178 as we were putting final touches on our own proposal. The two ERCs look very similar on the surface but we believe there're a few key advantages this one has over ERC-1178. - ERC-1178 offers no backward compatibility whereas this proposal is an extension of ERC-20 and therefore fully compatible with all existing wallets and exchanges - By the same token, existing ERC-20 contracts can extend themselves to adopt this standard and support additional classes without affecting their current behaviors - This proposal introduces the concept of cross class conversion and dilution, making each token class integral part of a whole system rather than many silos ## Backwards Compatibility This EIP is fully compatible with the mandatory methods of ERC20 Token Standard so long as the implementation includes a "lowest common denominator" class, which may be class B common/gold coin/money in the abstract/virtual/physical examples above respectively. Where it is not possible to implement such class, then the implementation should specify a default class for tracking or transferring unless otherwise specified, e.g. US dollar is transferred unless other currency is explicitly specified. We find it contrived to require the optional methods of ERC20 Token Standard, `name()`, `symbol()`, and `decimals()`, but developers are certainly free to implement these as they wish. ## Test Cases The repository at [jeffishjeff/ERC-1203](https://github.com/jeffishjeff/ERC-1203) contains the [sample test cases](https://github.com/jeffishjeff/ERC-1203/blob/master/token.test.js). ## Implementation The repository at [jeffishjeff/ERC-1203](https://github.com/jeffishjeff/ERC-1203) contains the [sample implementation](https://github.com/jeffishjeff/ERC-1203/blob/master/token.sol). ## References - ERC-20 Token Standard. ./eip-20.md - ERC-721 Non-Fungible Token Standard. ./eip-721.md - ERC-1178 Multi-class Token Standard. ./eip-1178.md ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 01 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1203 https://eips.ethereum.org/EIPS/eip-1203 DAuth Access Delegation Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1207 DAuth Access Delegation Standard ===== ## Simple Summary DAuth is a standard interface for accessing authorization delegation between smart contracts and users. ## Abstract The DAuth protocol defines a set of standard API allowing identity delegations between smart contracts without the user's private key. Identity delegations include accessing and operating a user's data and assets contained in the delegated contracts. ## Motivation The inspiration for designing DAuth comes from OAuth protocol that is extensively used in web applications. But unlike the centralized authorization of OAuth, DAuth works in a distributed manner, thus providing much more reliability and generality. ## Specification ![Rationale](/assets/eip-1207/rationale.png) **Resource owner**: the authorizer **Resource contract**: the contract providing data and operators **API**: the resource contract APIs that the grantee contract can invoke **Client contract**: the grantee contract using authorization to access and operate the data **Grantee request**: the client contract calls the resource contract with the authorizer authorization **AuthInfo** ``` js struct AuthInfo { string[] funcNames; uint expireAt; } ``` Required - The struct contains user authorization information * `funcNames`: a list of function names callable by the granted contract * `expireAt`: the authorization expire timestamp in seconds **userAuth** ``` js mapping(address => mapping(address => AuthInfo)) userAuth; ``` Required - userAuth maps (authorizer address, grantee contract address) pair to the user’s authorization AuthInfo object **callableFuncNames** ``` js string[] callableFuncNames; ``` Required - All methods that are allowed other contracts to call * The callable function MUST verify the grantee’s authorization **updateCallableFuncNames** ``` js function updateCallableFuncNames(string _invokes) public returns (bool success); ``` Optional - Update the callable function list for the client contract by the resource contract's administrator * `_invokes`: the invoke methods that the client contract can call * return: Whether the callableFuncNames is updated or not * This method MUST return success or throw, no other outcomes can be possible **verify** ``` js function verify(address _authorizer, string _invoke) internal returns (bool success); ``` Required - check the invoke method authority for the client contract * `_authorizer`: the user address that the client contract agents * `_invoke`: the invoke method that the client contract wants to call * return: Whether the grantee request is authorized or not * This method MUST return success or throw, no other outcomes can be possible **grant** ``` js function grant(address _grantee, string _invokes, uint _expireAt) public returns (bool success); ``` Required - delegate a client contract to access the user's resource * `_grantee`: the client contract address * `_invokes`: the callable methods that the client contract can access. It is a string which contains all function names split by spaces * `_expireAt`: the authorization expire timestamp in seconds * return: Whether the grant is successful or not * This method MUST return success or throw, no other outcomes can be possible * A successful grant MUST fire the Grant event(defined below) **regrant** ``` js function regrant(address _grantee, string _invokes, uint _expireAt) public returns (bool success); ``` Optional - alter a client contract's delegation **revoke** ``` js function revoke(address _grantee) public returns (bool success); ``` Required - delete a client contract's delegation * `_grantee`: the client contract address * return: Whether the revoke is successful or not * A successful revoke MUST fire the Revoke event(defined below). **Grant** ``` js event Grant(address _authorizer, address _grantee, string _invokes, uint _expireAt); ``` * This event MUST trigger when the authorizer grant a new authorization when `grant` or `regrant` processes successfully **Revoke** ``` js event Revoke(address _authorizer, address _grantee); ``` * This event MUST trigger when the authorizer revoke a specific authorization successfully **Callable Resource Contract Functions** All public or external functions that are allowed the grantee to call MUST use overload to implement two functions: The First one is the standard method that the user invokes directly, the second one is the grantee methods of the same function name with one more authorizer address parameter. Example: ``` js function approve(address _spender, uint256 _value) public returns (bool success) { return _approve(msg.sender, _spender, _value); } function approve(address _spender, uint256 _value, address _authorizer) public returns (bool success) { verify(_authorizer, "approve"); return _approve(_authorizer, _spender, _value); } function _approve(address sender, address _spender, uint256 _value) internal returns (bool success) { allowed[sender][_spender] = _value; emit Approval(sender, _spender, _value); return true; } ``` ## Rationale **Current Limitations** The current design of many smart contracts only considers the user invokes the smart contract functions by themselves using the private key. However, in some case, the user wants to delegate other client smart contracts to access and operate their data or assets in the resource smart contract. There isn’t a common protocol to provide a standard delegation approach. **Rationale** On the Ethereum platform, all storage is transparent and the `msg.sender` is reliable. Therefore, the DAuth don't need an `access_token` like OAuth. DAuth just recodes the users' authorization for the specific client smart contract's address. It is simple and reliable on the Ethereum platform. ## Backwards Compatibility This EIP introduces no backward compatibility issues. In the future, the new version protocol has to keep these interfaces. ## Implementation Following is the DAuth Interface implementation. Furthermore, the example implementations of EIP20 Interface and ERC-DAuth Interface are also provided. Developers can easily implement their own contracts with ERC-DAuth Interface and other EIP. * ERC-DAuth Interface implementation is available at: https://github.com/DIA-Network/ERC-DAuth/blob/master/ERC-DAuth-Interface.sol * Example implementation with EIP20 Interface and ERC-DAuth Interface is available at: https://github.com/DIA-Network/ERC-DAuth/blob/master/eip20-dauth-example/EIP20DAuth.sol ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 10 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1207 https://eips.ethereum.org/EIPS/eip-1207 Defuse Difficulty Bomb and Reset Block Reward Standards Track/Core https://github.com/ethereum/EIPs/issues/1227 ## Simple Summary This EIP proposes to permanently disable the "difficulty bomb" and reset the block reward to pre-Byzantium levels. ## Abstract Starting with `FORK_BLKNUM` the client will calculate the difficulty without the additional exponential component. Furthermore, block rewards will be adjusted to a base of 5 ETH, uncle and nephew rewards will be adjusted accordingly. ## Motivation Due to the "difficulty bomb" (also known as the "ice age"), introduced in EIP [#2](/EIPS/eip-2), an artificial exponential increase in difficulty until chain freeze, users may find it much more challenging to remain on the unforked chain after a hard-fork. This is a desirable effect of the ice age (in fact, its only stated purpose) in the case of a scheduled network upgrade, but is especially problematic when a hard-fork includes a controversial change. This situation has already been observed: during the Byzantium hard-fork users were given the "choice" of following the upgraded side of the chain or remaining on the original chain, the latter already experiencing block times greater than 30 seconds. In reality one will find that organizing a disperse and decentralized set of individuals to keep the original, soon-to-be-dead chain alive under such conditions impossible. This is exacerbated when a controversial change, such as EIP [#649](/EIPS/eip-649), is merged in so close to the hard-fork date, as users cannot be organized to take an educated stance for or against the change on such short notice. Ultimately, the difficulty bomb serves but a single purpose: make it more difficult to keep the original chain alive after a hard-fork. This is unacceptable if the only way the community can make their voice heard is running/not running client software, and not through the EIP process, since they effectively have no choice and therefore no power. This EIP proposes to completely eliminate the difficulty bomb, returning some measure of power over Ethereum's governance process to the users, to the community. Given the controversy surrounding the directly relevant EIP [#649](/EIPS/eip-649), the issuance should also be reset to pre-Byzantium levels. It may be reduced again at a later time via a new hard-fork, only this time users would actually have a meaningful choice in accepting the change or not. Note: the issuance reduction is not the focus of this proposal, and is optional; the defusing of the difficulty bomb is of primary concern. ## Specification #### Remove Exponential Component of Difficulty Adjustment For the purposes of `calc_difficulty`, simply remove the exponential difficulty adjustment component, `epsilon`, i.e. the `int(2**((block.number // 100000) - 2))`. #### Reset Block, Uncle, and Nephew rewards To ensure a constant Ether issuance, adjust the block reward to `new_block_reward`, where new_block_reward = 5_000_000_000_000_000_000 if block.number >= FORK_BLKNUM else block.reward (5E18 wei, or 5,000,000,000,000,000,000 wei, or 5 ETH). Analogue, if an uncle is included in a block for `block.number >= FORK_BLKNUM` such that `block.number - uncle.number = k`, the uncle reward is new_uncle_reward = (8 - k) * new_block_reward / 8 This is the existing pre-Byzantium formula for uncle rewards, simply adjusted with `new_block_reward`. The nephew reward for `block.number >= FORK_BLKNUM` is new_nephew_reward = new_block_reward / 32 This is the existing pre-Byzantium formula for nephew rewards, simply adjusted with `new_block_reward`. ## Rationale This will permanently, without further changes, disable the "ice age." It will also reset the block reward to pre-Byzantium levels. Both of these changes are specified similarly to EIP [#649](/EIPS/eip-649), so they should require only minimal changes from client developers. ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. However, it may be controversial in nature among different sections of the userbase&mdash;the very problem this EIP is made to address. Therefore, it should not be included in a scheduled hardfork at a certain block number. It is suggested to implement this EIP in an isolated hard-fork before the second of the two Metropolis hard-forks. ## Test Cases Forthcoming. ## Implementation Forthcoming. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 18 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1227 https://eips.ethereum.org/EIPS/eip-1227 Constantinople Difficulty Bomb Delay and Block Reward Adjustment Standards Track/Core https://ethereum-magicians.org/t/eip-1234-constantinople-difficulty-bomb-delay-and-block-reward-adjustment/833 ## Simple Summary The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately 12 months and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork. ## Abstract Starting with `CNSTNTNPL_FORK_BLKNUM` the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 5 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly. ## Motivation The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another 12 months. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake. ## Specification #### Relax Difficulty with Fake Block Number For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: fake_block_number = max(0, block.number - 5_000_000) if block.number >= CNSTNTNPL_FORK_BLKNUM else block.number #### Adjust Block, Uncle, and Nephew rewards To ensure a constant Ether issuance, adjust the block reward to `new_block_reward`, where new_block_reward = 2_000_000_000_000_000_000 if block.number >= CNSTNTNPL_FORK_BLKNUM else block.reward (2E18 wei, or 2,000,000,000,000,000,000 wei, or 2 ETH). Analogue, if an uncle is included in a block for `block.number >= CNSTNTNPL_FORK_BLKNUM` such that `block.number - uncle.number = k`, the uncle reward is new_uncle_reward = (8 - k) * new_block_reward / 8 This is the existing pre-Constantinople formula for uncle rewards, simply adjusted with `new_block_reward`. The nephew reward for `block.number >= CNSTNTNPL_FORK_BLKNUM` is new_nephew_reward = new_block_reward / 32 This is the existing pre-Constantinople formula for nephew rewards, simply adjusted with `new_block_reward`. ## Rationale This will delay the ice age by 29 million seconds (approximately 12 months), so the chain would be back at 30 second block times in winter 2019. An alternate proposal was to add special rules to the difficulty calculation to effectively _pause_ the difficulty between different blocks. This would lead to similar results. This was previously discussed at All Core Devs Meeting [#42](https://github.com/ethereum/pm/blob/6dbd82303bfcb697eaf9a76de37f5fa570e6379d/AllCoreDevs-EL-Meetings/Meeting%2042.md) and subsequent meetings; and accepted in the Constantinople Session [#1](https://github.com/ethereum/pm/issues/55). ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, _Constantinople_. ## Test Cases Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. ## Implementation The implementation in it's logic does not differ from [EIP-649](/EIPS/eip-649); an implementation for Parity-Ethereum is available in [parity-ethereum#9187](https://github.com/paritytech/parity-ethereum/pull/9187). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 19 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1234 https://eips.ethereum.org/EIPS/eip-1234 Remove Difficulty Bomb Standards Track/Core https://ethereum-magicians.org/t/difficulty-bomb-removal/832 ## Simple Summary The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to remove the difficulty increase over time and replace it with a fixed difficulty targeting 15 second blocks. ## Abstract Starting with `FORK_BLOCK_NUMBER` the client will calculate the difficulty without considering the current block number. ## Motivation The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. Another way to put this is that miners will follow economic participants, not the other way around. ## Specification #### Remove Difficulty For the purposes of `calc_difficulty`, if `block.number >= FORK_BLOCK_NUMBER` then change the epsilon component to `0` rather than having it be a function of block number. ## Rationale With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not. If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today. This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users. Author Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults. ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number. ## Test Cases Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. ## Implementations The yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710 ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 21 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1240 https://eips.ethereum.org/EIPS/eip-1240 Membership Verification Token (MVT) Standards Track/ERC https://github.com/ethereum/EIPs/issues/1261 ## Simple Summary A standard interface for Membership Verification Token(MVT). ## Abstract The following standard allows for the implementation of a standard API for Membership Verification Token within smart contracts(called entities). This standard provides basic functionality to track membership of individuals in certain on-chain ‘organizations’. This allows for several use cases like automated compliance, and several forms of governance and membership structures. We considered use cases of MVTs being assigned to individuals which are non-transferable and revocable by the owner. MVTs can represent proof of recognition, proof of membership, proof of right-to-vote and several such otherwise abstract concepts on the blockchain. The following are some examples of those use cases, and it is possible to come up with several others: - Voting: Voting is inherently supposed to be a permissioned activity. So far, onchain voting systems are only able to carry out voting with coin balance based polls. This can now change and take various shapes and forms. - Passport issuance, social benefit distribution, Travel permit issuance, Drivers licence issuance are all applications which can be abstracted into membership, that is belonging of an individual to a small set, recognized by some authority as having certain entitlements, without needing any individual specific information(right to welfare, freedom of movement, authorization to operate vehicles, immigration) - Investor permissioning: Making regulatory compliance a simple on chain process. Tokenization of securities, that are streamlined to flow only to accredited addresses, tracing and certifying on chain addresses for AML purposes. - Software licencing: Software companies like game developers can use the protocol to authorize certain hardware units(consoles) to download and use specific software(games) In general, an individual can have different memberships in their day to day life. The protocol allows for the creation of software that puts everything all at one place. Their identity can be verified instantly. Imagine a world where you don't need to carry a wallet full of identity cards (Passport, gym membership, SSN, Company ID etc) and organizations can easily keep track of all its members. Organizations can easily identify and disallow fake identities. Attributes are a huge part of ERC-1261 which help to store identifiable information regarding its members. Polls can make use of attributes to calculate the voterbase. E.g: Users should belong to USA entity and not belong to Washington state attribute to be a part of a poll. There will exist a mapping table that maps attribute headers to an array of all possible attributes. This is done in order to subdivide entities into subgroups which are exclusive and exhaustive. For example, header: blood group alphabet Array: [ o, a, b, ab ] header: blood group sign Array: [ +, - ] NOT an example of exclusive exhaustive: Header: video subscription Array: [ Netflix, HBO, Amazon ] Because a person is not necessitated to have EXACTLY one of the elements. He or she may have none or more than one. ## Motivation A standard interface allows any user, applications to work with any MVT on Ethereum. We provide for simple ERC-1261 smart contracts. Additional applications are discussed below. This standard is inspired from the fact that voting on the blockchain is done with token balance weights. This has been greatly detrimental to the formation of flexible governance systems on the blockchain, despite the tremendous governance potential that blockchains offer. The idea was to create a permissioning system that allows organizations to vet people once into the organization on the blockchain, and then gain immense flexibility in the kind of governance that can be carried out. We have also reviewed other Membership EIPs including EIP-725/735 Claim Registry. A significant difference between #735 claims and #1261 MVTs is information ownership. In #735 the Claim Holder owns any claims made about themselves. The problem with this is that there is no way for a Claim Issuer to revoke or alter a claim once it has been issued. While #735 does specify a removeClaim method, a malicious implementation could simply ignore that method call, because they own the claim. Imagine that SafeEmploy™, a background checking company, issues a claim about Timmy. The claim states that Timmy has never been convicted of any felonies. Timmy makes some bad decisions, and now that claim is no longer true. SafeEmploy™ executes removeClaim, but Timmy's #735 contract just ignores it, because Timmy wants to stay employed (and is crypto-clever). #1261 MVTs do not have this problem. Ownership of a badge/claim is entirely determined by the contract issuing the badges, not the one receiving them. The issuer is free to remove or change those badges as they see fit. **Trade-off between trustlessness and usability:** To truly understand the value of the protocol, it is important to understand the trade-off we are treading on. The MVT contract allows the creator to revoke the token, and essentially confiscate the membership of the member in question. To some, this might seem like an unacceptable flaw, however this is a design choice, and not a flaw. The choice may seem to place a great amount of trust in the individuals who are managing the entity contract(entity owners). If the interests of the entity owner conflict with the interests of the members, the owner may resort to addition of fake addresses(to dominate consensus) or evicting members(to censor unfavourable decisions). At first glance this appears to be a major shortcomings, because the blockchain space is used to absolute removal of authority in most cases. Even the official definition of a dapp requires the absence of any party that manages the services provided by the application. However, the trust in entity owners is not misplaced, if it can be ensured that the interests of entity owners are aligned with the interests of members. Another criticism of such a system would be that the standard edge of blockchain intermediation - “you cannot bribe the system if you don’t know who to bribe” - no longer holds. It is possible to bribe an entity owner into submission, and get them to censor or fake votes. There are several ways to respond to this argument. First of all, all activities, such as addition of members, and removal of members can be tracked on the blockchain and traces of such activity cannot be removed. It is not difficult to build analytics tools to detect malicious activity(adding 100 fake members suddenly who vote in the direction/sudden removal of a number of members voting in a certain direction). Secondly, the entity owners’ power is limited to the addition and removal of members. This means that they cannot tamper any votes. They can only alter the counting system to include fake voters or remove real voters. Any sensible auditor can identify the malicious/victim addresses and create an open source audit tool to find out the correct results. The biggest loser in this attack will be the entity owner, who has a reputation to lose. Finally, one must understand why we are taking a step away from trustlessness in this trade-off. The answer is usability. Introducing a permissioning system expands the scope of products and services that can be delivered through the blockchain, while leveraging other aspects of the blockchain(cheap, immutable, no red-tape, secure). Consider the example of the driver licence issuing agency using the ERC-1300 standard. This is a service that simply cannot be deployed in a completely trustless environment. The introduction of permissioned systems expanded the scope of services on the blockchain to cover this particular service. Sure, they have the power to revoke a person’s licence for no reason. But will they? Who stands to lose the most, if the agency acts erratically? The agency itself. Now consider the alternative, the way licences(not necessarily only drivers licence, but say shareholder certificates and so on) are issued, the amount of time consumed, the complete lack of transparency. One could argue that if the legacy systems providing these services really wanted to carry out corruption and nepotism in the execution of these services, the present systems make it much easier to do so. Also, they are not transparent, meaning that there is no way to even detect if they act maliciously. All that being said, we are very excited to share our proposal with the community and open up to suggestions in this space. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. **Every ERC-1261 compliant contract must implement the `ERC1261`, `ERC173` and `ERC165` interfaces** (subject to "caveats" below): ```solidity /// @title ERC-1261 MVT Standard /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1261.md /// The constructor should define the attribute set for this MVT. /// Note: the ERC-165 identifier for this interface is 0x1d8362cf. interface IERC1261 {/* is ERC173, ERC165 */ /// @dev This emits when a token is assigned to a member. event Assigned(address indexed _to, uint[] attributeIndexes); /// @dev This emits when a membership is revoked. event Revoked(address indexed _to); /// @dev This emits when a user forfeits his membership event Forfeited(address indexed _to); /// @dev This emits when a membership request is accepted event ApprovedMembership(address indexed _to, uint[] attributeIndexes); /// @dev This emits when a membership is requested by an user event RequestedMembership(address indexed _to); /// @dev This emits when data of a member is modified. /// Doesn't emit when a new membership is created and data is assigned. event ModifiedAttributes(address indexed _to, uint attributeIndex, uint attributeValueIndex); /// @notice Adds a new attribute (key, value) pair to the set of pre-existing attributes. /// @dev Adds a new attribute at the end of the array of attributes and maps it to `values`. /// Contract can set a max number of attributes and throw if limit is reached. /// @param _name Name of the attribute which is to be added. /// @param values List of values of the specified attribute. function addAttributeSet(bytes32 _name, bytes32[] calldata values) external; /// @notice Modifies the attribute value of a specific attribute for a given `_to` address. /// @dev Use appropriate checks for whether a user/admin can modify the data. /// Best practice is to use onlyOwner modifier from ERC173. /// @param _to The address whose attribute is being modified. /// @param _attributeIndex The index of attribute which is being modified. /// @param _modifiedValueIndex The index of the new value which is being assigned to the user attribute. function modifyAttributeByIndex(address _to, uint _attributeIndex, uint _modifiedValueIndex) external; /// @notice Requests membership from any address. /// @dev Throws if the `msg.sender` already has the token. /// The individual `msg.sender` can request for a membership if some existing criteria are satisfied. /// When a membership is requested, this function emits the RequestedMembership event. /// dev can store the membership request and use `approveRequest` to assign membership later /// dev can also oraclize the request to assign membership later /// @param _attributeIndexes the attribute data associated with the member. /// This is an array which contains indexes of attributes. function requestMembership(uint[] calldata _attributeIndexes) external payable; /// @notice User can forfeit his membership. /// @dev Throws if the `msg.sender` already doesn't have the token. /// The individual `msg.sender` can revoke his/her membership. /// When the token is revoked, this function emits the Revoked event. function forfeitMembership() external payable; /// @notice Owner approves membership from any address. /// @dev Throws if the `_user` doesn't have a pending request. /// Throws if the `msg.sender` is not an owner. /// Approves the pending request /// Make oraclize callback call this function /// When the token is assigned, this function emits the `ApprovedMembership` and `Assigned` events. /// @param _user the user whose membership request will be approved. function approveRequest(address _user) external; /// @notice Owner discards membership from any address. /// @dev Throws if the `_user` doesn't have a pending request. /// Throws if the `msg.sender` is not an owner. /// Discards the pending request /// Make oraclize callback call this function if criteria are not satisfied /// @param _user the user whose membership request will be discarded. function discardRequest(address _user) external; /// @notice Assigns membership of an MVT from owner address to another address. /// @dev Throws if the member already has the token. /// Throws if `_to` is the zero address. /// Throws if the `msg.sender` is not an owner. /// The entity assigns the membership to each individual. /// When the token is assigned, this function emits the Assigned event. /// @param _to The address to which the token is assigned. /// @param _attributeIndexes The attribute data associated with the member. /// This is an array which contains indexes of attributes. function assignTo(address _to, uint[] calldata _attributeIndexes) external; /// @notice Only Owner can revoke the membership. /// @dev This removes the membership of the user. /// Throws if the `_from` is not an owner of the token. /// Throws if the `msg.sender` is not an owner. /// Throws if `_from` is the zero address. /// When transaction is complete, this function emits the Revoked event. /// @param _from The current owner of the MVT. function revokeFrom(address _from) external; /// @notice Queries whether a member is a current member of the organization. /// @dev MVT's assigned to the zero address are considered invalid, and this /// function throws for queries about the zero address. /// @param _to An address for whom to query the membership. /// @return Whether the member owns the token. function isCurrentMember(address _to) external view returns (bool); /// @notice Gets the value collection of an attribute. /// @dev Returns the values of attributes as a bytes32 array. /// @param _name Name of the attribute whose values are to be fetched /// @return The values of attributes. function getAttributeExhaustiveCollection(bytes32 _name) external view returns (bytes32[] memory); /// @notice Returns the list of all past and present members. /// @dev Use this function along with isCurrentMember to find wasMemberOf() in Js. /// It can be calculated as present in getAllMembers() and !isCurrentMember(). /// @return List of addresses who have owned the token and currently own the token. function getAllMembers() external view returns (address[]); /// @notice Returns the count of all current members. /// @dev Use this function in polls as denominator to get percentage of members voted. /// @return Count of current Members. function getCurrentMemberCount() external view returns (uint); /// @notice Returns the list of all attribute names. /// @dev Returns the names of attributes as a bytes32 array. /// AttributeNames are stored in a bytes32 Array. /// Possible values for each attributeName are stored in a mapping(attributeName => attributeValues). /// AttributeName is bytes32 and attributeValues is bytes32[]. /// Attributes of a particular user are stored in bytes32[]. /// Which has a single attributeValue for each attributeName in an array. /// Use web3.toAscii(data[0]).replace(/\u0000/g, "") to convert to string in JS. /// @return The names of attributes. function getAttributeNames() external view returns (bytes32[] memory); /// @notice Returns the attributes of `_to` address. /// @dev Throws if `_to` is the zero address. /// Use web3.toAscii(data[0]).replace(/\u0000/g, "") to convert to string in JS. /// @param _to The address whose current attributes are to be returned. /// @return The attributes associated with `_to` address. function getAttributes(address _to) external view returns (bytes32[]); /// @notice Returns the `attribute` stored against `_to` address. /// @dev Finds the index of the `attribute`. /// Throws if the attribute is not present in the predefined attributes. /// Returns the attributeValue for the specified `attribute`. /// @param _to The address whose attribute is requested. /// @param _attributeIndex The attribute Index which is required. /// @return The attribute value at the specified name. function getAttributeByIndex(address _to, uint _attributeIndex) external view returns (bytes32); } interface ERC173 /* is ERC165 */ { /// @dev This emits when ownership of a contract changes. event OwnershipTransferred(address indexed previousOwner, address indexed newOwner); /// @notice Get the address of the owner /// @return The address of the owner. function owner() external view; /// @notice Set the address of the new owner of the contract /// @param _newOwner The address of the new owner of the contract function transferOwnership(address _newOwner) external; } interface ERC165 { /// @notice Query if a contract implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 /// @dev Interface identification is specified in ERC-165. This function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceID` and /// `interfaceID` is not 0xffffffff, `false` otherwise function supportsInterface(bytes4 interfaceID) external view returns (bool); } ``` The **metadata extension** is OPTIONAL for ERC-1261 smart contracts (see "caveats", below). This allows your smart contract to be interrogated for its name and for details about the organization which your MV tokens represent. ```solidity /// @title ERC-1261 MVT Standard, optional metadata extension /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1261.md interface ERC1261Metadata /* is ERC1261 */ { /// @notice A descriptive name for a collection of MVTs in this contract function name() external view returns (string _name); /// @notice An abbreviated name for MVTs in this contract function symbol() external view returns (string _symbol); } ``` This is the "ERC1261 Metadata JSON Schema" referenced above. ```json { "title": "Organization Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the organization to which this MVT represents" }, "description": { "type": "string", "description": "Describes the organization to which this MVT represents" } } } ``` ### Caveats The 0.4.24 Solidity interface grammar is not expressive enough to document the ERC-1261 standard. A contract which complies with ERC-1261 MUST also abide by the following: - Solidity issue #3412: The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: `payable`, implicit nonpayable, `view`, and `pure`. Your implementation MUST meet the mutability guarantee in this interface and you MAY meet a stronger guarantee. For example, a `payable` function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.24 is that you can edit this interface to add stricter mutability before inheriting from your contract. - Solidity issue #3419: A contract that implements `ERC1261Metadata` SHALL also implement `ERC1261`. - Solidity issue #2330: If a function is shown in this specification as `external` then a contract will be compliant if it uses `public` visibility. As a workaround for version 0.4.24, you can edit this interface to switch to `public` before inheriting from your contract. - Solidity issues #3494, #3544: Use of `this.*.selector` is marked as a warning by Solidity, a future version of Solidity will not mark this as an error. _If a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification._ ## Rationale There are many potential uses of Ethereum smart contracts that depend on tracking membership. Examples of existing or planned MVT systems are Vault, a DAICO platform, and Stream, a security token framework. Future uses include the implementation of direct democracy, in-game memberships and badges, licence and travel document issuance, electronic voting machine trails, software licencing and many more. **MVT Word Choice:** Since the tokens are non transferable and revocable, they function like membership cards. Hence the word membership verification token. **Transfer Mechanism** MVTs can't be transferred. This is a design choice, and one of the features that distinguishes this protocol. Any member can always ask the issuer to revoke the token from an existing address and assign to a new address. One can think of the set of MVTs as identifying a user, and you cannot split the user into parts and have it be the same user, but you can transfer a user to a new private key. **Assign and Revoke mechanism** The assign and revoke functions' documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results: - **Disallow additional memberships after a condition is met** — Sample contract available on GitHub - **Blacklist certain address from receiving MV tokens** — Sample contract available on GitHub - **Disallow additional memberships after a certain time is reached** — Sample contract available on GitHub - **Charge a fee to user of a transaction** — require payment when calling `assign` and `revoke` so that condition checks from external sources can be made **ERC-173 Interface** We chose Standard Interface for Ownership (ERC-173) to manage the ownership of a ERC-1261 contract. A future EIP/ Zeppelin may create a multi-ownable implementation for ownership. We strongly support such an EIP and it would allow your ERC-1261 implementation to implement `ERC1261Metadata`, or other interfaces by delegating to a separate contract. **ERC-165 Interface** We chose Standard Interface Detection (ERC-165) to expose the interfaces that a ERC-1261 smart contract supports. A future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your ERC-1261 implementation to implement `ERC1261Metadata`, or other interfaces by delegating to a separate contract. **Gas and Complexity** (regarding the enumeration extension) This specification contemplates implementations that manage a few and _arbitrarily large_ numbers of MVTs. If your application is able to grow then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound **Privacy** Personal information: The protocol does not put any personal information on to the blockchain, so there is no compromise of privacy in that respect. Membership privacy: The protocol by design, makes it public which addresses are/aren’t members. Without making that information public, it would not be possible to independently audit governance activity or track admin(entity owner) activity. **Metadata Choices** (metadata extension) We have required `name` and `symbol` functions in the metadata extension. Every token EIP and draft we reviewed (ERC-20, ERC-223, ERC-677, ERC-777, ERC-827) included these functions. We remind implementation authors that the empty string is a valid response to `name` and `symbol` if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as _your_ contract. How a client may determine which ERC-1261 smart contracts are well-known (canonical) is outside the scope of this standard. A mechanism is provided to associate MVTs with URIs. We expect that many implementations will take advantage of this to provide metadata for each MVT system. The URI MAY be mutable (i.e. it changes from time to time). We considered an MVT representing membership of a place, in this case metadata about the organization can naturally change. Metadata is returned as a string value. Currently this is only usable as calling from `web3`, not from other contracts. This is acceptable because we have not considered a use case where an on-blockchain application would query such information. _Alternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough)_ **Community Consensus** We have been very inclusive in this process and invite anyone with questions or contributions into our discussion. However, this standard is written only to support the identified use cases which are listed herein. ## Backwards Compatibility We have adopted `name` and `symbol` semantics from the ERC-20 specification. Example MVT implementations as of July 2018: - Membership Verification Token(https://github.com/chaitanyapotti/MembershipVerificationToken) ## Test Cases Membership Verification Token ERC-1261 Token includes test cases written using Truffle. ## Implementations Membership Verification Token ERC1261 -- a reference implementation - MIT licensed, so you can freely use it for your projects - Includes test cases - Also available as a npm package - npm i membershipverificationtoken ## References **Standards** 1. ERC-20 Token Standard. ./eip-20.md 1. ERC-165 Standard Interface Detection. ./eip-165.md 1. ERC-725/735 Claim Registry ./eip-725.md 1. ERC-173 Owned Standard. ./eip-173.md 1. JSON Schema. https://json-schema.org/ 1. Multiaddr. https://github.com/multiformats/multiaddr 1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt **Issues** 1. The Original ERC-1261 Issue. https://github.com/ethereum/eips/issues/1261 1. Solidity Issue \#2330 -- Interface Functions are Axternal. https://github.com/ethereum/solidity/issues/2330 1. Solidity Issue \#3412 -- Implement Interface: Allow Stricter Mutability. https://github.com/ethereum/solidity/issues/3412 1. Solidity Issue \#3419 -- Interfaces Can't Inherit. https://github.com/ethereum/solidity/issues/3419 **Discussions** 1. Gitter #EIPs (announcement of first live discussion). https://gitter.im/ethereum/EIPs?at=5b5a1733d2f0934551d37642 1. ERC-1261 (announcement of first live discussion). https://github.com/ethereum/eips/issues/1261 **MVT Implementations and Other Projects** 1. Membership Verification Token ERC-1261 Token. https://github.com/chaitanyapotti/MembershipVerificationToken ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 14 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1261 https://eips.ethereum.org/EIPS/eip-1261 Standard Signature Validation Method for Contracts Standards Track/ERC https://github.com/ethereum/EIPs/issues/1271 ## Abstract Externally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot. We propose a standard way for any contracts to verify whether a signature on a behalf of a given contract is valid. This is possible via the implementation of a `isValidSignature(hash, signature)` function on the signing contract, which can be called to validate a signature. ## Motivation There are and will be many contracts that want to utilize signed messages for validation of rights-to-move assets or other purposes. In order for these contracts to be able to support non Externally Owned Accounts (i.e., contract owners), we need a standard mechanism by which a contract can indicate whether a given signature is valid or not on its behalf. One example of an application that requires signatures to be provided would be decentralized exchanges with off-chain orderbook, where buy/sell orders are signed messages. In these applications, EOAs sign orders, signaling their desire to buy/sell a given asset and giving explicit permissions to the exchange smart contracts to conclude a trade via a signature. When it comes to contracts however, regular signatures are not possible since contracts do not possess a private key, hence this proposal. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). ```javascript pragma solidity ^0.5.0; contract ERC1271 { // bytes4(keccak256("isValidSignature(bytes32,bytes)") bytes4 constant internal MAGICVALUE = 0x1626ba7e; /** * @dev Should return whether the signature provided is valid for the provided hash * @param _hash Hash of the data to be signed * @param _signature Signature byte array associated with _hash * * MUST return the bytes4 magic value 0x1626ba7e when function passes. * MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5) * MUST allow external calls */ function isValidSignature( bytes32 _hash, bytes memory _signature) public view returns (bytes4 magicValue); } ``` `isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc. This function should be implemented by contracts which desire to sign messages (e.g. smart contract wallets, DAOs, multisignature wallets, etc.) Applications wanting to support contract signatures should call this method if the signer is a contract. ## Rationale We believe the name of the proposed function to be appropriate considering that an *authorized* signers providing proper signatures for a given data would see their signature as "valid" by the signing contract. Hence, a signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart wallet. Two arguments are provided for simplicity of separating the hash signed from the signature. A bytes32 hash is used instead of the unhashed message for simplicity, since contracts could expect a certain hashing function that is not standard, such as with [EIP-712](/EIPS/eip-712). `isValidSignature()` should not be able to modify states in order to prevent `GasToken` minting or similar attack vectors. Again, this is to simplify the implementation surface of the function for better standardization and to allow off-chain contract queries. The specific return value is expected to be returned instead of a boolean in order to have stricter and simpler verification of a signature. ## Backwards Compatibility This EIP is backward compatible with previous work on signature validation since this method is specific to contract based signatures and not EOA signatures. ## Reference Implementation Example implementation of a signing contract: ```solidity /** * @notice Verifies that the signer is the owner of the signing contract. */ function isValidSignature( bytes32 _hash, bytes calldata _signature ) external override view returns (bytes4) { // Validate signatures if (recoverSigner(_hash, _signature) == owner) { return 0x1626ba7e; } else { return 0xffffffff; } } /** * @notice Recover the signer of hash, assuming it's an EOA account * @dev Only for EthSign signatures * @param _hash Hash of message that was signed * @param _signature Signature encoded as (bytes32 r, bytes32 s, uint8 v) */ function recoverSigner( bytes32 _hash, bytes memory _signature ) internal pure returns (address signer) { require(_signature.length == 65, "SignatureValidator#recoverSigner: invalid signature length"); // Variables are not scoped in Solidity. uint8 v = uint8(_signature[64]); bytes32 r = _signature.readBytes32(0); bytes32 s = _signature.readBytes32(32); // EIP-2 still allows signature malleability for ecrecover(). Remove this possibility and make the signature // unique. Appendix F in the Ethereum Yellow paper (https://ethereum.github.io/yellowpaper/paper.pdf), defines // the valid range for s in (281): 0 < s < secp256k1n ÷ 2 + 1, and for v in (282): v ∈ {27, 28}. Most // signatures from current libraries generate a unique signature with an s-value in the lower half order. // // If your library generates malleable signatures, such as s-values in the upper range, calculate a new s-value // with 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 - s1 and flip v from 27 to 28 or // vice versa. If your library also generates signatures with 0/1 for v instead 27/28, add 27 to v to accept // these malleable signatures as well. // // Source OpenZeppelin // https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ECDSA.sol if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0) { revert("SignatureValidator#recoverSigner: invalid signature 's' value"); } if (v != 27 && v != 28) { revert("SignatureValidator#recoverSigner: invalid signature 'v' value"); } // Recover ECDSA signer signer = ecrecover(_hash, v, r, s); // Prevent signer from being 0x0 require( signer != address(0x0), "SignatureValidator#recoverSigner: INVALID_SIGNER" ); return signer; } ``` Example implementation of a contract calling the isValidSignature() function on an external signing contract ; ```solidity function callERC1271isValidSignature( address _addr, bytes32 _hash, bytes calldata _signature ) external view { bytes4 result = IERC1271Wallet(_addr).isValidSignature(_hash, _signature); require(result == 0x1626ba7e, "INVALID_SIGNATURE"); } ``` ## Security Considerations Since there are no gas-limit expected for calling the isValidSignature() function, it is possible that some implementation will consume a large amount of gas. It is therefore important to not hardcode an amount of gas sent when calling this method on an external contract as it could prevent the validation of certain signatures. Note also that each contract implementing this method is responsible to ensure that the signature passed is indeed valid, otherwise catastrophic outcomes are to be expected. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 25 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1271 https://eips.ethereum.org/EIPS/eip-1271 Eliminate Difficulty Bomb and Adjust Block Reward on Constantinople Shift Standards Track/Core https://ethereum-magicians.org/t/eip-1276-eliminate-difficulty-bomb-and-adjust-block-reward-on-constantinople-shift/908 ## Simple Summary The average block times are increasing due to the factor of difficulty logic well known as difficulty bomb. This EIP proposes to eliminate the difficulty bomb forever and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork. ## Abstract Starting with `CNSTNTNPL_FORK_BLKNUM` the client will calculate the difficulty without considering the current block number. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly. ## Motivation Block time has been played a most important role on blockchain ecosystem, and it is being adjusted by the logic of mining difficulty calculation that is already implemented on the node client as a part of proof-of-work consensus. Last year, average block time rapidly increased due to the wrong design of difficulty logic that is meant to be changed on the part of Casper upgrade, however, implementation of casper has been delayed therefore it was inevitable to delay the difficulty bomb in order to prevent the significant delay of processing transactions on ethereum network. Despite of the successful hardfork to delay the activation of difficulty bomb, activation of the difficulty bomb is expected to happen again on the upcoming period before implementing casper protocol on ethereum network. Therefore, completely removing the difficulty bomb is the most proper way to response the block time increase instead of delaying it again. Also decreasing the block mining reward along with difficulty bomb removal is expected to help the growth of the stable ethereum ecosystem, right now ethereum dominates 92% of the total hashrate share of ethash based chains, and this corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake. ## Specification #### Remove Exponential Component of Difficulty Adjustment For the purposes of `calc_difficulty`, simply remove the exponential difficulty adjustment component, `epsilon`, i.e. the `int(2**((block.number // 100000) - 2))`. #### Adjust Block, Uncle, and Nephew rewards To ensure a constant Ether issuance, adjust the block reward to `new_block_reward`, where new_block_reward = 2_000_000_000_000_000_000 if block.number >= CNSTNTNPL_FORK_BLKNUM else block.reward (2E18 wei, or 2,000,000,000,000,000,000 wei, or 2 ETH). Analogue, if an uncle is included in a block for `block.number >= CNSTNTNPL_FORK_BLKNUM` such that `block.number - uncle.number = k`, the uncle reward is new_uncle_reward = (8 - k) * new_block_reward / 8 This is the existing pre-Constantinople formula for uncle rewards, simply adjusted with `new_block_reward`. The nephew reward for `block.number >= CNSTNTNPL_FORK_BLKNUM` is new_nephew_reward = new_block_reward / 32 This is the existing pre-Constantinople formula for nephew rewards, simply adjusted with `new_block_reward`. ## Rationale This will completely remove the difficulty bomb on difficulty adjustment algorithm without delaying the difficulty bomb again, therefore it is possible to prevent network delay on the beginning of 2019. This EIP-1276 opposes directly the intent of [EIP-1234](/EIPS/eip-1234) which should be also considered in discussions. ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, _Constantinople_. ## Test Cases Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. ## Implementation The implementation shall be created once the specification is to be accepted by the developers or implemented by the clients. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 31 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1276 https://eips.ethereum.org/EIPS/eip-1276 Net gas metering for SSTORE without dirty maps Standards Track/Core https://github.com/sorpaas/EIPs/issues/1 ## Abstract This EIP proposes net gas metering changes for `SSTORE` opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn't match how most implementations work. This acts as an alternative for EIP-1087, where it tries to be friendlier to implementations that use different optimization strategies for storage change caches. ## Motivation This EIP proposes a way for gas metering on SSTORE (as an alternative for EIP-1087 and EIP-1153), using information that is more universally available to most implementations, and requires as little change in implementation structures as possible. * *Storage slot's original value*. * *Storage slot's current value*. * Refund counter. Usages that benefits from this EIP's gas reduction scheme includes: * Subsequent storage write operations within the same call frame. This includes reentry locks, same-contract multi-send, etc. * Exchange storage information between sub call frame and parent call frame, where this information does not need to be persistent outside of a transaction. This includes sub-frame error codes and message passing, etc. ## Specification Definitions of terms are as below: * *Storage slot's original value*: This is the value of the storage if a reversion happens on the *current transaction*. * *Storage slot's current value*: This is the value of the storage before SSTORE operation happens. * *Storage slot's new value*: This is the value of the storage after SSTORE operation happens. Replace `SSTORE` opcode gas cost calculation (including refunds) with the following logic: * If *current value* equals *new value* (this is a no-op), 200 gas is deducted. * If *current value* does not equal *new value* * If *original value* equals *current value* (this storage slot has not been changed by the current execution context) * If *original value* is 0, 20000 gas is deducted. * Otherwise, 5000 gas is deducted. If *new value* is 0, add 15000 gas to refund counter. * If *original value* does not equal *current value* (this storage slot is dirty), 200 gas is deducted. Apply both of the following clauses. * If *original value* is not 0 * If *current value* is 0 (also means that *new value* is not 0), remove 15000 gas from refund counter. We can prove that refund counter will never go below 0. * If *new value* is 0 (also means that *current value* is not 0), add 15000 gas to refund counter. * If *original value* equals *new value* (this storage slot is reset) * If *original value* is 0, add 19800 gas to refund counter. * Otherwise, add 4800 gas to refund counter. Refund counter works as before -- it is limited to half of the gas consumed. On a transaction level, refund counter will never go below zero. However, there are some important notes depending on the implementation details: * If an implementation uses "transaction level" refund counter (refund is checkpointed at each call frame), then the refund counter continues to be unsigned. * If an implementation uses "execution-frame level" refund counter (a new refund counter is created at each call frame, and then merged back to parent when the call frame finishes), then the refund counter needs to be changed to signed -- at internal calls, a child refund can go below zero. ## Explanation The new gas cost scheme for `SSTORE` is divided into three different types: * **No-op**: the virtual machine does not need to do anything. This is the case if *current value* equals *new value*. * **Fresh**: this storage slot has not been changed, or has been reset to its original value. This is the case if *current value* does not equal *new value*, and *original value* equals *current value*. * **Dirty**: this storage slot has already been changed. This is the case if *current value* does not equal *new value*, and *original value* does not equal *current value*. We can see that the above three types cover all possible variations of *original value*, *current value*, and *new value*. **No-op** is a trivial operation. Below we only consider cases for **Fresh** and **Dirty**. All initial (not-**No-op**) `SSTORE` on a particular storage slot starts with **Fresh**. After that, it will become **Dirty** if the value has been changed. When going from **Fresh** to **Dirty**, we charge the gas cost the same as current scheme. A **Dirty** storage slot can be reset back to **Fresh** via a `SSTORE` opcode. This will trigger a refund. When a storage slot remains at **Dirty**, we charge 200 gas. In this case, we would also need to keep track of `R_SCLEAR` refunds -- if we already issued the refund but it no longer applies (*current value* is 0), then removes this refund from the refund counter. If we didn't issue the refund but it applies now (*new value* is 0), then adds this refund to the refund counter. It is not possible where a refund is not issued but we remove the refund in the above case, because all storage slot starts with **Fresh** state. ### State Transition Below is a graph ([by @Arachnid](https://github.com/ethereum/EIPs/pull/1283#issuecomment-410229053)) showing possible state transition of gas costs. We ignore **No-op** state because that is trivial: ![State Transition](/assets/eip-1283/state.png) Below is table version of the above diagram. Vertical shows the *new value* being set, and horizontal shows the state of *original value* and *current value*. When *original value* is 0: | | A (`current=orig=0`) | B (`current!=orig`) | |----|----------------------|--------------------------| | ~0 | B; 20k gas | B; 200 gas | | 0 | A; 200 gas | A; 200 gas, 19.8k refund | When *original value* is not 0: | | X (`current=orig!=0`) | Y (`current!=orig`) | Z (`current=0`) | |-------------|-----------------------|-------------------------|---------------------------| | `orig` | X; 200 gas | X; 200 gas, 4.8k refund | X; 200 gas, -10.2k refund | | `~orig, ~0` | Y; 5k gas | Y; 200 gas | Y; 200 gas, -15k refund | | 0 | Z; 5k gas, 15k refund | Z; 200 gas, 15k refund | Z; 200 gas | ## Rationale This EIP mostly achieves what a transient storage tries to do (EIP-1087 and EIP-1153), but without the complexity of introducing the concept of "dirty maps", or an extra storage struct. * We don't suffer from the optimization limitation of EIP-1087. EIP-1087 requires keeping a dirty map for storage changes, and implicitly makes the assumption that a transaction's storage changes are committed to the storage trie at the end of a transaction. This works well for some implementations, but not for others. After EIP-658, an efficient storage cache implementation would probably use an in-memory trie (without RLP encoding/decoding) or other immutable data structures to keep track of storage changes, and only commit changes at the end of a block. For them, it is possible to know a storage's original value and current value, but it is not possible to iterate over all storage changes without incurring additional memory or processing costs. * It never costs more gas compared with the current scheme. * It covers all usages for a transient storage. Clients that are easy to implement EIP-1087 will also be easy to implement this specification. Some other clients might require a little bit extra refactoring on this. Nonetheless, no extra memory or processing cost is needed on runtime. Regarding `SSTORE` gas cost and refunds, see Appendix for proofs of properties that this EIP satisfies. * For *absolute gas used* (that is, actual *gas used* minus *refund*), this EIP is equivalent to EIP-1087 for all cases. * For one particular case, where a storage slot is changed, reset to its original value, and then changed again, EIP-1283 would move more gases to refund counter compared with EIP-1087. Examine examples provided in EIP-1087's Motivation: * If a contract with empty storage sets slot 0 to 1, then back to 0, it will be charged `20000 + 200 - 19800 = 400` gas. * A contract with empty storage that increments slot 0 5 times will be charged `20000 + 5 * 200 = 21000` gas. * A balance transfer from account A to account B followed by a transfer from B to C, with all accounts having nonzero starting and ending balances, it will cost `5000 * 3 + 200 - 4800 = 10400` gas. ## Backwards Compatibility This EIP requires a hard fork to implement. No gas cost increase is anticipated, and many contracts will see gas reduction. ## Test Cases Below we provide 17 test cases. 15 of them covering consecutive two `SSTORE` operations are based on work [by @chfast](https://github.com/ethereum/tests/issues/483). Two additional cases with three `SSTORE` operations is used to test the case when a slot is reset and then set again. | Code | Used Gas | Refund | Original | 1st | 2nd | 3rd | |------------------------------------|----------|--------|----------|-----|-----|-----| | `0x60006000556000600055` | 412 | 0 | 0 | 0 | 0 | | | `0x60006000556001600055` | 20212 | 0 | 0 | 0 | 1 | | | `0x60016000556000600055` | 20212 | 19800 | 0 | 1 | 0 | | | `0x60016000556002600055` | 20212 | 0 | 0 | 1 | 2 | | | `0x60016000556001600055` | 20212 | 0 | 0 | 1 | 1 | | | `0x60006000556000600055` | 5212 | 15000 | 1 | 0 | 0 | | | `0x60006000556001600055` | 5212 | 4800 | 1 | 0 | 1 | | | `0x60006000556002600055` | 5212 | 0 | 1 | 0 | 2 | | | `0x60026000556000600055` | 5212 | 15000 | 1 | 2 | 0 | | | `0x60026000556003600055` | 5212 | 0 | 1 | 2 | 3 | | | `0x60026000556001600055` | 5212 | 4800 | 1 | 2 | 1 | | | `0x60026000556002600055` | 5212 | 0 | 1 | 2 | 2 | | | `0x60016000556000600055` | 5212 | 15000 | 1 | 1 | 0 | | | `0x60016000556002600055` | 5212 | 0 | 1 | 1 | 2 | | | `0x60016000556001600055` | 412 | 0 | 1 | 1 | 1 | | | `0x600160005560006000556001600055` | 40218 | 19800 | 0 | 1 | 0 | 1 | | `0x600060005560016000556000600055` | 10218 | 19800 | 1 | 0 | 1 | 0 | ## Appendix: Proof Because the *storage slot's original value* is defined as the value when a reversion happens on the *current transaction*, it's easy to see that call frames won't interfere SSTORE gas calculation. So although the below proof is discussed without call frames, it applies to all situations with call frames. We will discuss the case separately for *original value* being zero and not zero, and use *induction* to prove some properties of SSTORE gas cost. *Final value* is the value of a particular storage slot at the end of a transaction. *Absolute gas used* is the absolute value of *gas used* minus *refund*. We use `N` to represent the total number of SSTORE operations on a storage slot. For states discussed below, refer to *State Transition* in *Explanation* section. ### Original Value Being Zero When *original value* is 0, we want to prove that: * **Case I**: If the *final value* ends up still being 0, we want to charge `200 * N` gases, because no disk write is needed. * **Case II**: If the *final value* ends up being a non-zero value, we want to charge `20000 + 200 * (N-1)` gas, because it requires writing this slot to disk. #### Base Case We always start at state A. The first SSTORE can: * Go to state A: 200 gas is deducted. We satisfy *Case I* because `200 * N == 200 * 1`. * Go to state B: 20000 gas is deducted. We satisfy *Case II* because `20000 + 200 * (N-1) == 20000 + 200 * 0`. #### Inductive Step * From A to A. The previous gas cost is `200 * (N-1)`. The current gas cost is `200 + 200 * (N-1)`. It satisfy *Case I*. * From A to B. The previous gas cost is `200 * (N-1)`. The current gas cost is `20000 + 200 * (N-1)`. It satisfy *Case II*. * From B to B. The previous gas cost is `20000 + 200 * (N-2)`. The current gas cost is `200 + 20000 + 200 * (N-2)`. It satisfy *Case II*. * From B to A. The previous gas cost is `20000 + 200 * (N-2)`. The current gas cost is `200 - 19800 + 20000 + 200 * (N-2)`. It satisfy *Case I*. ### Original Value Not Being Zero When *original value* is not 0, we want to prove that: * **Case I**: If the *final value* ends up unchanged, we want to charge `200 * N` gases, because no disk write is needed. * **Case II**: If the *final value* ends up being zero, we want to charge `5000 - 15000 + 200 * (N-1)` gas. Note that `15000` is the refund in actual definition. * **Case III**: If the *final value* ends up being a changed non-zero value, we want to charge `5000 + 200 * (N-1)` gas. #### Base Case We always start at state X. The first SSTORE can: * Go to state X: 200 gas is deducted. We satisfy *Case I* because `200 * N == 200 * 1`. * Go to state Y: 5000 gas is deducted. We satisfy *Case III* because `5000 + 200 * (N-1) == 5000 + 200 * 0`. * Go to state Z: The absolute gas used is `5000 - 15000` where 15000 is the refund. We satisfy *Case II* because `5000 - 15000 + 200 * (N-1) == 5000 - 15000 + 200 * 0`. #### Inductive Step * From X to X. The previous gas cost is `200 * (N-1)`. The current gas cost is `200 + 200 * (N-1)`. It satisfy *Case I*. * From X to Y. The previous gas cost is `200 * (N-1)`. The current gas cost is `5000 + 200 * (N-1)`. It satisfy *Case III*. * From X to Z. The previous gas cost is `200 * (N-1)`. The current absolute gas cost is `5000 - 15000 + 200 * (N-1)`. It satisfy *Case II*. * From Y to X. The previous gas cost is `5000 + 200 * (N-2)`. The absolute current gas cost is `200 - 4800 + 5000 + 200 * (N-2)`. It satisfy *Case I*. * From Y to Y. The previous gas cost is `5000 + 200 * (N-2)`. The current gas cost is `200 + 5000 + 200 * (N-2)`. It satisfy *Case III*. * From Y to Z. The previous gas cost is `5000 + 200 * (N-2)`. The current absolute gas cost is `200 - 15000 + 5000 + 200 * (N-2)`. It satisfy *Case II*. * From Z to X. The previous gas cost is `5000 - 15000 + 200 * (N-2)`. The current absolute gas cost is `200 + 10200 + 5000 - 15000 + 200 * (N-2)`. It satisfy *Case I*. * From Z to Y. The previous gas cost is `5000 - 15000 + 200 * (N-2)`. The current absolute gas cost is `200 + 15000 + 5000 - 15000 + 200 * (N-2)`. It satisfy *Case III*. * From Z to Z. The previous gas cost is `5000 - 15000 + 200 * (N-2)`. The current absolute gas cost is `200 + 5000 - 15000 + 200 * (N-2)`. It satisfy *Case II*. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 01 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1283 https://eips.ethereum.org/EIPS/eip-1283 Increase Gcallstipend gas in the CALL opcode Standards Track/Core https://ethereum-magicians.org/t/eip-1285-increase-gcallstipend-gas-in-the-call-opcode/941 ## Simple Summary Increase the ``Gcallstipend`` fee parameter in the ``CALL`` opcode from ``2,300`` to ``3,500`` gas units. ## Abstract Currently, the ``CALL`` opcode forwards a stipend of ``2,300`` gas units for a non zero value ``CALL`` operations where a contract is called. This stipend is given to the contract to allow execution of its ``fallback`` function. The stipend given is intentionally small in order to prevent the called contract from spending the call gas or performing an attack (like re-entrancy). While the stipend is small it should still give the sufficient gas required for some cheap opcodes like ``LOG``, but it's not enough for some more complex and modern logics to be implemented. This EIP proposes to increase the given stipend from ``2,300`` to ``3,500`` to increase the usability of the ``fallback`` function. ## Motivation The main motivation behind this EIP is to allow simple fallback functions to be implemented for contracts following the ``"Proxy"`` pattern. Simply explained, a ``"Proxy Contract"`` is a contract which use ``DELEGATECALL`` in its ``fallback`` function to behave according to the logic of another contract and serve as an independent instance for the logic of the contract it points to. This pattern is very useful for saving gas per deployment (as Proxy contracts are very lean) and it opens the ability to experiment with upgradability of contracts. On average, the ``DELEGATECALL`` functionality of a proxy contract costs about ``1,000`` gas units. When a contract transfers ETH to a proxy contract, the proxy logic will consume about ``1,000`` gas units before the ``fallback`` function of the logic contract will be executed. This leaves merely about 1,300 gas units for the execution of the logic. This is a severe limitation as it is not enough for an average ``LOG`` operation (it might be enough for a ``LOG`` with one parameter). By slightly increasing the gas units given in the stipend we allow proxy contracts have proper ``fallback`` logic without increasing the attack surface of the calling contract. ## Specification Increase the ``Gcallstipend`` fee parameter in the ``CALL`` opcode from ``2,300`` to ``3,500`` gas unit. The actual change to the Ethereum clients would be to change the ``CallStipend`` they store as a constant. For an implementation example you can find a Geth client implementation linked [here](https://github.com/ben-kaufman/go-ethereum/tree/eip-1285). The actual change to the code can be found [here](https://github.com/ben-kaufman/go-ethereum/blob/eip-1285/params/protocol_params.go#L41). ## Rationale The rational for increasing the ``Gcallstipend`` gas parameter by ``1,200`` gas units comes from the cost of performing ``DELEGATECALL`` and ``SLOAD`` with a small margin for some small additional operations. All while still keeping the stipend relatively small and insufficient for accessing the storage or changing the state. ## Backwards Compatibility This EIP requires a backwards incompatible change for the ``Gcallstipend`` gas parameter in the ``CALL`` opcode. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 01 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1285 https://eips.ethereum.org/EIPS/eip-1285 Modify Ethereum PoW Incentive Structure and Delay Difficulty Bomb Standards Track/Core https://github.com/atlanticcrypto/Discussion/issues/1 ## Simple Summary Network security and overall ecosystem maturity warrants the continued incentivization of Proof of Work participation but may allow for a reduction in ancillary ETH issuance and the delay of the Difficulty Bomb. This EIP proposes a reduction of Uncle and removal of Nephew rewards while delaying the Difficulty Bomb with the Constantinople hard fork. ## Abstract Starting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the Homestead fork. Furthermore, Uncle rewards will be adjusted and Nephew rewards will be removed to eliminate excess ancillary ETH issuance. The current ETH block reward of 3 ETH will remain constant. ## Motivation Network scalability and security are at the forefront of risks to the Ethereum protocol. With great strides being made towards on and off chain scalability, the existence of an artificial throughput limiting device in the protocol is not warranted. Removing the risk of reducing throughput through the initialization of the Difficulty Bomb is "low-hanging-fruit" to ensure continued operation at a minimum of current throughput through the next major hard fork (scheduled for late 2019). The security layer of the Ethereum network is and should remain robust. Incentives for continued operation of the security of the growing ecosystem are paramount. At the same time, the ancillary issuance benefits of the Ethereum protocol can be adjusted to reduce the overall issuance profile. Aggressively adjusting Uncle and removing Nephew rewards will reduce the inflationary aspect of ETH issuance, while keeping the current block reward constant at 3 ETH will ensure top line incentives stay in place. ## Specification #### Relax Difficulty with Fake Block Number For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: fake_block_number = max(0, block.number - 6_000_000) if block.number >= CNSTNTNPL_FORK_BLKNUM else block.number #### Adjust Uncle and Nephew rewards If an uncle is included in a block for `block.number >= CNSTNTNPL_FORK_BLKNUM` such that `block.number - uncle.number = k`, the uncle reward is new_uncle_reward = (3 - k) * new_block_reward / 8 This is the existing pre-Constantinople formula for uncle rewards, adjusted to reward 2 levels of Uncles at a reduced rate. The nephew reward for `block.number >= CNSTNTNPL_FORK_BLKNUM` is new_nephew_reward = 0 This is a removal of all rewards for Nephew blocks. ## Rationale The security layer of the Ethereum network is and should remain robust. Incentives for continued operation of the growing ecosystem’s security are paramount. At the same time, the ancillary issuance benefits of the Ethereum protocol can be adjusted to reduce the overall issuance profile. Aggressively adjusting Uncle and removing Nephew rewards will reduce the inflationary aspect of ETH issuance, while keeping the current block reward constant at 3 ETH will ensure top line incentives stay in place. The Difficulty Bomb was instituted as a type of planned obsolescence to force the implementation of network upgrades with regular frequency. With the focus on scalability for the protocol, delaying a mechanism whereby the throughput of the network can be limited artificially, due to any circumstance, is a logical step to ensure continued minimum network operation at the current throughput level. We believe the existence of the Difficulty Bomb has allowed for the inclusion of protocol upgrades in forced hard-forks, and will continue to do so. Through August 4th, the 2018 year to date reward issued to Uncle blocks totaled over 635,000 ETH. The average reward per Uncle totals 2.27 ETH. The year to date average Uncle rate is 22.49%. Using the year to date metrics, the ongoing average ETH paid as an Uncle reward per block is 0.51 ETH plus the Uncle inclusion reward of 0.021 ETH (0.09375 ETH * .2249), total Uncle related reward per block being over 0.53 ETH. With total year to date block rewards totaling approximately 3,730,000 ETH, the network has paid an additional 17pct in Uncle rewards. This is issuance that can be reduced while still maintaining the overall integrity and incentivization of network security. Reducing the issuance of ETH in rewarding Uncle blocks (forked blocks caused by latency in propagation, a multi-faceted problem) should directly incentivize the investment in technologies and efficiencies to reduce block propagation latency which may lead to a reduction in Network wide Uncle rates, reducing ancillary issuance further. Reducing the Uncle rewards from the current specification to the proposed will yield two levels of ancillary ETH issuance for Uncles: Level 1 Uncle -> 0.75 ETH Level 2 Uncle -> 0.375 ETH These levels are sufficient to continue incentivizing decentralized participation, while also providing an immediate economic incentive for the upgrade of the Ethereum node network and its tangential infrastructure. We believe that the ETH network has been subsidizing transaction inclusion through the robust Uncle Reward structure since inception. We also believe that a removal of the set subsidy will create a dynamic response mechanism whereby Miners and transaction senders will minimize total costs of transaction inclusion. This dynamic response structure may limit unnecessary layer 1 transaction throughput while providing incentives for layer 2 scaling solutions. The Nephew reward structure should be entirely eliminated. Due to current market conditions, and the likelihood of a further USD denominated price decline (50%), we believe that any top line reduction to security incentives will put the Ethereum network at undue risk. Unlike the time of the Byzantium hard fork, current USD denominated economics for securing the Ethereum network threaten the participation of the most decentralized Miner community (at home miners), which we believe make up the largest proportion of the overall network hashrate. We believe eliminating this portion of the community will increase centralization and the probability of an organized network attack. For a technology so new and with so much potential, we find it extremely irresponsible to increase the likelihood of a network attack by reducing ETH Issuance past this proposal’s level. With a reduction to the Uncle and removal of the Nephew reward, ancillary ETH issuance should drop (under normal market conditions, i.e. 22.49% uncle rate) by over 75pct and total ETH issuance from the successful sealing and mining of valid blocks should drop over 10pct. Paired with the diffusal of the Difficulty Bomb, this proposal strikes a balance between ensuring status quo network throughput, reducing overall ETH issuance, and continuing top line incentives for investment in infrastructure and efficiencies to continue operating the Ethereum network’s security layer. ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, Constantinople. ## Test Cases Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. ## Implementation Forthcoming. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 05 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1295 https://eips.ethereum.org/EIPS/eip-1295 Smart Contract Package Registry Interface Standards Track/ERC https://github.com/ethereum/EIPs/issues/1319 ## Simple Summary A standard interface for smart contract package registries. ## Abstract This EIP specifies an interface for publishing to and retrieving assets from smart contract package registries. It is a companion EIP to [1123](/EIPS/eip-1123) which defines a standard for smart contract package manifests. ## Motivation The goal is to establish a framework that allows smart contract publishers to design and deploy code registries with arbitrary business logic while exposing a set of common endpoints that tooling can use to retrieve assets for contract consumers. A clear standard would help the existing EthPM Package Registry evolve from a centralized, single-project community resource into a decentralized multi-registry system whose constituents are bound together by the proposed interface. In turn, these registries could be ENS name-spaced, enabling installation conventions familiar to users of `npm` and other package managers. **Examples** ```shell $ ethpm install packages.zeppelin.eth/Ownership ``` ```javascript const SimpleToken = await web3.packaging .registry('packages.ethpm.eth') .getPackage('simple-token') .getVersion('^1.1.5'); ``` ## Specification The specification describes a small read/write API whose components are mandatory. It allows registries to manage versioned releases using the conventions of [semver](https://semver.org/) without imposing this as a requirement. It assumes registries will share the following structure and conventions: + a **registry** is a deployed contract which manages a collection of **packages**. + a **package** is a collection of **releases** + a **package** is identified by a unique string name and unique bytes32 **packageId** within a given **registry** + a **release** is identified by a `bytes32` **releaseId** which must be unique for a given package name and release version string pair. + a **releaseId** maps to a set of data that includes a **manifestURI** string which describes the location of an [EIP 1123 package manifest](/EIPS/eip-1123). This manifest contains data about the release including the location of its component code assets. + a **manifestURI** is a URI as defined by [RFC3986](https://tools.ietf.org/html/rfc3986) which can be used to retrieve the contents of the package manifest. In addition to validation against RFC3986, each **manifestURI** must also contain a hash of the content as specified in the [EIP-1123](/EIPS/eip-1123). ### Examples **Package Names / Release Versions** ```shell "simple-token" # package name "1.0.1" # version string ``` **Release IDs** Implementations are free to choose any scheme for generating a **releaseId**. A common approach would be to hash the strings together as below: ```solidity // Hashes package name and a release version string function generateReleaseId(string packageName, string version) public view returns (bytes32 releaseId) { return keccak256(abi.encodePacked(packageName, version)); } ``` Implementations **must** expose this id generation logic as part of their public `read` API so tooling can easily map a string based release query to the registry's unique identifier for that release. **Manifest URIs** Any IPFS or Swarm URI meets the definition of **manifestURI**. Another example is content on GitHub addressed by its SHA-1 hash. The Base64 encoded content at this hash can be obtained by running: ```shell $ curl https://api.github.com/repos/:owner/:repo/git/blobs/:file_sha # Example $ curl https://api.github.com/repos/rstallman/hello/git/blobs/ce013625030ba8dba906f756967f9e9ca394464a ``` The string "hello" can have its GitHub SHA-1 hash independently verified by comparing it to the output of: ```shell $ printf "blob 6\000hello\n" | sha1sum > ce013625030ba8dba906f756967f9e9ca394464a ``` ### Write API Specification The write API consists of a single method, `release`. It passes the registry the package name, a version identifier for the release, and a URI specifying the location of a manifest which details the contents of the release. ```solidity function release(string packageName, string version, string manifestURI) public returns (bytes32 releaseId); ``` ### Events #### VersionRelease MUST be triggered when `release` is successfully called. ```solidity event VersionRelease(string packageName, string version, string manifestURI) ``` ### Read API Specification The read API consists of a set of methods that allows tooling to extract all consumable data from a registry. ```solidity // Retrieves a slice of the list of all unique package identifiers in a registry. // `offset` and `limit` enable paginated responses / retrieval of the complete set. (See note below) function getAllPackageIds(uint offset, uint limit) public view returns ( bytes32[] packageIds, uint pointer ); // Retrieves the unique string `name` associated with a package's id. function getPackageName(bytes32 packageId) public view returns (string packageName); // Retrieves the registry's unique identifier for an existing release of a package. function getReleaseId(string packageName, string version) public view returns (bytes32 releaseId); // Retrieves a slice of the list of all release ids for a package. // `offset` and `limit` enable paginated responses / retrieval of the complete set. (See note below) function getAllReleaseIds(string packageName, uint offset, uint limit) public view returns ( bytes32[] releaseIds, uint pointer ); // Retrieves package name, release version and URI location data for a release id. function getReleaseData(bytes32 releaseId) public view returns ( string packageName, string version, string manifestURI ); // Retrieves the release id a registry *would* generate for a package name and version pair // when executing a release. function generateReleaseId(string packageName, string version) public view returns (bytes32 releaseId); // Returns the total number of unique packages in a registry. function numPackageIds() public view returns (uint totalCount); // Returns the total number of unique releases belonging to the given packageName in a registry. function numReleaseIds(string packageName) public view returns (uint totalCount); ``` **Pagination** `getAllPackageIds` and `getAllReleaseIds` support paginated requests because it's possible that the return values for these methods could become quite large. The methods should return a `pointer` that points to the next available item in a list of all items such that a caller can use it to pick up from where the previous request left off. (See [here](https://mixmax.com/blog/api-paging-built-the-right-way) for a discussion of the merits and demerits of various pagination strategies.) The `limit` parameter defines the maximum number of items a registry should return per request. ## Rationale The proposal hopes to accomplish the following: + Define the smallest set of inputs necessary to allow registries to map package names to a set of release versions while allowing them to use any versioning schema they choose. + Provide the minimum set of getter methods needed to retrieve package data from a registry so that registry aggregators can read all of their data. + Define a standard query that synthesizes a release identifier from a package name and version pair so that tooling can resolve specific package version requests without needing to query a registry about all of a package's releases. Registries may offer more complex `read` APIs that manage requests for packages within a semver range or at `latest` etc. This EIP is agnostic about how tooling or registries might implement these. It recommends that registries implement [EIP-165](/EIPS/eip-165) and avail themselves of resources to publish more complex interfaces such as [EIP-926](/EIPS/eip-926). ## Backwards Compatibility No existing standard exists for package registries. The package registry currently deployed by EthPM would not comply with the standard since it implements only one of the method signatures described in the specification. ## Implementation A reference implementation of this proposal is in active development at the EthPM organization on GitHub [here](https://github.com/ethpm/escape-truffle). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 13 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1319 https://eips.ethereum.org/EIPS/eip-1319 WalletConnect URI Format Standards Track/ERC https://ethereum-magicians.org/t/wallet-connect-eip/850 ## Abstract This standard defines how the data to connect some application and a wallet can be encoded with a URI. This URI can then be shown either as a QR code or as a link. ## Specification ### Syntax WalletConnect request URI with the following parameters: request = "wc" ":" topic [ "@" version ][ "?" parameters ] topic = STRING version = 1*DIGIT parameters = parameter *( "&" parameter ) parameter = key "=" value key = STRING value = STRING ### Semantics Required parameters are dependent on the WalletConnect protocol version: For WalletConnect v1.0 protocol (`version`=`1`) the parameters are: - `key` - symmetric key used for encryption - `bridge` - url of the bridge server for relaying messages For WalletConnect v2.0 protocol (`version`=`2`) the parameters are: - `symKey` - symmetric key used for encrypting messages over relay - `methods` - jsonrpc methods supported for pairing topic - `relay-protocol` - transport protocol for relaying messages - `relay-data` - (optional) transport data for relaying messages - `expiryTimestamp` - (optional) unix epoch in seconds when pairing expires ### Example ``` # 1.0 wc:8a5e5bdc-a0e4-4702-ba63-8f1a5655744f@1?bridge=https%3A%2F%2Fbridge.walletconnect.org&key=41791102999c339c844880b23950704cc43aa840f3739e365323cda4dfa89e7a # 2.0 wc:7f6e504bfad60b485450578e05678ed3e8e8c4751d3c6160be17160d63ec90f9@2?relay-protocol=irn&symKey=587d5484ce2a2a6ee3ba1962fdd7e8588e06200c46823bd18fbd67def96ad303&methods=[wc_sessionPropose],[wc_authRequest,wc_authBatchRequest]"&expiryTimestamp=1705934757 ``` ## Rationale This proposal moves away from the JSON format used in the alpha version of the WalletConnect protocol because it suffered from very inefficient parsing of the intent of the QR code, thereby making it easier to create better QR code parsers APIs for wallets to implement. Also by using a URI instead of JSON inside the QR-Code the Android Intent system can be leveraged. ## Backwards Compatibility Versioning is required as part of the syntax for this URI specification to allow the WalletConnect protocol to evolve and allow backwards-compatibility whenever a new version is introduced. ## Security Considerations URIs should be shared between user devices or applications and no sensitive data is shared within the URI that could compromise the communication or would allow control of the user's private keys. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 15 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1328 https://eips.ethereum.org/EIPS/eip-1328 Subscriptions on the blockchain Standards Track/ERC https://ethereum-magicians.org/t/eip-1337-subscriptions-on-the-blockchain/4422 ## Simple Summary Monthly subscriptions are a key monetization channel for legacy web, and arguably they are the most healthy monetization channel for businesses on the legacy web (especially when compared to ad/surveillance) based models. They are arguably more healthy than a token based economic system (depending upon the vesting model of the ICO) because ##### For a user: * you don't have to read a complex whitepaper to use a dapps utility (as opposed to utility tokens) * you don't have to understand the founder's vesting schedules * you can cancel anytime ##### For a Service Provider: * since you know your subscriber numbers, churn numbers, conversion rate, you get consistent cash flow, and accurate projections * you get to focus on making your customers happy * enables you to remove speculators from your ecosystem For these reasons, we think it's imperative to create a standard way to do 'subscriptions' on Ethereum. ## Abstract To enable replay-able transactions users sign a concatenated bytes hash that is composed of the input data needed to execute the transaction. This data is stored off chain by the recipient of the payment and is transmitted to the customers smart contract for execution alongside a provided signature. ## Motivation Recurring payments are the bedrock of SaSS and countless other businesses, a robust specification for defining this interaction will enable a broad spectrum of revenue generation and business models. ## Specification #### Enum Contract EIP-1337 Contracts should be compiled with a contract that references all the enumerations that are required for operation ```SOLIDITY /// @title Enum - Collection of enums /// Original concept from Richard Meissner - <richard@gnosis.pm> Gnosis safe contracts contract Enum { enum Operation { Call, DelegateCall, Create, ERC20, ERC20Approve } enum SubscriptionStatus { ACTIVE, PAUSED, CANCELLED, EXPIRED } enum Period { INIT, DAY, WEEK, MONTH } } ``` #### EIP-165 EIP-1337 compliant contracts support EIP-165 announcing what interfaces they support ```SOLIDITY interface ERC165 { /** * @notice Query if a contract implements an interface * @param interfaceID The interface identifier, as specified in ERC-165 * @dev Interface identification is specified in ERC-165. This function * uses less than 30,000 gas. * @return `true` if the contract implements `interfaceID` and * `interfaceID` is not 0xffffffff, `false` otherwise **/ function supportsInterface(bytes4 interfaceID) external view returns (bool); } ``` #### Public View Functions ###### isValidSubscription ```SOLIDITY /** @dev Checks if the subscription is valid. * @param bytes subscriptionHash is the identifier of the customer's subscription with its relevant details. * @return success is the result of whether the subscription is valid or not. **/ function isValidSubscription( uint256 subscriptionHash ) public view returns ( bool success ) ``` ###### getSubscriptionStatus ```SOLIDITY /** @dev returns the value of the subscription * @param bytes subscriptionHash is the identifier of the customer's subscription with its relevant details. * @return status is the enumerated status of the current subscription, 0 expired, 1 active, 2 paused, 3 cancelled **/ function getSubscriptionStatus( uint256 subscriptionHash ) public view returns ( uint256 status, uint256 nextWithdraw ) ``` ###### getSubscriptionHash ```SOLIDITY /** @dev returns the hash of cocatenated inputs to the address of the contract holding the logic., * the owner would sign this hash and then provide it to the party for execution at a later date, * this could be viewed like a cheque, with the exception that unless you specifically * capture the hash on chain a valid signature will be executable at a later date, capturing the hash lets you modify the status to cancel or expire it. * @param address recipient the address of the person who is getting the funds. * @param uint256 value the value of the transaction * @param bytes data the data the user is agreeing to * @param uint256 txGas the cost of executing one of these transactions in gas(probably safe to pad this) * @param uint256 dataGas the cost of executing the data portion of the transaction(delegate calls etc) * @param uint 256 gasPrice the agreed upon gas cost of Execution of this subscription(cost incurment is up to implementation, ie, sender or receiver) * @param address gasToken address of the token in which gas will be compensated by, address(0) is ETH, only works in the case of an enscrow implementation) * @param bytes meta dynamic bytes array with 4 slots, 2 required, 2 optional // address refundAddress / uint256 period / uint256 offChainID / uint256 expiration (uinx timestamp) * @return bytes32, return the hash input arguments concatenated to the address of the contract that holds the logic. **/ function getSubscriptionHash( address recipient, uint256 value, bytes data, Enum.Operation operation, uint256 txGas, uint256 dataGas, uint256 gasPrice, address gasToken, bytes meta ) public view returns ( bytes32 subscriptionHash ) ``` ###### getModifyStatusHash ```SOLIDITY /** @dev returns the hash of concatenated inputs that the owners user would sign with their public keys * @param address recipient the address of the person who is getting the funds. * @param uint256 value the value of the transaction * @return bytes32 returns the hash of concatenated inputs with the address of the contract holding the subscription hash **/ function getModifyStatusHash( bytes32 subscriptionHash Enum.SubscriptionStatus status ) public view returns ( bytes32 modifyStatusHash ) ``` #### Public Functions ###### modifyStatus ```SOLIDITY /** @dev modifys the current subscription status * @param uint256 subscriptionHash is the identifier of the customer's subscription with its relevant details. * @param Enum.SubscriptionStatus status the new status of the subscription * @param bytes signatures of the requested method being called * @return success is the result of the subscription being paused **/ function modifyStatus( uint256 subscriptionHash, Enum.SubscriptionStatus status, bytes signatures ) public returns ( bool success ) ``` ###### executeSubscription ```SOLIDITY /** @dev returns the hash of cocatenated inputs to the address of the contract holding the logic., * the owner would sign this hash and then provide it to the party for execution at a later date, * this could be viewed like a cheque, with the exception that unless you specifically * capture the hash on chain a valid signature will be executable at a later date, capturing the hash lets you modify the status to cancel or expire it. * @param address recipient the address of the person who is getting the funds. * @param uint256 value the value of the transaction * @param bytes data the data the user is agreeing to * @param uint256 txGas the cost of executing one of these transactions in gas(probably safe to pad this) * @param uint256 dataGas the cost of executing the data portion of the transaction(delegate calls etc) * @param uint 256 gasPrice the agreed upon gas cost of Execution of this subscription(cost incurment is up to implementation, ie, sender or receiver) * @param address gasToken address of the token in which gas will be compensated by, address(0) is ETH, only works in the case of an enscrow implementation) * @param bytes meta dynamic bytes array with 4 slots, 2 required, 2 optional // address refundAddress / uint256 period / uint256 offChainID / uint256 expiration (uinx timestamp) * @param bytes signatures signatures concatenated that have signed the inputs as proof of valid execution * @return bool success something to note that a failed execution will still pay the issuer of the transaction for their gas costs. **/ function executeSubscription( address to, uint256 value, bytes data, Enum.Operation operation, uint256 txGas, uint256 dataGas, uint256 gasPrice, address gasToken, bytes meta, bytes signatures ) public returns ( bool success ) ``` ## Rationale Merchants who accept credit-cards do so by storing a token that is retrieved from a third party processor(stripe, paypal, etc), this token is used to grant access to pull payment from the cx's credit card provider and move funds to the merchant account. Having users sign input data acts in a similliar fashion and enables that merchant to store the signature of the concatenated bytes hash and input data used to generate the hash and pass them off to the contract holding the subscription logic, thus enabling a workflow that is similliar to what exists in the present day legacy web. ## Backwards Compatibility N/A ## Test Cases TBD ## Implementation TBD ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 01 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1337 https://eips.ethereum.org/EIPS/eip-1337 ChainID opcode Standards Track/Core https://ethereum-magicians.org/t/add-chain-id-opcode-for-replay-protection-when-handling-signed-messages-in-contracts/1131 ## Abstract This EIP adds an opcode that returns the current chain's EIP-155 unique identifier. ## Motivation [EIP-155](/EIPS/eip-155) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](/EIPS/eip-712). ## Specification Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. Chain ID is a 256-bit value. The operation costs `G_base` to execute. The value of the current chain ID is obtained from the chain ID configuration, which should match the EIP-155 unique identifier a client will accept from incoming transactions. Please note that per EIP-155, it is not *required* that a transaction have an EIP-155 unique identifier, but in that scenario this opcode will still return the configured chain ID and not a default. ## Rationale The current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages. By adding the proposed opcode it will be possible to access the current chain ID and validate signatures based on that. Currently, there is no specification for how chain ID is set for a particular network, relying on choices made manually by the client implementers and the chain community. There is a potential scenario where, during a "contentious split" over a divisive issue, a community using a particular value of chain ID will make a decision to split into two such chains. When this scenario occurs, it will be unsafe to maintain chain ID to the same value on both chains, as chain ID is used for replay protection for in-protocol transactions (per EIP-155), as well as for L2 and "meta-transaction" use cases (per EIP-712 as enabled by this proposal). There are two potential resolutions in this scenario under the current process: 1) one chain decides to modify their value of chain ID (while the other keeps it), or 2) both chains decide to modify their value of chain ID. In order to mitigate this situation, users of the proposed `CHAINID` opcode **must** ensure that their application can handle a potential update to the value of chain ID during their usage of their application in case this does occur, if required for the continued use of the application. A Trustless Oracle that logs the timestamp when a change is made to chain ID can be implemented either as an application-level feature inside the application contract system, or referenced as a globally standard contract. Failure to provide a mitigation for this scenario could lead to a sudden loss of legitimacy of previously signed off-chain messages, which could be an issue during settlement periods and other longer-term verification events for these types of messages. Not all applications of this opcode may need mitigations to handle this scenario, but developers should provide reasoning on a case-by-case basis. One example of a scenario where it would not make sense to leverage a global oracle is with the Plasma L2 paradigm. In the Plasma paradigm, an operator or group of operators submit blocks from the L2 network to the base chain (in this case Ethereum) summarizing transactions that have occurred on that chain. The submission of these blocks may not perfectly align with major events on the mainchain, such as a split causing an update of chain ID, which may cause a significant insecurity in the protocol if chain ID is utilized in signing messages. If the operators are not allowed to control the update of chain ID they will not be able to perfectly synchronize the update with their block submissions, and certain past transactions may be rejected because they do not align with the update. This is one example of the unintended consequences of trying to specify too much of the behavior of chain ID during a contentious split, and why having a simple opcode for access is most optimal, versus a more complicated precompile or contract. This proposed opcode would be the simplest possible way to implement this functionality, and allows developers the flexibility to implement their own global or local handling of chain ID changes, if required. ## Backwards Compatibility This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. ## References This was previously suggested as part of [EIP-901](https://github.com/ethereum/EIPs/issues/901). ## Test Cases Test Cases added to [ethereum/tests](https://github.com/ethereum/tests/pull/627) ## Implementation A reference implementation for the Trinity Python client is [here](https://github.com/ethereum/py-evm/pull/1803). An example implementation of a trustless chain ID oracle was implemented [here](https://github.com/fubuloubu/chain-id-oracle/blob/master/ChainIdOracle.vy). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 22 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1344 https://eips.ethereum.org/EIPS/eip-1344 Specify restricted address range for precompiles/system contracts Standards Track/Core https://ethereum-magicians.org/t/eip-1352-specify-restricted-address-range-for-precompiles-system-contracts/1151 ## Simple Summary Specify an Ethereum address range occupied by precompiles and future system contracts. Regular accounts and contracts cannot obtain such an address. ## Abstract The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts. ## Motivation This will simplify certain future features where unless this is implemented, several exceptions must be specified. ## Specification The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts. Due to the extremely low probability (and lack of adequate testing possibilities) no explicit checks should be added to ensure that external transaction signing or the invoking of the `CREATE` instruction can result in a precompile address. ## Rationale N/A ## Backwards Compatibility No contracts on the main network have been created at the specified addresses. As a result it should pose no backwards compatibility problems. ## Test Cases N/A ## Implementation N/A ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 27 Jul 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1352 https://eips.ethereum.org/EIPS/eip-1352 Ethash 1a Standards Track/Core https://ethereum-magicians.org/t/eip-1355-ethash-1a/1167 ## Motivation Provide minimal set of changes to Ethash algorithm to hinder and delay the adoption of ASIC based mining. ## Specification 1. Define hash function `fnv1a()` as ```python def fnv1a(v1, v2): return ((v1 ^ v2) * FNV1A_PRIME) % 2**32 ``` where `FNV1A_PRIME` is 16777499 or 16777639. 2. Change the hash function that determines the DAG item index in Ethash algorithm from `fnv()` to new `fnv1a()`. In [Main Loop](https://github.com/ethereum/eth-wiki/blob/master/concepts/ethash/ethash.md#main-loop) change ```python p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes ``` to ```python p = fnv1a(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes ``` ## Rationale The usual argument for decentralization and network security. Unless programmable, an ASIC is hardwired to perform sequential operations in a given order. fnv1a changes the order in which an exclusive-or and a multiply are applied, effectively disabling the current wave of ASICS. A second objective is minimize ethash changes to be the least disruptive, to facilitate rapid development, and to lower the analysis and test requirements. Minimizing changes to ethash reduces risk associated with updating all affected network components, and also reduces the risk of detuning existing GPUs. It's expected that this specific change would have no effect on existing GPU performance. Changing fnv to fnv1a has no cryptographic implications. It is merely an efficient hash function with good dispersion characteristics used to scramble DAG indexing. We remain focused on risk mitigation by reducing the need for rigorous cryptographic analysis. ### FNV Primes The 16777639 satisfies all requirements from [Wikipedia](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV_prime). The 16777499 is preferred by FNV authors but not used in the reference FNV implementation because of historical reasons. See [A few remarks on FNV primes](http://www.isthe.com/chongo/tech/comp/fnv/index.html#fnv-prime). ## Copyright This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/). Sun, 26 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1355 https://eips.ethereum.org/EIPS/eip-1355 Payable Token Standards Track/ERC https://github.com/ethereum/eips/issues/1363 ## Simple Summary Defines a token interface for [ERC-20](/EIPS/eip-20) tokens that supports executing recipient code after `transfer` or `transferFrom`, or spender code after `approve`. ## Abstract Standard functions a token contract and contracts working with tokens can implement to make a token Payable. `transferAndCall` and `transferFromAndCall` will call an `onTransferReceived` on a `ERC1363Receiver` contract. `approveAndCall` will call an `onApprovalReceived` on a `ERC1363Spender` contract. ## Motivation There is no way to execute code after a [ERC-20](/EIPS/eip-20) transfer or approval (i.e. making a payment), so to make an action it is required to send another transaction and pay GAS twice. This proposal wants to make token payments easier and working without the use of any other listener. It allows to make a callback after a transfer or approval in a single transaction. There are many proposed uses of Ethereum smart contracts that can accept [ERC-20](/EIPS/eip-20) payments. Examples could be * to create a token payable crowdsale * selling services for tokens * paying invoices * making subscriptions For these reasons it was named as **"Payable Token"**. Anyway you can use it for specific utilities or for any other purposes who require the execution of a callback after a transfer or approval received. This proposal has been inspired by the [ERC-721](/EIPS/eip-721) `onERC721Received` and `ERC721TokenReceiver` behaviours. ## Specification Implementing contracts **MUST** implement the [ERC-1363](/EIPS/eip-1363) interface as well as the [ERC-20](/EIPS/eip-20) and [ERC-165](/EIPS/eip-165) interfaces. ```solidity pragma solidity ^0.8.0; interface ERC1363 /* is ERC20, ERC165 */ { /* * Note: the ERC-165 identifier for this interface is 0xb0202a11. * 0xb0202a11 === * bytes4(keccak256('transferAndCall(address,uint256)')) ^ * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ * bytes4(keccak256('approveAndCall(address,uint256)')) ^ * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) */ /** * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver * @param to address The address which you want to transfer to * @param value uint256 The amount of tokens to be transferred * @return true unless throwing */ function transferAndCall(address to, uint256 value) external returns (bool); /** * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver * @param to address The address which you want to transfer to * @param value uint256 The amount of tokens to be transferred * @param data bytes Additional data with no specified format, sent in call to `to` * @return true unless throwing */ function transferAndCall(address to, uint256 value, bytes memory data) external returns (bool); /** * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver * @param from address The address which you want to send tokens from * @param to address The address which you want to transfer to * @param value uint256 The amount of tokens to be transferred * @return true unless throwing */ function transferFromAndCall(address from, address to, uint256 value) external returns (bool); /** * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver * @param from address The address which you want to send tokens from * @param to address The address which you want to transfer to * @param value uint256 The amount of tokens to be transferred * @param data bytes Additional data with no specified format, sent in call to `to` * @return true unless throwing */ function transferFromAndCall(address from, address to, uint256 value, bytes memory data) external returns (bool); /** * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender * and then call `onApprovalReceived` on spender. * @param spender address The address which will spend the funds * @param value uint256 The amount of tokens to be spent * @return true unless throwing */ function approveAndCall(address spender, uint256 value) external returns (bool); /** * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender * and then call `onApprovalReceived` on spender. * @param spender address The address which will spend the funds * @param value uint256 The amount of tokens to be spent * @param data bytes Additional data with no specified format, sent in call to `spender` * @return true unless throwing */ function approveAndCall(address spender, uint256 value, bytes memory data) external returns (bool); } interface ERC20 { function totalSupply() external view returns (uint256); function balanceOf(address account) external view returns (uint256); function transfer(address recipient, uint256 amount) external returns (bool); function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); function allowance(address owner, address spender) external view returns (uint256); function approve(address spender, uint256 amount) external returns (bool); event Transfer(address indexed from, address indexed to, uint256 value); event Approval(address indexed owner, address indexed spender, uint256 value); } interface ERC165 { function supportsInterface(bytes4 interfaceId) external view returns (bool); } ``` A contract that wants to accept token payments via `transferAndCall` or `transferFromAndCall` **MUST** implement the following interface: ```solidity /** * @title ERC1363Receiver interface * @dev Interface for any contract that wants to support `transferAndCall` or `transferFromAndCall` * from ERC1363 token contracts. */ interface ERC1363Receiver { /* * Note: the ERC-165 identifier for this interface is 0x88a7ca5c. * 0x88a7ca5c === bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)")) */ /** * @notice Handle the receipt of ERC1363 tokens * @dev Any ERC1363 smart contract calls this function on the recipient * after a `transfer` or a `transferFrom`. This function MAY throw to revert and reject the * transfer. Return of other than the magic value MUST result in the * transaction being reverted. * Note: the token contract address is always the message sender. * @param operator address The address which called `transferAndCall` or `transferFromAndCall` function * @param from address The address which are token transferred from * @param value uint256 The amount of tokens transferred * @param data bytes Additional data with no specified format * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` * unless throwing */ function onTransferReceived(address operator, address from, uint256 value, bytes memory data) external returns (bytes4); } ``` A contract that wants to accept token payments via `approveAndCall` **MUST** implement the following interface: ```solidity /** * @title ERC1363Spender interface * @dev Interface for any contract that wants to support `approveAndCall` * from ERC1363 token contracts. */ interface ERC1363Spender { /* * Note: the ERC-165 identifier for this interface is 0x7b04a2d0. * 0x7b04a2d0 === bytes4(keccak256("onApprovalReceived(address,uint256,bytes)")) */ /** * @notice Handle the approval of ERC1363 tokens * @dev Any ERC1363 smart contract calls this function on the recipient * after an `approve`. This function MAY throw to revert and reject the * approval. Return of other than the magic value MUST result in the * transaction being reverted. * Note: the token contract address is always the message sender. * @param owner address The address which called `approveAndCall` function * @param value uint256 The amount of tokens to be spent * @param data bytes Additional data with no specified format * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` * unless throwing */ function onApprovalReceived(address owner, uint256 value, bytes memory data) external returns (bytes4); } ``` ## Rationale The choice to use `transferAndCall`, `transferFromAndCall` and `approveAndCall` derives from the [ERC-20](/EIPS/eip-20) naming. They want to highlight that they have the same behaviours of `transfer`, `transferFrom` and `approve` with the addition of a callback on receiver or spender. ## Backwards Compatibility This proposal has been inspired also by [ERC-223](https://github.com/ethereum/EIPs/issues/223) and [ERC-677](https://github.com/ethereum/EIPs/issues/677) but it uses the [ERC-721](/EIPS/eip-721) approach, so it doesn't override the [ERC-20](/EIPS/eip-20) `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining the [ERC-20](/EIPS/eip-20) backwards compatibility. ## Security Considerations The `approveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard [ERC-20](/EIPS/eip-20) `approve` and `transferFrom` method. Changing an allowance with the `approveAndCall` methods brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards ([EIP-20#issuecomment-263524729](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729)). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 30 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1363 https://eips.ethereum.org/EIPS/eip-1363 Reduced gas cost for call to self Standards Track/Core https://ethereum-magicians.org/t/eip-1380-reduced-gas-cost-for-call-to-self/1242 ## Abstract Reduce the gas cost for call instructions, when the goal is to run a new instance of the currently loaded contract. ## Motivation The current gas cost of 700 for all call types (`CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL`) does not take into account that a call to a contract itself does not need to perform additional I/O operations, because the current contract code has already been loaded into memory. Reducing the call-to-self gas cost would greatly benefit smart contract languages, such as Solidity and Vyper, who would then be able to utilise `CALL` instead of `JUMP` opcodes for internal function calls. While languages can already utilise `CALL` for internal function calls, they are discouraged to do so due to the gas costs associated with it. Using `JUMP` comes at a considerable cost in complexity to the implementation of a smart contract language and/or compiler. The context (including stack and memory) must be swapped in and out of the calling functions context. A desired feature is having *pure* functions, which do not modify the state of memory, and realising them through `JUMP` requires a bigger effort from the compiler as opposed to being able to use `CALL`s. Using call-to-self provides the guarantee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both contract writers and contract consumers against potentially undetected edge cases were memory could poison the context of the internal function. Because of the `JUMP` usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerably faster, if nested function calls with many in and/or outputs are required. Reducing the gas cost, and thereby incentivising of using call-to-self instead of `JUMP`s for the internal function implementation will also benefit static analyzers and tracers. ## Specification If `block.number >= FORK_BLKNUM`, then decrease the cost of `CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL` from 700 to 40, if and only if, the destination address of the call equals to the address of the caller. ## Rationale EIP150 has increased the cost of these instructions from 40 to 700 to more fairly charge for loading new contracts from disk, e.g. to reflect the I/O charge more closely. By assuming that 660 is the cost of loading a contract from disk, one can assume that the original 40 gas is a fair cost of creating a new VM instance of an already loaded contract code. ## Backwards Compatibility This should pose no risk to backwards compatibility. Currently existing contracts should not notice the difference, just see cheaper execution. With EIP150 contract (and language) developers had a lesson that relying on strict gas costs is not feasible as costs may change. The impact of this EIP is even less that of EIP150 because the costs are changing downwards and not upwards. ## Test Cases TBA ## Implementation TBA ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 31 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1380 https://eips.ethereum.org/EIPS/eip-1380 Attestation management contract Standards Track/ERC https://github.com/ethereum/EIPs/issues/1386 ### Introduction Very often, we will need to use Attestations like "Alice lives in Australia" on the blockchain; that is issued by a valid issuer off chain for privacy reasons and is revokable inside a smart contract. An issuer can create a smart contract where he revokes multiple attestations in one go by building a bloom filter of all the hashes of the revoked attestations. An issuer can also put the validation method in their smart contract that can be called by other smart contracts who need to validate attestations issued by them. This allows each attestor to update their attestation format separately. ### Purpose This ERC provides an interface for attestation issuers to manage their attestation signing keys and the attestations that are issued off chain for actions such as revocation and validation. In our draft implementation we include functions to hold cryptographic attestations, change the issuing contracts of attestations, revoke attestations and verify the authenticity of a cryptographic attestation. ### Example use cases Let's say that our friend, Alice, wants to buy a bottle of wine to consume with her friends. She wants to do the order online and have it delivered to her home address whilst paying for it with Ether. Alice has a cryptographic attestation from her local road and maritime services who attests to her age, date of birth, country of residence and ability to drive. Alice is able to split up this attestation (see merkle tree attestations ERC [here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/lib/MerkleTreeAttestation.sol)) and provides only the leaf that states she is over the age of 21. Alice goes to buy the wine through the wine vendors smart contract and feeds in the merkle tree attestation proving that she is above 21 and can thus buy the wine, whilst attaching the appropriate amount of ether to complete the purchase. The issuer smart contract is able to validate her attestation, check that the issuer contract is valid and capable of performing such an attestation to her age. In this case it would have to be from someone like a driver's licence authority, as attestations to age from a school ID are not of a high enough capacity. The wine vendors smart contract validates the attestation, checks the payment amount is correct and credits Alice with the wine tokens she needs to complete the sale and deliver the wine. When the wine vendor shows up to her apartment with the wine, there is no need to prove her age again. ### Draft interface ```solidity /* each attestation issuer should provide their own verify() for the * attestations they issued. There are two reasons for this. First, we * need to leave room for new attestation methods other than the * Merkle Tree format we are recommending. Second, the validity of the * attestation may depend on the context that only the attestor * knows. For example, a ticket as an attestation issued on a * successful redemption of an American Express credit */ contract Issuer { struct Attestation { bytes32[] merklePath; bool valid; uint8 v; bytes32 r; bytes32 s; address attestor; address recipient; bytes32 salt; bytes32 key; bytes32 val; }` /* Verify the authenticity of an attestation */ function verify(Attestation attestation); function addattestorKey(address newAttestor, string capacity, uint expiry); /* this should call the revoke first */ function replaceKey(address attestorToReplace, string capacity, uint expiry, address newAttestor); /* this revokes a single key */ function removeKey(address attestor); /* if the key exists with such capacity and isn't revoked or expired */ function validateKey(address attestor, string capacity) returns (bool); /* revoke an attestation by replace the bloom filter, this helps preserve privacy */ function revokeAttestations(Bloomfilter b); } ``` Please click [here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/example-james-squire/james-squire.sol) to see a draft implementation of this interface ### Related ERC's #1388 #1387 Sat, 08 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1386 https://eips.ethereum.org/EIPS/eip-1386 Merkle Tree Attestations with Privacy enabled Standards Track/ERC https://github.com/ethereum/EIPs/issues/1387 ### Introduction It's often needed that an Ethereum smart contract must verify a claim (I live in Australia) attested by a valid attester. For example, an ICO contract might require that the participant, Alice, lives in Australia before she participates. Alice's claim of residency could come from a local Justice of the Peace who could attest that "Alice is a resident of Australia in NSW". Unlike previous attempts, we assume that the attestation is signed and issued off the blockchain in a Merkle Tree format. Only a part of the Merkle tree is revealed by Alice at each use. Therefore we avoid the privacy problem often associated with issuing attestations on chain. We also assume that Alice has multiple signed Merkle Trees for the same factual claim to avoid her transactions being linkable. ## Purpose This ERC provides an interface and reference implementation for smart contracts that need users to provide an attestation and validate it. ### Draft implementation ```solidity contract MerkleTreeAttestationInterface { struct Attestation { bytes32[] merklePath; bool valid; uint8 v; bytes32 r; bytes32 s; address attester; address recipient; bytes32 salt; bytes32 key; bytes32 val; } function validate(Attestation attestation) public returns(bool); } ``` ### Relevant implementation examples [Here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/lib/MerkleTreeAttestation.sol) is an example implementation of the MerkleTreeAttestationInterface [Here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/example-james-squire/james-squire.sol) is an example service which would use such a merkle tree attestation ### Related ERC's #1388 #1386 Sat, 08 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1387 https://eips.ethereum.org/EIPS/eip-1387 Attestation Issuers Management List Standards Track/ERC https://github.com/ethereum/EIPs/issues/1388 ### Introduction In smart contracts, we will need methods to handle cryptographic attestations to a users identifier or abilities. Let's say we have a real estate agent, KiwiRealtors, that provides an "expression of interest" function though a smart contract and requires the users to provide an attestation that they are a resident of New Zealand or Australia, as a legal requirement. This has actually happened in the New Zealand property market and it is the perfect example of a need to handle such attestations. However, it is not practical for a smart contract to explicitly trust an attestation issuer. There are multiple issuers who can provide an attestation to a person's residency - a local Justice of the Peace, the land title office, local police, passport authority etc. We envision a model where the effort to manage the list of qualified issuers is practically outsourced to a list. Anyone can publish a list of issuers. Only the most trusted and carefully maintained lists gets popular use. ### Purpose This ERC provides a smart contract interface for anyone to manage a list of attestation issuers. A smart contract would explicitly trust a list, and therefore all attestations issued by the issuers on the list. ### Draft implementation ```solidity /* The purpose of this contract is to manage the list of attestation * issuer contracts and their capacity to fulfill requirements */ contract ManagedListERC { /* a manager is the steward of a list. Only he/she/it can change the * list by removing/adding attestation issuers to the list. * An issuer in the list is represented by their contract * addresses, not by the attestation signing keys managed by such a * contract. */ struct List { string name; string description; // short description of what the list entails string capacity; // serves as a filter for the attestation signing keys /* if a smart contract specifies a list, only attestation issued * by issuers on that list is accepted. Furthermore, if that * list has a non-empty capacity, only attestations signed by a * signing key with that capacity is accepted. */ address[] issuerContracts; // all these addresses are contracts, no signing capacity uint expiry; } // find which list the sender is managing, then add an issuer to it function addIssuer(address issuerContractAddress) public; //return false if the list identified by the sender doesn't have this issuer in the list function removeIssuer(address issuerContractAddress, List listToRemoveIssuerFrom) public returns(bool); /* called by services, e.g. Kiwi Properties or James Squire */ /* loop through all issuer's contract and execute validateKey() on * every one of them in the hope of getting a hit, return the * contract address of the first hit. Note that there is an attack * method for one issuer to claim to own the key of another which * is mitigated by later design. */ //loop through the issuers array, calling validate on the signingKeyOfAttestation function getIssuerCorrespondingToAttestationKey(bytes32 list_id, address signingKeyOfAttestation) public returns (address); /* for simplicity we use sender's address as the list ID, * accepting these consequences: a) if one user wish to maintain * several lists with different capacity, he or she must use a * different sender address for each. b) if the user replaced the * sender's key, either because he or she suspects the key is * compromised or that it is lost and reset through special means, * then the list is still identified by the first sender's * address. */ function createList(List list) public; /* replace list manager's key with the new key */ function replaceListIndex(List list, address manager) public returns(bool); } ``` Click [here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/trustlist/ManagedList.sol) to see an example implementation of this ERC ### Related ERC's #1387 #1386 Sat, 08 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1388 https://eips.ethereum.org/EIPS/eip-1388 Poll Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1417 ## Note to Readers 1. We have created a couple of implementations of polls for varied use cases. Please refer to them [here](https://github.com/chaitanyapotti/Voting) ## Simple Summary A standard interface for Polls to be used with EIP-1261 (MVT). ## Abstract The following standard allows for the implementation of a standard API for polls to be used with MVTs (refer [EIP-1261](/EIPS/eip-1261)). The standard provides basic functionality to vote, unvote, tally votes, get voter turnout, and a lot more. The poll standard attempts to modularize blockchain voting by breaking down a poll into 4 crucial building blocks: voterbase qualification, vote weight calculation, vote consequences, and vote tallying. By creating a common interface for polls that have different kinds of building blocks, the poll standard makes it possible to make interactive front end applications which can seamlessly get data from a poll contract in order to bring transparency into consensus and decision making on the blockchain. We considered the usage of polls with MVTs because MVTs serve as a permissioning mechanism. The manual permissioning of polls allows for vote weightage functions to take up several shapes and forms. Hence the voterbase function applies several logical checks on the vote sender to confirm that they are member(see EIP 1261) of a certain entity or combination of entities. For the specification of the nature of voting, we define the vote weight function. The vote weight function decides how much of vote share each voter will receive and this can be based on several criteria, some of which are listed below in this article. There are certain kinds of polls that enforce certain consequences on the voter, for example a poll may require a voter to lock in a certain amount of tokens, or require the voter to pay a small fee. These on-chain consequences can be coded into the consequence module of the poll standard. Finally, the last module is where the votes are added. A ballot for each candidate is updated whenever relevant, depending on the vote value, and the corresponding NoV count(number of voters). This module is common for most polls, and is the most straightforward. Polls may be time bound, ie. having a finish time, after which no votes are recorded, or be unbound, such that there is no finish time. The following are some examples of specific polls which leverage the flexibility of the poll standard, and it is possible to come up with several others: - Plurality Voting: The simplest form of voting is when you want all eligible voters to have one vote per person. This is the simplest to code, as the vote weight is 1, and there is no vote consequence. The only relevant module here is the voterbase, which can be categorized by one or more MVT contracts. - Token proportional voting: This kind of a poll is actually possible without the use of a voterbase function, because the vote weight function having token proportionality automatically rules out addresses which don't hold the appropriate ERC - 20/ ERC - 777 token. However the voterbase function may be leveraged to further permission the system and give voting rights only to a fixed subset of token holders. - Capped Token Proportional Voting: This is a modified version of the previous example, where each voter is given proportional vote share only until a certain limit of token ownership. After exceeding that limit, holding more coins does not add more vote share. This format leverages the voterbase module effectively, disallowing people from spreading their coins across multiple addresses by allowing the admin to control which addresses can vote. - Delegated Voting: Certain polls may allow voters to delegate their votes to other voters. This is known as delegated voting or liquid democracy. For such a poll, a complicated vote weight function is needed, and a data structure concerning the voterbase is also required. A consequence of voting here would be that a user cannot delegate, and a consequence of delegating is that a user cannot vote. Sample implementation of polls contains an example of this vote scheme. - Karma Based Voting: A certain form of poll may be based on weightage from digital respect. This digital respect would be like a simple upvote from one member of voterbase to another. A mapping of mappings along with an appropriate vote weight function can serve this purpose. Sample implementation has an example. - Quadratic voting: A system where each vote is associated with a fee, and the fee is proportional to the square of the vote weight that the voter wants. This can be designed by applying a vote weight based on the transaction message, and then charging a fee in the vote consequence module. The poll standard is intended to be a smart contract standard that makes poll deployment flexible, transparent and accessible. ## Motivation A standard interface allows any user or applications to work with any Poll contract on Ethereum. We provide for simple ERC-1417 smart contracts. Additional applications are discussed below. This standard is inspired by the lack of governance tools in the blockchain space. Whenever there is a consensus collection exercise, someone goes ahead and deploys some kind of poll, and there is no standard software for accessing the data on the poll. For an end user who is not a developer, this is a real problem. The poll, which might be fully transparent, appears to be completely opaque to a common user who does not understand blockchain. In order for developers to build applications for interacting with and accessing poll data, and for poll deployers to have ready application level support, there must be a standardization of poll interfaces. This realization happened while conducting market research on DAICOs. The first ever DAICO, Abyss, had far from optimal user experience, and abysmal transparency. Since then, we have been working on a poll standard. During the process, we came across EIP 1202, the voting standard, and found that the discussion there had already diverged from our thoughts to an extent that it made sense to publish a separate proposal altogether. Some of the benefits brought by the poll standard - EIP 1417 aims to offer some additional benefits. 1. Modularization: EIP 1417 modularizes the code present in the poll standard into 4 major building blocks based on functionality. These are: voterbase logic, vote weight calculation, vote consequence processing, and tallying module. This makes it easy for developers to change parts of a poll without disrupting other parts, and also helps people understand better, code written in the same format by other people. 2. Permissioning: Permissioning is an important aspect of polls, and is missing in most poll proposals so far, on the blockchain. For some reason, most blockchain based polls seem to consider token holding as the only way to permission a poll. However this hampers flexibility, and hence our poll standard is leveraging EIP 1261 in order to clear the permissioning hurdle. Not only does it allow for more creative poll structures in terms of vote weightage, but even improves the flexibility in permissioning by allowing developers to combine several entities and read attributes from entities. 3. Flexibility: The vote weight module of the poll standard can be used effectively to design various kinds of poll contracts which function differently and are suited to different environments. Some examples are quadratic voting, karma voting, delegated voting, token based voting, and one person one vote systems. These schemes are possible due to the separation of voterbase creation and vote weight calculation. 4. NoV Counts: Several weighted polls have struggled to provide proper transparency because they only show the final result without enough granularity. This is because they do not store the number of voters that have voted for each proposal, and only store the total accrued vote for each option. EIP 1417 solves this by additionally recording number of voters(NoV) in each proposal. This NoV count is redundant in the case of one person one vote, but elsewhere, it is helpful in figuring out concentration of power. This ensures that malicious parties can be traced to a larger extent. 5. Event Logging: The poll standard logs an event during a successful vote, unsuccessful vote, and a successful unvote. This is being done so that in the event of a malicious admin removing real members or adding fake members, communities can build tools in order to perform advanced audits and simulate results in the absence of the malicious attack. Such advanced features are completely absent in most polls, and hence, it is hard to investigate such polls. 6. Pollscan.io: The Electus foundation is working on a web based application for accessing and interacting with poll data on the blockchain, it will be deployed on the domain name www.pollscan.io in the coming months. All that being said, we are very excited to share our proposal with the community and open up to suggestions in this space. ### Benefits 1. Building applications (pollscan.io) on top of a standardized voting interface enables transparency and encourage more DAO/DAICO's to act responsibly in terms of governance 2. Create Action contracts which take actions programmatically based on the result of a poll 3. Allow the compatibility with token standard such as [ERC-20](/EIPS/eip-20) or (./eip-777.md)) and membership standard such as [EIP-1261](/EIPS/eip-1261) 4. Flexibility allows for various voting schemes including but not limited to modern schemes such as PLCR Voting ### Use-cases: Polls are useful in any context of collective decision making, which include but aren't limited to: 1. Governing public resources, like ponds, playgrounds, streets etc 2. Maintaining fiscal policy in a transparent consensus driven manner 3. Governing crowdfunded projects - refer DAICO, Vitalik Buterin 4. Implementation of Futarchy 5. Decision making in political parties, and municipal corporations 6. Governing expenditure of a cryptocurrency community ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. **Every ERC-1417 compliant contract must implement the `ERC1417` and `ERC165` interfaces** (subject to "caveats" below): ```solidity /// @title ERC-1417 Poll Standard /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1417.md /// Note: the ERC-165 identifier for this interface is 0x4fad898b. interface IPoll { /// @dev This emits when a person tries to vote without permissions. Useful for auditing purposes. /// E.g.: To prevent an admin to revoke permissions; calculate the result had they not been removed. /// @param _from User who tried to vote /// @param _to the index of the proposal he voted to /// @param voteWeight the weight of his vote event TriedToVote(address indexed _from, uint8 indexed _to, uint voteWeight); /// @dev This emits when a person votes successfully /// @param _from User who successfully voted /// @param _to the index of the proposal he voted to /// @param voteWeight the weight of his vote event CastVote(address indexed _from, uint8 indexed _to, uint voteWeight); /// @dev This emits when a person revokes his vote /// @param _from User who successfully unvoted /// @param _to the index of the proposal he unvoted /// @param voteWeight the weight of his vote event RevokedVote(address indexed _from, uint8 indexed _to, uint voteWeight); /// @notice Handles the vote logic /// @dev updates the appropriate data structures regarding the vote. /// stores the proposalId against the user to allow for unvote /// @param _proposalId the index of the proposal in the proposals array function vote(uint8 _proposalId) external; /// @notice Handles the unvote logic /// @dev updates the appropriate data structures regarding the unvote function revokeVote() external; /// @notice gets the proposal names /// @dev limit the proposal count to 32 (for practical reasons), loop and generate the proposal list /// @return the list of names of proposals function getProposals() external view returns (bytes32[]); /// @notice returns a boolean specifying whether the user can vote /// @dev implement logic to enable checks to determine whether the user can vote /// if using eip-1261, use protocol addresses and interface (IERC1261) to enable checking with attributes /// @param _to the person who can vote/not /// @return a boolean as to whether the user can vote function canVote(address _to) external view returns (bool); /// @notice gets the vote weight of the proposalId /// @dev returns the current cumulative vote weight of a proposal /// @param _proposalId the index of the proposal in the proposals array /// @return the cumulative vote weight of the specified proposal function getVoteTally(uint _proposalId) external view returns (uint); /// @notice gets the no. of voters who voted for the proposal /// @dev use a struct to keep a track of voteWeights and voterCount /// @param _proposalId the index of the proposal in the proposals array /// @return the voter count of the people who voted for the specified proposal function getVoterCount(uint _proposalId) external view returns (uint); /// @notice calculates the vote weight associated with the person `_to` /// @dev use appropriate logic to determine the vote weight of the individual /// For sample implementations, refer to end of the eip /// @param _to the person whose vote weight is being calculated /// @return the vote weight of the individual function calculateVoteWeight(address _to) external view returns (uint); /// @notice gets the leading proposal at the current time /// @dev calculate the leading proposal at the current time /// For practical reasons, limit proposal count to 32. /// @return the index of the proposal which is leading function winningProposal() external view returns (uint8); /// @notice gets the name of the poll e.g.: "Admin Election for Autumn 2018" /// @dev Set the name in the constructor of the poll /// @return the name of the poll function getName() external view returns (bytes32); /// @notice gets the type of the Poll e.g.: Token (XYZ) weighted poll /// @dev Set the poll type in the constructor of the poll /// @return the type of the poll function getPollType() external view returns (bytes32); /// @notice gets the logic to be used in a poll's `canVote` function /// e.g.: "XYZ Token | US & China(attributes in erc-1261) | Developers(attributes in erc-1261)" /// @dev Set the Voterbase logic in the constructor of the poll /// @return the voterbase logic function getVoterBaseLogic() external view returns (bytes32); /// @notice gets the start time for the poll /// @dev Set the start time in the constructor of the poll as Unix Standard Time /// @return start time as Unix Standard Time function getStartTime() external view returns (uint); /// @notice gets the end time for the poll /// @dev Set the end time in the constructor of the poll as Unix Time or specify duration in constructor /// @return end time as Unix Standard Time function getEndTime() external view returns (uint); /// @notice returns the list of entity addresses (eip-1261) used for perimissioning purposes. /// @dev addresses list can be used along with IERC1261 interface to define the logic inside `canVote()` function /// @return the list of addresses of entities function getProtocolAddresses() external view returns (address[]); /// @notice gets the vote weight against all proposals /// @dev limit the proposal count to 32 (for practical reasons), loop and generate the vote tally list /// @return the list of vote weights against all proposals function getVoteTallies() external view returns (uint[]); /// @notice gets the no. of people who voted against all proposals /// @dev limit the proposal count to 32 (for practical reasons), loop and generate the vote count list /// @return the list of voter count against all proposals function getVoterCounts() external view returns (uint[]); /// @notice For single proposal polls, returns the total voterbase count. /// For multi proposal polls, returns the total vote weight against all proposals /// this is used to calculate the percentages for each proposal /// @dev limit the proposal count to 32 (for practical reasons), loop and generate the voter base denominator /// @return an integer which specifies the above mentioned amount function getVoterBaseDenominator() external view returns (uint); } ``` ### Caveats The 0.4.24 Solidity interface grammar is not expressive enough to document the ERC-1417 standard. A contract which complies with ERC-1417 MUST also abide by the following: - Solidity issue #3412: The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: `payable`, implicit nonpayable, `view`, and `pure`. Your implementation MUST meet the mutability guarantee in this interface and you MAY meet a stronger guarantee. For example, a `payable` function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.24 is that you can edit this interface to add stricter mutability before inheriting from your contract. - Solidity issue #2330: If a function is shown in this specification as `external` then a contract will be compliant if it uses `public` visibility. As a workaround for version 0.4.24, you can edit this interface to switch to `public` before inheriting from your contract. _If a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification._ ## Rationale As the poll standard is built with the intention of creating a system that allows for more transparency and accessibility of governance data, the design choices in the poll standard are driven by this motivator. In this section we go over some of the major design choices, and why these choices were made: 1. Event logging: The logic behind maintaining event logs in the cases of: - Cast Vote - Unvote - Failed Vote is to ensure that in the event of a manipulated voterbase, simple off chain checks can be performed to audit the integrity of the poll result. 2. No poll finish trigger: There was a consideration of adding functions in the poll which execute after completion of the poll to carry out some pre-decided logic. However this was deemed to be unnecessary - because such an action can be deployed in a separate contract which simply reads the result of a given poll, and against the spirit of modularity, because no actions can be created after the poll has been deployed. Also, such functions would not be able to combine the results of polls, and definitely would not fit into polls that do not have an end time. 3. Allow for unbound polls: The poll standard, unlike other voting standard proposals, does not force polls to have an end time. This becomes relevant in some cases where the purpose of a poll is to have a live register of ongoing consensus. Some other use cases come into picture when you want to deploy a set of action contracts which read from the poll, and want to be able to execute the action contract whenever a poll reaches a certain threshold, rather than waiting for the end of the poll. 4. Modularization: There have been opinions in the Ethereum community that there cannot exist a voting standard, because voting contracts can be of various types, and have several shapes and forms. However we disagree, and make the case that modularization is the solution. While different polls may need different logic, they all need consistent end points. All polls need to give out results along with headcounts, all polls should have event logs, all polls should be examinable with frontend tools, and so on. The poll standard is not a statement saying “all polls should be token based” or any such specific system. However the poll standard is a statement saying that all polls should have a common access and modification protocol - this will enable more apps to include governance without having to go through the trouble of making customers start using command line. Having explained our rationale, we are looking forward to hearing from the community some thoughts on how this can be made more useful or powerful. **Gas and Complexity** (regarding the enumeration for proposal count) This specification contemplates implementations that contain a sample of 32 proposals (max up to blockgaslimit). If your application is able to grow and needs more than 32 proposals, then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound **Privacy** Personal information: The standard does not put any personal information on to the blockchain, so there is no compromise of privacy in that respect. **Community Consensus** We have been very inclusive in this process and invite anyone with questions or contributions into our discussion. However, this standard is written only to support the identified use cases which are listed herein. ## Test Cases Voting Standard includes test cases written using Truffle. ## Implementations Voting Standard -- a reference implementation - MIT licensed, so you can freely use it for your projects - Includes test cases - Also available as a npm package - npm i electusvoting ## References **Standards** - [EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)](/EIPS/eip-20) - [EIP-165: Standard Interface Detection](/EIPS/eip-165) - [EIP-721: Non-Fungible Token Standard(a.k.a. ERC-721)](/EIPS/eip-721) - [ERC-1261 MV Token Standard](/EIPS/eip-1261) - [RFC 2119 Key words for use in RFCs to Indicate Requirement Levels](https://www.ietf.org/rfc/rfc2119.txt) **Issues** 1. The Original ERC-1417 Issue. https://github.com/ethereum/eips/issues/1417 1. Solidity Issue \#2330 -- Interface Functions are Axternal. https://github.com/ethereum/solidity/issues/2330 1. Solidity Issue \#3412 -- Implement Interface: Allow Stricter Mutability. https://github.com/ethereum/solidity/issues/3412 1. Solidity Issue \#3419 -- Interfaces Can't Inherit. https://github.com/ethereum/solidity/issues/3419 **Discussions** 1. ERC-1417 (announcement of first live discussion). https://github.com/ethereum/eips/issues/1417 **Voting Implementations and Other Projects** - [Voting Implementations](https://github.com/chaitanyapotti/Voting) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 16 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1417 https://eips.ethereum.org/EIPS/eip-1417 Blockchain Storage Rent Payment Standards Track/Core https://ethereum-magicians.org/t/eip-1418-storage-rent/10737 ## Abstract At each block, deduct an amount of value ("rent") from every account based on the quantity of storage used by that account. ## Motivation Ethereum is a public utility and we are underpricing the long-term costs of storage. Storage cost can be approximately modeled as bytes × time. ## Specification **Updated transaction type** A new transaction type is introduced. Whereas [EIP-1559](/EIPS/eip-1559) introduced warm access for contract state, this new type introduces warm access for contract code. **New state variables (per account)** * **σ[a]_rent** -- an amount of value, in Wei, this is a signed value * **σ[a]_storageWords** -- number of words in storage **New constants** * **`RENT_WORD_COST`** -- The rent cost, in Wei, paid for each word-block * **`RENT_ACCOUNT_COST`** -- The rent cost, in Wei, paid for each account-block * **`FORK_BLOCK`** – When implementation starts **New opcodes** * **`RENTBALANCE(address)`** -- G_BALANCE -- Similar to `BALANCE` * This returns the logical `σ[a]_rent` value which is defined to reduce each block. It is possible for the implementation to calculate this value using the recommended implementation variables, rather than storing and updating `σ[a]_rent` every block for every account. * **`SENDRENT(address, amount)`** -- G_BASE -- Convert value to rent and send to account 1. `σ[account]_rent` += amount 2. `σ[msg.sender]_balance` -= amount **Updated opcodes** A new subroutine, paying for rent, is established as such: ```pseudocode PAYRENT(account) blocks_to_pay = NUMBER - σ[account]_rentLastPaid cost_per_block = RENT_ACCOUNT_COST + RENT_WORD_COST * (⌈∥σ[account]_code∥ / 32⌉ + * σ[a]_storageWords) rent_to_pay = blocks_to_pay * cost_per_block σ[account]_rent -= rent_to_pay if σ[account]_rent < 0 σ[account]_value += σ[account]_rent σ[account]_rent = 0 end if σ[account]_value < 0 σ[account]_rent = σ[account]_value σ[account]_value = 0 end σ[account]_rentLastPaid = NUMBER σ[account]_rentEvictBlock = NUMBER + ⌊σ[account]_rent / cost_per_block⌋ END PAYRENT ``` * **`SSTORE(account, key, value)`** * Perform PAYRENT(account) * If `account` is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless using the new transaction type and sufficient proofs are included to validate the old storage root and calculate the new root. * Do normal SSTORE operation * If the old value was zero for this [account, key] and the new value is non-zero, then `σ[account]_storageWords++` * If the old value was non-zero for this [account, key] and the new value is zero, then `σ[account]_storageWords--`, and if the result is negative then set to zero * **`SLOAD(account, key)`** * If `account` is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless using the new transaction type and sufficient proofs are included to validate the existing storage root and the existing storage value. * Do normal SLOAD operation. * **`CALL (and derivatives)`** * If the target block is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless using the new transaction type and sufficient proof is included to validate the existing code. * Do normal CALL operation * **`CREATE`** * Set σ[account]_rentLastPaid = NUMBER * Do normal CREATE operation * `σ[account]_storageWord = 0` * Note: it is possible there is a pre-existing rent balance here **New built-in contract** * `PAYRENT(address, amount)` -- Calls `PAYRENT` opcode * This is a convenience for humans to send Ether from their accounts and turn it into rent. Note that simple accounts (CODESIZE == 0) cannot call arbitrary opcodes, they can only call CREATE or CALL. * The gas cost of PAYRENT will be 10,000 or lower if possible. **Calculating `σ[account]_storageWord` for existing accounts** DRAFT... It is not an acceptable upgrade if on the fork block it is necessary for only archive nodes to participate which know the full storage amount for each account. An acceptable upgrade will be if the required `σ[account]_storageWord` can be calculated (or estimated) incrementally based on new transaction activity. DRAFT: I think it is possible to make such an acceptable upgrade using an unbiased estimator * add one bit of storage per `SSTORE` for legacy accounts on the first access of a given key * add log(n) bits for each trie level * assume that storage keys are a random variable To think more about... **No changes to current opcode gas costs.** ## Rationale **No call** A contract will not know or react to the receipt of rent. This is okay. Workaround: if a contract really needed to know who provided rent payments then it could create a function in its ABI to attribute these payments. It is already possible to send payments to a contract without attribution by using `SELFDESTRUCT`. Other blockchains like TRON allow to transfer value to a contract without performing a call. **Eviction responsibility / lazy evaluation** The specification gives responsibility for eviction to the consensus clients. This is the most predictable behavior because it happens exactly when it should. Also there need not be any incentive mechanism (refund gas, bounty) for outside participants (off-chain) to monitor accounts and request removal. It is possible that an arbitrary number of accounts will be evicted in one block. That doesn't matter. Client implementations do not need to track which accounts are evicted, consensus is achieved just by agreeing on the conditions under which an account would be evicted. **No converting rent to value** Ether converted to rent cannot be converted back. Anybody that works in accounting and knows about gifts cards should tell you this is a good idea. It makes reasoning about the system much easier. **Accounts pay rent** Yes, they pay rent. It costs resources to account for their balances so we charge them rent. **Why do you need a separate rent account?** Because anybody/everybody can contribute to the rent account. If you depend on a contract, you should contribute to its rent. But the contract can spend all of its value. By maintaining a separate rent and value balance, this allows people to contribute to the rent while being confident that this is allowing the contract to stay around. NOTE: cloning. With this EIP, it may become feasible to allow storage cloning. Yes really. Because the new clone will be paying rent. See other EIP, I think made by Augur team. ### Economics & constants An `SSTORE` executed in 2015 cost 20,000 gas and has survived about 6 million blocks. The gas price has been around 1 ~ 50 Gwei. So basically 4,000 Wei per block per word so far. Maybe storing an account is 10 times more intensive than storing a word. But actually `G_transaction` is 21,000 and `G_sstore` is 20,000 so these are similar and they can both create new accounts / words. How about: * `RENT_WORD_COST` -- 4,000 Wei * `RENT_ACCOUNT_COST` -- 4,000 Wei * `FORK_BLOCK` – when implementation starts The rent is priced in cold, hard Ether. It is not negotiated by clients, it is not dynamic. A future EIP may change this pricing to be dynamic. For example to notarize a block, notaries may be required to prove they have the current storage dataset (excluding evictions). Additionally, they may also prove they have the dataset plus evictions to earn an additional fee. The relative storage of the evicted accounts, and the other accounts versus the value of the additional fee may be used as a feedback mechanism to set a market price for storage. FYI, there are about 15B words in the Ethereum Mainnet dataset and about 100M total Ether mined. This means if all Ether was spent on storage at current proposed prices it would be 400 terabyte-years of storage. I'm not sure if it is helpful to look at it that way. ## Backwards Compatibility EIP-1559 already introduces a mechanism for nodes to participate without recording the full network state and for clients to warm cache with storage data in their type 2 transactions. Users will need to be educated. Many smart contracts allow anybody to use an arbitrary amount of storage in them. This can limit the usefulness of deploying this proposal on an existing chain. **Recommended implementation variables (per account)** * **σ[a]_rentLastPaid** -- a block number that is set when: * Value is transferred into an account (`CREATE`, `CALL`, `SELFDESTRUCT`) * Code is set for an account (`CREATE`) * An account's storage is updated (`SSTORE`) * This begins with a logical value of `FORK_BLOCK` for all accounts * **σ[a]_rentEvictBlock** -- the block number when this account will be evicted **Storage note** For every account that is evicted, clients may choose to delete that storage from disk. A future EIP may make an incentive to keep this extra data for a fee. A future EIP may create a mechanism for clients to exchange information about these storage states. ## Security Considerations Many smart contracts allow anybody to use an arbitrary amount of storage in them. ## Copyright Copyright and related rights waived via CC0. <!-- ## TODO To discuss: - Can/should an evicted account be allowed to be un-evicted when paying past due rent? --> Sun, 16 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1418 https://eips.ethereum.org/EIPS/eip-1418 dApp Components (avatar) & Universal Wallet Standards Track/ERC https://ethresear.ch/t/avatar-system-and-universal-wallet-for-ethereum-address/3473 ## Simple Summary Contracts are open source based. And most developers use the public contracts at the start of the project to modify or simply include them. This is project-oriented centralized development and I think it is a waste of resources. Therefore, we propose to make dApp or contracts component-ready for use in other services. ## Abstract There have been suggestions for modified tokens based on erc20, but since many tokens have already been built on erc20, it is necessary to increase the utilization of already developed erc20 tokens. Therefore, we propose a universal wallet that can use erc20 tokens universally. We also propose a component dApp that allows you to create and save your avatar (& social badge system), and use it immediately in other services. All of the dApps suggested in this document are based on decentralized development and use that anyone can create and participate in. ## Motivation While many projects are under development in an open source way, they are simply adding and deploy with open sources to their projects. This means that you are developing a centralized service that uses your own dApp-generated information on your own. In order to improve the block chain ecosystem, all resources created by dApp and placed in the public block chain must be reusable in another dApp. This means that you can enhance your service by exchanging the generated information with other dApp. Likewise, ERC20 Tokens require Universal Wallet standards to be easy to use for direct transactions. ### Seeds for improvement of the blockchain ecosystem. - Synergy - With other dApps and resources. - Enhanced interface - For ERC20 tokens. - Easy & Decentralized - Everyone should be able to add to their services easily, without censorship. #### The following avatar store, badge system, and universal wallet are kind of examples about component dApp. ![intro](/assets/eip-1438/intro.png) ## Specification ### 1. Avatar #### 1.1. Avatar Shop - The avatar store is created after ERC20 currency is set. - You can customize asset category & viewer script. #### 1.2. Upload asset & user data The avatar's information & assets are stored in the event log part of the block chain. - Assets are SVG format. (compressed with gzip) - avatar information data is json (compressed with msgpack) ![avatar](/assets/eip-1438/avatar.png) ** The avatar assets from [Avataaars](https://github.com/fangpenlin/avataaars) developed by [Fang-Pen Lin](https://twitter.com/fangpenlin), the original avatar is designed by [Pablo Stanley](https://twitter.com/pablostanley). ### 2. Universal Wallet ![wallet](/assets/eip-1438/wallet.png) #### 2.1. ERC20 interface ``` js contract ERC20Interface { function totalSupply() public constant returns (uint); function balanceOf(address tokenOwner) public constant returns (uint balance); function allowance(address tokenOwner, address spender) public constant returns (uint remaining); function transfer(address to, uint tokens) public returns (bool success); function approve(address spender, uint tokens) public returns (bool success); function transferFrom(address from, address to, uint tokens) public returns (bool success); event Transfer(address indexed from, address indexed to, uint tokens); event Approval(address indexed tokenOwner, address indexed spender, uint tokens); } ``` #### 2.2. Fixed ERC20 contract for receive approval and execute function in one call ``` js function approveAndCall(address spender, uint tokens, bytes data) public returns (bool success) { allowed[msg.sender][spender] = tokens; emit Approval(msg.sender, spender, tokens); ApproveAndCallFallBack(spender).receiveApproval(msg.sender, tokens, this, data); return true; } ``` #### 2.3. And ApproveAndCallFallBack contract for Fixed ERC20. However, many ERC20 tokens are not prepared. ``` js contract ApproveAndCallFallBack { function receiveApproval(address from, uint256 tokens, address token, bytes data) public; } ``` #### 2.4. Universal Wallet We propose a Universal Wallet to solve this problem. ``` js contract UniversalWallet is _Base { constructor(bytes _msgPack) _Base(_msgPack) public {} function () public payable {} //------------------------------------------------------- // erc20 interface //------------------------------------------------------- function balanceOf(address _erc20) public constant returns (uint balance) { if(_erc20==address(0)) return address(this).balance; return _ERC20Interface(_erc20).balanceOf(this); } function transfer(address _erc20, address _to, uint _tokens) onlyOwner public returns (bool success) { require(balanceOf(_erc20)>=_tokens); if(_erc20==address(0)) _to.transfer(_tokens); else return _ERC20Interface(_erc20).transfer(_to,_tokens); return true; } function approve(address _erc20, address _spender, uint _tokens) onlyOwner public returns (bool success) { require(_erc20 != address(0)); return _ERC20Interface(_erc20).approve(_spender,_tokens); } //------------------------------------------------------- // pay interface //------------------------------------------------------- function pay(address _store, uint _tokens, uint256[] _options) onlyOwner public { address erc20 = _ApproveAndCallFallBack(_store).erc20(); address spender = _ApproveAndCallFallBack(_store).spender(); if(erc20 == address(0)) { transfer(erc20,spender,_tokens); _ApproveAndCallFallBack(_store).receiveApproval(_options); } else { _ERC20Interface(erc20).approve(spender,_tokens); _ApproveAndCallFallBack(_store).receiveApproval(_options); } } function pay(address _store, uint _tokens, bytes _msgPack) onlyOwner public { address erc20 = _ApproveAndCallFallBack(_store).erc20(); address spender = _ApproveAndCallFallBack(_store).spender(); if(erc20 == address(0)) { transfer(erc20,spender,_tokens); _ApproveAndCallFallBack(_store).receiveApproval(_msgPack); } else { _ERC20Interface(erc20).approve(spender,_tokens); _ApproveAndCallFallBack(_store).receiveApproval(_msgPack); } } } ``` ## Test Cases - https://www.nitro888.com - https://github.com/Nitro888/nitro888.github.io - https://github.com/Nitro888/dApp-Alliance ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 21 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1438 https://eips.ethereum.org/EIPS/eip-1438 Localized Messaging with Signal-to-Text Standards Track/ERC https://ethereum-magicians.org/t/eip-1444-localized-messaging-with-signal-to-text/ ## Simple Summary A method of converting machine codes to human-readable text in any language and phrasing. ## Abstract An on-chain system for providing user feedback by converting machine-efficient codes into human-readable strings in any language or phrasing. The system does not impose a list of languages, but rather lets users create, share, and use the localizated text of their choice. ## Motivation There are many cases where an end user needs feedback or instruction from a smart contract. Directly exposing numeric codes does not make for good UX or DX. If Ethereum is to be a truly global system usable by experts and lay persons alike, systems to provide feedback on what happened during a transaction are needed in as many languages as possible. Returning a hard-coded string (typically in English) only serves a small segment of the global population. This standard proposes a method to allow users to create, register, share, and use a decentralized collection of translations, enabling richer messaging that is more culturally and linguistically diverse. There are several machine efficient ways of representing intent, status, state transition, and other semantic signals including booleans, enums and [ERC-1066 codes](/EIPS/eip-1066). By providing human-readable messages for these signals, the developer experience is enhanced by returning easier to consume information with more context (ex. `revert`). End user experience is enhanced by providing text that can be propagated up to the UI. ## Specification ### Contract Architecture Two types of contract: `LocalizationPreferences`, and `Localization`s. The `LocalizationPreferences` contract functions as a proxy for `tx.origin`. ```diagram +--------------+ | | +------> | Localization | | | | | +--------------+ | | +-----------+ +-------------------------+ | +--------------+ | | | | <------+ | | | Requestor | <------> | LocalizationPreferences | <-------------> | Localization | | | | | <------+ | | +-----------+ +-------------------------+ | +--------------+ | | | +--------------+ | | | +------> | Localization | | | +--------------+ ``` ### `Localization` A contract that holds a simple mapping of codes to their text representations. ```solidity interface Localization { function textFor(bytes32 _code) external view returns (string _text); } ``` #### `textFor` Fetches the localized text representation. ```solidity function textFor(bytes32 _code) external view returns (string _text); ``` ### `LocalizationPreferences` A proxy contract that allows users to set their preferred `Localization`. Text lookup is delegated to the user's preferred contract. A fallback `Localization` with all keys filled MUST be available. If the user-specified `Localization` has not explicitly set a loalization (ie. `textFor` returns `""`), the `LocalizationPreferences` MUST redelegate to the fallback `Localization`. ```solidity interface LocalizationPreferences { function set(Localization _localization) external returns (bool); function textFor(bytes32 _code) external view returns (bool _wasFound, string _text); } ``` #### `set` Registers a user's preferred `Localization`. The registering user SHOULD be considered `tx.origin`. ```solidity function set(Localization _localization) external; ``` #### `textFor` Retrieve text for a code found at the user's preferred `Localization` contract. The first return value (`bool _wasFound`) represents if the text is available from that `Localization`, or if a fallback was used. If the fallback was used in this context, the `textFor`'s first return value MUST be set to `false`, and is `true` otherwise. ```solidity function textFor(bytes32 _code) external view returns (bool _wasFound, string _text); ``` ### String Format All strings MUST be encoded as [UTF-8](https://www.ietf.org/rfc/rfc3629.txt). ```solidity "Špeĉiäl chârãçtérs are permitted" "As are non-Latin characters: アルミ缶の上にあるみかん。" "Emoji are legal: 🙈🙉🙊🎉" "Feel free to be creative: (ﾉ◕ヮ◕)ﾉ*:･ﾟ✧" ``` ### Templates Template strings are allowed, and MUST follow the [ANSI C `printf`](https://pubs.opengroup.org/onlinepubs/009696799/utilities/printf.html) conventions. ```solidity "Satoshi's true identity is %s" ``` Text with 2 or more arguments SHOULD use the POSIX parameter field extension. ```solidity "Knock knock. Who's there? %1$s. %1$s who? %2$s!" ``` ## Rationale ### `bytes32` Keys `bytes32` is very efficient since it is the EVM's base word size. Given the enormous number of elements (card(A) > 1.1579 × 10<sup>77</sup>), it can embed nearly any practical signal, enum, or state. In cases where an application's key is longer than `bytes32`, hashing that long key can map that value into the correct width. Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](/EIPS/eip-1066)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the larger one. ### Local vs Globals and Singletons This spec has opted to not _force_ a single global registry, and rather allow any contract and use case deploy their own system. This allows for more flexibility, and does not restrict the community for opting to use singleton `LocalizationPreference` contracts for common use cases, share `Localization`s between different proxys, delegate translations between `Localization`s, and so on. There are many practical uses of agreed upon singletons. For instance, translating codes that aim to be fairly universal and integrated directly into the broader ecosystem (wallets, frameworks, debuggers, and the like) will want to have a single `LocalizationPreference`. Rather the dispersing several `LocalizationPreference`s for different use cases and codes, one could imagine a global "registry of registries". While this approach allows for a unified lookups of all translations in all use cases, it is antithetical to the spirit of decentralization and freedom. Such a system also increases the lookup complexity, places an onus on getting the code right the first time (or adding the overhead of an upgradable contract), and need to account for use case conflicts with a "unified" or centralized numbering system. Further, lookups should be lightweight (especially in cases like looking up revert text). For these reasons, this spec chooses the more decentralized, lightweight, free approach, at the cost of on-chain discoverability. A registry could still be compiled, but would be difficult to enforce, and is out of scope of this spec. ### Off Chain Storage A very viable alternative is to store text off chain, with a pointer to the translations on-chain, and emit or return a `bytes32` code for another party to do the lookup. It is difficult to guarantee that off-chain resources will be available, and requires coordination from some other system like a web server to do the code-to-text matching. This is also not compatible with `revert` messages. ### ASCII vs UTF-8 vs UTF-16 UTF-8 is the most widely used encoding at time of writing. It contains a direct embedding of ASCII, while providing characters for most natural languages, emoji, and special characters. Please see the [UTF-8 Everywhere Manifesto](https://utf8everywhere.org/) for more information. ### When No Text is Found Returning a blank string to the requestor fully defeats the purpose of a localization system. The two options for handling missing text are: 1. A generic "text not found" message in the preferred language 2. The actual message, in a different language #### Generic Option This designed opted to not use generic fallback text. It does not provide any useful information to the user other than to potentially contact the `Localization` maintainer (if one even exists and updating is even possible). #### Fallback Option The design outlined in this proposal is to providing text in a commonly used language (ex. English or Mandarin). First, this is the language that will be routed to if the user has yet to set a preference. Second, there is a good chance that a user may have _some_ proficiency with the language, or at least be able to use an automated translation service. Knowing that the text fell back via `textFor`s first return field boolean is _much_ simpler than attempting language detection after the fact. This information is useful for certain UI cases. for example where there may be a desire to explain why localization fell back. ### Decentralized Text Crowdsourcing In order for Ethereum to gain mass adoption, users must be able to interact with it in the language, phrasing, and level of detail that they are most comfortable with. Rather than imposing a fixed set of translations as in a traditional, centralized application, this EIP provides a way for anyone to create, curate, and use translations. This empowers the crowd to supply culturally and linguistically diverse messaging, leading to broader and more distributed access to information. ### `printf`-style Format Strings C-style `printf` templates have been the de facto standard for some time. They have wide compatibility across most languages (either in standard or third-party libraries). This makes it much easier for the consuming program to interpolate strings with low developer overhead. #### Parameter Fields The POSIX parameter field extension is important since languages do not share a common word order. Parameter fields enable the reuse and rearrangement of arguments in different localizations. ```solidity ("%1$s is an element with the atomic number %2$d!", "Mercury", 80); // => "Mercury is an element with the atomic number 80!" ``` #### Simplified Localizations Localization text does not require use of all parameters, and may simply ignore values. This can be useful for not exposing more technical information to users that would otherwise find it confusing. ```ruby #!/usr/bin/env ruby sprintf("%1$s é um elemento", "Mercurio", 80) # => "Mercurio é um elemento" ``` ```clojure #!/usr/bin/env clojure (format "Element #%2$s" "Mercury" 80) ;; => Element #80 ``` ### Interpolation Strategy Please note that it is highly advisable to return the template string _as is_, with arguments as multiple return values or fields in an `event`, leaving the actual interpolation to be done off chain. ```solidity event AtomMessage { bytes32 templateCode; bytes32 atomCode; uint256 atomicNumber; } ``` ```javascript #!/usr/bin/env node var printf = require('printf'); const { returnValues: { templateCode, atomCode, atomicNumber } } = eventResponse; const template = await AppText.textFor(templateCode); // => "%1$s ist ein Element mit der Ordnungszahl %2$d!" const atomName = await PeriodicTableText.textFor(atomCode); // => "Merkur" printf(template, atomName, 80); // => "Merkur ist ein Element mit der Ordnungszahl 80!" ``` ### Unspecified Behaviour This spec does not specify: * Public or private access to the default `Localization` * Who may set text * Deployer * `onlyOwner` * Anyone * Whitelisted users * and so on * When text is set * `constructor` * Any time * Write to empty slots, but not overwrite existing text * and so on These are intentionally left open. There are many cases for each of these, and restricting any is fully beyond the scope of this proposal. ## Implementation ```solidity pragma solidity ^0.4.25; contract Localization { mapping(bytes32 => string) private dictionary_; constructor() public {} // Currently overwrites anything function set(bytes32 _code, string _message) external { dictionary_[_code] = _message; } function textFor(bytes32 _code) external view returns (string _message) { return dictionary_[_code]; } } contract LocalizationPreference { mapping(address => Localization) private registry_; Localization public defaultLocalization; bytes32 private empty_ = keccak256(abi.encodePacked("")); constructor(Localization _defaultLocalization) public { defaultLocalization = _defaultLocalization; } function set(Localization _localization) external returns (bool) { registry_[tx.origin] = _localization; return true; } function get(bytes32 _code) external view returns (bool, string) { return get(_code, tx.origin); } // Primarily for testing function get(bytes32 _code, address _who) public view returns (bool, string) { string memory text = getLocalizationFor(_who).textFor(_code); if (keccak256(abi.encodePacked(text)) != empty_) { return (true, text); } else { return (false, defaultLocalization.textFor(_code)); } } function getLocalizationFor(address _who) internal view returns (Localization) { if (Localization(registry_[_who]) == Localization(0)) { return Localization(defaultLocalization); } else { return Localization(registry_[tx.origin]); } } } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 23 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1444 https://eips.ethereum.org/EIPS/eip-1444 ERC-1450 A compatible security token for issuing and trading SEC-compliant securities Standards Track/ERC https://ethereum-magicians.org/t/erc-proposal-ldgrtoken-a-compatible-security-token-for-issuing-and-trading-sec-compliant-securities/1468 # ERC-1450 - A compatible security token for issuing and trading SEC-compliant securities ## Simple Summary `ERC-1450` is an `ERC-20` compatible token that enables issuing tokens representing securities that are required to comply with one or more of the following [Securities Act Regulations: Regulation Crowdfunding, Regulation D, and Regulation A](https://www.sec.gov/smallbusiness/exemptofferings). ## Abstract `ERC-1450` facilitates the recording of ownership and transfer of securities sold in compliance with the [Securities Act Regulations CF, D and A](https://www.sec.gov/smallbusiness/exemptofferings). The issuance and trading of securities is subject to the Securities Exchange Commission (SEC) and specific U.S. state blue sky laws and regulations. `ERC-1450` manages securities ownership during issuance and trading. The Issuer is the only role that should create a `ERC-1450` and assign the RTA. The RTA is the only role that is allowed to execute `ERC-1450`’s `mint`, `burnFrom`, and `transferFrom` functions. No role is allowed to execute `ERC-1450`’s `transfer` function. ## Motivation With the advent of the [JOBS Act](https://www.sec.gov/spotlight/jobs-act.shtml) in 2012 and the launch of Regulation Crowdfunding and the amendments to Regulation A and Regulation D in 2016, there has been an expansion in the exemptions available to Issuers and Investors to sell and purchase securities that have not been "registered" with the SEC under the Securities Act of 1933. There are currently no token standards that expressly facilitate conformity to securities law and related regulations. ERC-20 tokens do not support the regulated roles of Funding Portal, Broker Dealer, RTA, and Investor and do not support the [Bank Secrecy Act/USA Patriot Act KYC and AML requirements](https://www.occ.treas.gov/topics/compliance-bsa/bsa/index-bsa.html). Other improvements (notably [EIP-1404 (Simple Restricted Token Standard)](https://github.com/ethereum/EIPs/issues/1404) have tried to tackle KYC and AML regulatory requirement. This approach is novel because the RTA is solely responsible for performing KYC and AML and should be solely responsible for `transferFrom`, `mint`, and `burnFrom`. ## Specification `ERC-1450` extends `ERC-20`. ### `ERC-1450` `ERC-1450` requires that only the Issuer can create a token representing the security that only the RTA manages. Instantiating the `ERC-1450` requires the `Owned` and `IssuerControlled` modifiers, and only the Issuer should execute the `ERC-1450` constructor for a compliant token. `ERC-1450` extends the general `Ownable` modifier to describe a specific subset of owners that automate and decentralize compliance through the contract modifiers `Owned` and `IssuerControlled` and the function modifiers `onlyOwner` and `onlyIssuerTransferAgent`. The `Owned` contract modifier instantiates the `onlyOwner` modifier for functions. The `IssuerControlled` modifier instantiates the `onlyIssuerTransferAgent` modifier for functions. `ERC-1450` must prevent anyone from executing the `transfer`, `allowance`, and `approve` functions and/or implement these functions to always fail. `ERC-1450` updates the `transferFrom`, `mint`, and `burnFrom` functions. `transferFrom`, `mint`, and `burnFrom` may only be executed by the RTA and are restricted with the `onlyIssuerTransferAgent` modifier. Additionally, `ERC-1450` defines the functions `transferOwnership`, `setTransferAgent`, `setPhysicalAddressOfOperation`, and `isTransferAgent`. Only the issuer may call the `transferOwnership`, `setTransferAgent`, and `setPhysicalAddressOfOperation` functions. Anyone may call the `isTransferAgent` function. ### Issuers and RTAs For compliance reasons, the `ERC-1450` constructor must specify the issuer (the `owner`), the RTA (`transferAgent`), the security’s `name`, and the security’s `symbol`. #### Issuer Owned `ERC-1450` must specify the `owner` in its constructor, apply the `Owned` modifier, and instantiate the `onlyOwner` modifier to enable specific functions to permit only the Issuer’s `owner` address to execute them. `ERC-1450` also defines the function `transferOwnership` which transfers ownership of the Issuer to the new `owner`’s address and can only be called by the `owner`. `transferOwnership` triggers the `OwnershipTransferred` event. #### Issuer Controlled `IssuerControlled` maintains the Issuer’s ownership of their securities by owning the contract and enables the Issuer to set and update the RTA for the Issuer’s securities. `ERC-1450`‘s constructor must have an `IssuerControlled` modifier with the issuer specified in its `ERC-1450` constructor. `IssuerControlled` instantiates the `onlyIssuerTransferAgent` modifier for `ERC-1450` to enable specific functions (`setPhysicalAddressOfOperation` and `setTransferAgent`) to permit only the Issuer to execute these functions. #### Register Transfer Agent Controlled `ERC-1450` defines the `setTransferAgent` function (to change the RTA) and `setPhysicalAddressOfOperation` function (to change the Issuer’s address) and must restrict execution to the Issuer’s owner with the `onlyOwner` modifier. `setTransferAgent` must emit the `TransferAgentUpdated` event. `setPhysicalAddressOfOperation` must emit the `PhysicalAddressOfOperationUpdated` event. `ERC-1450` must specify the `transferAgent` in its constructor and instantiate the `onlyIssuerTransferAgent` modifier to enable specific functions (`transferFrom`, `mint`, and `burnFrom`) to permit only the Issuer’s `transferAgent` address to execute them. `ERC-1450` also defines the public function `isTransferAgent` to lookup and identify the Issuer’s RTA. #### Securities `ERC-1450` updates the `transferFrom`, `mint`, and `burnFrom` functions by applying the `onlyIssuerTransferAgent` to enable the issuance, re-issuance, and trading of securities. ### ERC-20 Extension `ERC-20` tokens provide the following functionality: ```solidity contract ERC20 { function totalSupply() public view returns (uint256); function balanceOf(address who) public view returns (uint256); function transfer(address to, uint256 value) public returns (bool); function allowance(address owner, address spender) public view returns (uint256); function transferFrom(address from, address to, uint256 value) public returns (bool); function approve(address spender, uint256 value) public returns (bool); event Approval(address indexed owner, address indexed spender, uint256 value); event Transfer(address indexed from, address indexed to, uint256 value); } ``` `ERC-20` is extended as follows: ```solidity /** * ERC-1450 is an ERC-20 compatible token that facilitates compliance with one or more of Securities Act Regulations CF, D and A. * * Implementations of the ERC-1450 standard must define the following optional ERC-20 * fields: * * name - The name of the security * symbol - The symbol of the security * * Implementations of the ERC-1450 standard must specify the following constructor * arguments: * * _owner - the address of the owner * _transferAgent - the address of the transfer agent * _name - the name of the security * _symbol - the symbol of the security * * Implementations of the ERC-1450 standard must implement the following contract * modifiers: * * Owned - Only the address of the security’s issuer is permitted to execute the * token’s constructor. This modifier also sets up the onlyOwner function modifier. * IssuerControlled - This modifier sets up the onlyIssuerTransferAgent function modifier. * * Implementations of the ERC-1450 standard must implement the following function * modifiers: * * onlyOwner - Only the address of the security’s issuer is permitted to execute the * functions transferOwnership, setTransferAgent, and setPhysicalAddressOfOperation. * onlyIssuerTransferAgent - Only the address of the issuer’s Registered Transfer * Agent is permitted to execute the functions transferFrom, mint, and burnFrom. * * Implementations of the ERC-1450 standard must implement the following required ERC-20 * event to always fail: * * Approval - Should never be called as the functions that emit this event must be * implemented to always fail. * * Implementations of the ERC-1450 standard must implement the following required * ERC-20 functions to always fail: * * transfer - Not a legal, regulated call for transferring securities because * the token holder initiates the token transfer. The function must be implemented to * always fail. * allowance - Not a legal, regulated call for transferring securities because * the token holder may not allow third parties to initiate token transfers. The * function must be implemented to always fail. * approve - Not a legal, regulated call for transferring securities because * the token holder may not allow third parties to initiate token transfers. The * function must be implemented to always fail. * * Implementations of the ERC-1450 standard must implement the following optional * ERC-20 function: * decimals - Must return '0' because securities are indivisible entities. * * Implementations of the ERC-1450 standard must implement the following functions: * * mint - Only the address of the issuer's Registered Transfer Agent may create new * securities. * burnFrom - Only the address of the issuer’s Registered Transfer Agent may burn or * destroy securities. */ Contract ERC-1450 is Owned, IssuerControlled { /** * The constructor must implement a modifier (Owned) that creates the onlyOwner modifier * to allow only the address of the issuer (the owner) to execute the transferOwnership, * setTransferAgent, and setPhysicalAddressOfOperation functions. The construct must also * implement a modifier (TransferAgentControlled) that creates the onlyIssuerTransferAgent * modifier to allow only the address of the issuer’s Registered Transfer Agent to execute * the functions transferFrom, mint, and burnFrom). */ constructor(address _owner, address _transferAgent, string _name, string _symbol) Owned(_issuer) TransferAgentControlled(_transferAgent) public; /** * Specify that only the owner (issuer) may execute a function. * * onlyOwner requires the msg.sender to be the owner’s address. */ modifier onlyOwner(); /** * Specify that only the issuer’s transferAgent may execute a function. * * onlyIssuerTransferAgent requires the msg.sender to be the transferAgent’s address. */ modifier onlyIssuerTransferAgent(); /** * Transfer ownership of a security from one issuer to another issuer. * * transferOwnership must implement the onlyOwner modifier to only allow the * address of the issuer’s owner to transfer ownership. * transferOwnership requires the _newOwner address to be the address of the new * issuer. */ function transferOwnership(address _newOwner) public onlyOwner; /** * Triggered after transferOwnership is executed. */ event OwnershipTransferred() /** * Sets the transfer agent for the security. * * setTransferAgent must implement the onlyOwner modifier to only allow the * address of the issuer’s specify the security’s transfer agent. * setTransferAgent requires the _newTransferAgent address to be the address of the * new transfer agent. */ function setTransferAgent(address _newTransferAgent) public onlyOwner; /** * Triggered after setTransferAgent is executed. */ event TransferAgentUpdated(address indexed previousTransferAgent, address indexed newTransferAgent); /** * Sets the issuers physical address of operation. * * setPhysicalAddressOfOperation must implement the onlyOwner modifier to only allow * the address of the issuer’s owner to transfer ownership. * setPhysicalAddressOfOperation requires the _newPhysicalAddressOfOperation address * to be the new address of the issuer. */ function setPhysicalAddressOfOperation(string _newPhysicalAddressOfOperation) public onlyOwner; /** * Triggered after setPhysicalAddressOfOperation is executed. */ event PhysicalAddressOfOperationUpdated(string previousPhysicalAddressOfOperation, string newPhysicalAddressOfOperation); /** * Look up the security’s transfer agent. * * isTransferAgent is a public function. * isTransferAgent requires the _lookup address to determine if that address * is the security’s transfer agent. */ function isTransferAgent(address _lookup) public view returns (bool); /** * transfer is not a legal, regulated call and must be implemented to always fail. */ transfer(address to, uint tokens) public returns (bool success); /** * Approval does not have to be implemented. This event should never be triggered as * the functions that emit this even are not legal, regulated calls. */ event Approval(address indexed tokenOwner, address indexed spender, uint tokens); /** * allowance is not a legal, regulated call and must be implemented to always fail. */ allowance(address tokenOwner, address spender) public constant returns (uint remaining); /** * approve is not a legal, regulated call and must be implemented to always fail. */ approve(address spender, uint tokens) public returns (bool success); /** * Transfer securities. * * transferFrom must implement the onlyIssuerTransferAgent modifier to only allow the * address of the issuer’s Registered Transfer Agent to transfer `ERC-1450`s. * transferFrom requires the _from address to have _value tokens. * transferFrom requires that the _to address must not be 0 because securities must * not destroyed in this manner. */ function transferFrom(address _from, address _to, uint256 _value) public onlyIssuerTransferAgent returns (bool); /** * Create new securities. * * mint must implement the onlyIssuerTransferAgent modifier to only allow the address * of the issuer’s Registered Transfer Agent to mint `ERC-1450` tokens. * mint requires that the _to address must not be 0 because securities must * not destroyed in this manner. * mint must add _value tokens to the _to address and increase the totalSupply by * _value. * mint must emit the Transfer event. */ function mint(address _to, uint256 _value) public onlyIssuerTransferAgent returns (bool); /** * Burn or destroy securities. * * burnFrom must implement the onlyIssuerTransferAgent modifier to only allow the * address of the issuer’s Registered Transfer Agent to burn `ERC-1450`s. * burnFrom requires the _from address to have _value tokens. * burnFrom must subtract _value tokens from the _from address and decrease the * totalSupply by _value. * burnFrom must emit the Transfer event. */ function burnFrom(address _who, uint256 _value) public onlyIssuerTransferAgent returns (bool); } ``` ### Securities Exchange Commission Requirements The SEC has very strict requirements as to the specific roles that are allowed to perform specific actions. Specifically, only the RTA may `mint` and `transferFrom` securities. Implementers must maintain off-chain services and databases that record and track the Investor’s name, physical address, Ethereum address, and security ownership amount. The implementers and the SEC must be able to access the Investor’s private information on an as needed basis. Issuers and the RTA must be able to produce a current list of all Investors, including the names, addresses, and security ownership levels for every security at any given moment. Issuers and the RTA must be able to re-issue securities to Investors for a variety of regulated reasons. Private Investor information must never be publicly exposed on a public blockchain. ### Managing Investor Information Special care and attention must be taken to ensure that the personally identifiable information of Investors is never exposed or revealed to the public. ### Issuers who lost access to their address or private keys There is no recourse if the Issuer loses access to their address to an existing instance of their securities. Special care and efforts must be made by the Issuer to secure and safely store their address and associated private key. The Issuer can reassign ownership to another Issuer but not in the case where the Issuer loses their private key. If the Issuer loses access, the Issuer’s securities must be rebuilt using off-chain services. The Issuer must create (and secure) a new address. The RTA can read the existing Issuer securities, and the RTA can `mint` Investor securities accordingly under a new `ERC-1450` smart contract. ### Registered Transfer Agents who lost access to their address or private keys If the RTA loses access, the RTA can create a new Ethereum address, and the Issuer can execute the `setTransferAgent` function to reassign the RTA. ### Handling Investors (security owners) who lost access to their addresses or private keys Investors may “lose” their credentials for a number of reasons: they simply “lost” their credentials, they were hacked or the victim of fraud, they committed securities-related fraud, or a life event (like death) occurred. Because the RTA manages the Issuer’s securities, the RTA may authorize ownership related changes of securities (as long as they are properly notarized and verified). If an Investor (or, say, the Investor’s heir) loses their credentials, the Investor must go through a notarized process to notify the RTA of the situation and supply a new Investor address. From there, the RTA can `mint` the “lost” securities to the new Investor address and `burnFrom` the old Investor address (because the RTA knows all Investors’ addresses). ## Rationale The are currently no token standards that facilitate compliance with SEC regulations. The closest token is [ERC-884 (Delaware General Corporations Law (DGCL) compatible share token)](/EIPS/eip-884) which states that SEC requirements are out of scope. [EIP-1404 (Simple Restricted Token Standard)](https://github.com/ethereum/EIPs/issues/1404) does not go far enough to address SEC requirements around re-issuing securities to Investors. ## Backwards Compatibility `ERC-1450` maintains compatibility with ERC-20 tokens with the following stipulations: * `function allowance(address tokenOwner, address spender) public constant returns (uint remaining);` * Must be implemented to always fail because allowance is not a legal, regulated call for a security. * `function transfer(address to, uint tokens) public returns (bool success);` * As the token holder initiates the transfer, must be implemented to always fail because transfer is not a legal, regulated call for a security. * `function approve(address spender, uint tokens) public returns (bool success);` * Must be implemented to always fail because approve is not a legal, regulated call for a security * `function transferFrom(address from, address to, uint tokens) public returns (bool success);` * Must be implemented so that only the Issuer’s RTA can perform this action * `event Approval(address indexed tokenOwner, address indexed spender, uint tokens);` * Does not have to be implemented. Approval should never be called as the functions that emit this event must be implemented to always fail ## Test Cases Test cases are available at [https://github.com/StartEngine/ldgr_smart_contracts/tree/master/test](https://github.com/StartEngine/ldgr_smart_contracts/tree/master/test). ## Implementations A reference implementation is available at [https://github.com/StartEngine/ldgr_smart_contracts](https://github.com/StartEngine/ldgr_smart_contracts). ## Copyright Waiver Copyright and related rights waived via [CC0](/LICENSE). Tue, 25 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1450 https://eips.ethereum.org/EIPS/eip-1450 Node Discovery via DNS Standards Track/Networking https://github.com/ethereum/devp2p/issues/50 ## Abstract This document describes a scheme for authenticated, updateable Ethereum node lists retrievable via DNS. ## Motivation Many Ethereum clients contain hard-coded bootstrap node lists. Updating those lists requires a software update. The current lists are small, giving the client little choice of initial entry point into the Ethereum network. We would like to maintain larger node lists containing hundreds of nodes, and update them regularly. The scheme described here is a replacement for client bootstrap node lists with equivalent security and many additional benefits. Large lists populated by traversing the node discovery DHT can serve as a fallback option for nodes which can't join the DHT due to restrictive network policy. DNS-based node lists may also be useful to Ethereum peering providers because their customers can configure the client to use the provider's list. ## Specification A 'node list' is a list of 'node records' [as defined by EIP-778](/EIPS/eip-778) of arbitrary length. Lists may refer to other lists using links. The entire list is signed using a secp256k1 private key. The corresponding public key must be known to the client in order to verify the list. To refer to a DNS node list, clients use a URL with 'enrtree' scheme. The URL contains the DNS name on which the list can be found as well as the public key that signed the list. The public key is contained in the username part of the URL and is the base32 encoding (RFC-4648) of the compressed 32-byte binary public key. Example: enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2@nodes.example.org This URL refers to a node list at the DNS name 'nodes.example.org' and is signed by the public key `0x049f88229042fef9200246f49f94d9b77c4e954721442714e85850cb6d9e5daf2d880ea0e53cb3ac1a75f9923c2726a4f941f7d326781baa6380754a360de5c2b6` ### DNS Record Structure The nodes in a list are encoded as a merkle tree for distribution via the DNS protocol. Entries of the merkle tree are contained in DNS TXT records. The root of the tree is a TXT record with the following content: enrtree-root:v1 e=<enr-root> l=<link-root> seq=<sequence-number> sig=<signature> where - `enr-root` and `link-root` refer to the root hashes of subtrees containing nodes and links subtrees. - `sequence-number` is the tree's update sequence number, a decimal integer. - `signature` is a 65-byte secp256k1 EC signature over the keccak256 hash of the record content, excluding the `sig=` part, encoded as URL-safe base64 (RFC-4648). Further TXT records on subdomains map hashes to one of three entry types. The subdomain name of any entry is the base32 encoding of the (abbreviated) keccak256 hash of its text content. - `enrtree-branch:<h₁>,<h₂>,...,<hₙ>` is an intermediate tree entry containing hashes of subtree entries. - `enrtree://<key>@<fqdn>` is a leaf pointing to a different list located at another fully qualified domain name. Note that this format matches the URL encoding. This type of entry may only appear in the subtree pointed to by `link-root`. - `enr:<node-record>` is a leaf containing a node record. The node record is encoded as a URL-safe base64 string. Note that this type of entry matches the canonical ENR text encoding. It may only appear in the `enr-root` subtree. No particular ordering or structure is defined for the tree. Whenever the tree is updated, its sequence number should increase. The content of any TXT record should be small enough to fit into the 512 byte limit imposed on UDP DNS packets. This limits the number of hashes that can be placed into an `enrtree-branch` entry. Example in zone file format: ; name ttl class type content @ 60 IN TXT enrtree-root:v1 e=JWXYDBPXYWG6FX3GMDIBFA6CJ4 l=C7HRFPF3BLGF3YR4DY5KX3SMBE seq=1 sig=o908WmNp7LibOfPsr4btQwatZJ5URBr2ZAuxvK4UWHlsB9sUOTJQaGAlLPVAhM__XJesCHxLISo94z5Z2a463gA C7HRFPF3BLGF3YR4DY5KX3SMBE 86900 IN TXT enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2@morenodes.example.org JWXYDBPXYWG6FX3GMDIBFA6CJ4 86900 IN TXT enrtree-branch:2XS2367YHAXJFGLZHVAWLQD4ZY,H4FHT4B454P6UXFD7JCYQ5PWDY,MHTDO6TMUBRIA2XWG5LUDACK24 2XS2367YHAXJFGLZHVAWLQD4ZY 86900 IN TXT enr:-HW4QOFzoVLaFJnNhbgMoDXPnOvcdVuj7pDpqRvh6BRDO68aVi5ZcjB3vzQRZH2IcLBGHzo8uUN3snqmgTiE56CH3AMBgmlkgnY0iXNlY3AyNTZrMaECC2_24YYkYHEgdzxlSNKQEnHhuNAbNlMlWJxrJxbAFvA H4FHT4B454P6UXFD7JCYQ5PWDY 86900 IN TXT enr:-HW4QAggRauloj2SDLtIHN1XBkvhFZ1vtf1raYQp9TBW2RD5EEawDzbtSmlXUfnaHcvwOizhVYLtr7e6vw7NAf6mTuoCgmlkgnY0iXNlY3AyNTZrMaECjrXI8TLNXU0f8cthpAMxEshUyQlK-AM0PW2wfrnacNI MHTDO6TMUBRIA2XWG5LUDACK24 86900 IN TXT enr:-HW4QLAYqmrwllBEnzWWs7I5Ev2IAs7x_dZlbYdRdMUx5EyKHDXp7AV5CkuPGUPdvbv1_Ms1CPfhcGCvSElSosZmyoqAgmlkgnY0iXNlY3AyNTZrMaECriawHKWdDRk2xeZkrOXBQ0dfMFLHY4eENZwdufn1S1o ### Client Protocol To find nodes at a given DNS name, say "mynodes.org": 1. Resolve the TXT record of the name and check whether it contains a valid "enrtree-root=v1" entry. Let's say the `enr-root` hash contained in the entry is "CFZUWDU7JNQR4VTCZVOJZ5ROV4". 2. Verify the signature on the root against the known public key and check whether the sequence number is larger than or equal to any previous number seen for that name. 3. Resolve the TXT record of the hash subdomain, e.g. "CFZUWDU7JNQR4VTCZVOJZ5ROV4.mynodes.org" and verify whether the content matches the hash. 4. The next step depends on the entry type found: - for `enrtree-branch`: parse the list of hashes and continue resolving them (step 3). - for `enr`: decode, verify the node record and import it to local node storage. During traversal, the client must track hashes and domains which are already resolved to avoid going into an infinite loop. It's in the client's best interest to traverse the tree in random order. Client implementations should avoid downloading the entire tree at once during normal operation. It's much better to request entries via DNS when-needed, i.e. at the time when the client is looking for peers. ## Rationale ### Why DNS? We have chosen DNS as the distribution medium because it is always available, even under restrictive network conditions. The protocol provides low latency and answers to DNS queries can be cached by intermediate resolvers. No custom server software is needed. Node lists can be deployed to any DNS provider such as CloudFlare DNS, dnsimple, Amazon Route 53 using their respective client libraries. ### Why is this a merkle tree? Being a merkle tree, any node list can be authenticated by a single signature on the root. Hash subdomains protect the integrity of the list. At worst intermediate resolvers can block access to the list or disallow updates to it, but cannot corrupt its content. The sequence number prevents replacing the root with an older version. Synchronizing updates on the client side can be done incrementally, which matters for large lists. Individual entries of the tree are small enough to fit into a single UDP packet, ensuring compatibility with environments where only basic UDP DNS is available. The tree format also works well with caching resolvers: only the root of the tree needs a short TTL. Intermediate entries and leaves can be cached for days. ### Why does the link subtree exist? Links between lists enable federation and web-of-trust functionality. The operator of a large list can delegate maintenance to other list providers. If two node lists link to each other, users can use either list and get nodes from both. The link subtree is separate from the tree containing ENRs. This is done to enable client implementations to sync these trees independently. A client wanting to get as many nodes as possible will sync the link tree first and add all linked names to the sync horizon. ## Security Considerations Discovery via DNS is less secure than via DHT, because it relies on a trusted party to publish the records regularly. The actor could easily eclipse bootstrapping nodes by only publishing node records that it controls. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 26 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1459 https://eips.ethereum.org/EIPS/eip-1459 Base Security Token Standards Track/ERC https://ethereum-magicians.org/t/erc-1462-base-security-token/1501 ## Simple Summary An extension to ERC-20 standard token that provides compliance with securities regulations and legal enforceability. ## Abstract This EIP defines a minimal set of additions to the default token standard such as [ERC-20](/EIPS/eip-20), that allows for compliance with domestic and international legal requirements. Such requirements include KYC (Know Your Customer) and AML (Anti Money Laundering) regulations, and the ability to lock tokens for an account, and restrict them from transfer due to a legal dispute. Also the ability to attach additional legal documentation, in order to set up a dual-binding relationship between the token and off-chain legal entities. The scope of this standard is being kept as narrow as possible to avoid restricting potential use-cases of this base security token. Any additional functionality and limitations not defined in this standard may be enforced on per-project basis. ## Motivation There are several security token standards that have been proposed recently. Examples include [ERC-1400](https://github.com/ethereum/EIPs/issues/1411), also [ERC-1450](https://eips.ethereum.org/EIPS/eip-1450). We have concerns about each of them, mostly because the scope of each of these EIPs contains many project-specific or market-specific details. Since many EIPs are coming from the respective backing companies, they capture many niche requirements that are excessive for a general case. For instance, ERC-1411 uses dependency on [ERC-1410](https://github.com/ethereum/eips/issues/1410) but it falls out of the "security tokens" scope. Also its dependency on [ERC-777](/EIPS/eip-777) will block the adoption for a quite period of time before ERC-777 is finalized, but the integration guidelines for existing ERC-20 workflows are not described in that EIP, yet. Another attempt to make a much simpler base standard [ERC-1404](https://github.com/ethereum/EIPs/issues/1404) is missing a few important points, specifically it doesn't provide enough granularity to distinguish between different ERC-20 transfer functions such as `transfer` and `transferFrom`. It also doesn't provide a way to bind legal documentation to the issued tokens. What we propose in this EIP is a simple and very modular solution for creating a base security token for the widest possible scope of applications, so it can be used by other issuers to build upon. The issuers should be able to add more restrictions and policies to the token, using the functions and implementation proposed below, but they must not be limited in any way while using this ERC. ## Specification The ERC-20 token provides the following basic features: ```solidity contract ERC20 { function totalSupply() public view returns (uint256); function balanceOf(address who) public view returns (uint256); function transfer(address to, uint256 value) public returns (bool); function allowance(address owner, address spender) public view returns (uint256); function transferFrom(address from, address to, uint256 value) public returns (bool); function approve(address spender, uint256 value) public returns (bool); event Approval(address indexed owner, address indexed spender, uint256 value); event Transfer(address indexed from, address indexed to, uint256 value); } ``` This will be extended as follows: ```solidity interface BaseSecurityToken /* is ERC-20 */ { // Checking functions function checkTransferAllowed (address from, address to, uint256 value) public view returns (byte); function checkTransferFromAllowed (address from, address to, uint256 value) public view returns (byte); function checkMintAllowed (address to, uint256 value) public view returns (byte); function checkBurnAllowed (address from, uint256 value) public view returns (byte); // Documentation functions function attachDocument(bytes32 _name, string _uri, bytes32 _contentHash) external; function lookupDocument(bytes32 _name) external view returns (string, bytes32); } ``` ### Transfer Checking Functions We introduce four new functions that should be used to check that the actions are allowed for the provided inputs. The implementation details of each function are left for the token issuer, it is the issuer's responsibility to add all necessary checks that will validate an operation in accordance with KYC/AML policies and legal requirements set for a specific token asset. Each function must return a status code from the common set of Ethereum status codes (ESC), according to [ERC-1066](/EIPS/eip-1066). Localization of these codes is out of the scope of this proposal and may be optionally solved by adopting [ERC-1444](/EIPS/eip-1444) on the application level. If the operation is allowed by a checking function, the return status code must be `0x11` (Allowed) or an issuer-specific code with equivalent but more precise meaning. If the operation is not allowed by a checking function, the status must be `0x10` (Disallowed) or an issuer-specific code with equivalent but more precise meaning. Upon an internal error, the function must return the most relevant code from the general code table or an issuer-specific equivalent, example: `0xF0` (Off-Chain Failure). **For [ERC-20](/EIPS/eip-20) based tokens,** * It is required that transfer function must be overridden with logic that checks the corresponding checkTransferAllowed return status code. * It is required that `transferFrom` function must be overridden with logic that checks the corresponding `checkTransferFromAllowed` return status code. * It is required that `approve` function must be overridden with logic that checks the corresponding `checkTransferFromAllowed` return status code. * Other functions such as `mint` and `burn` must be overridden, if they exist in the token implementation, they should check `checkMintAllowed` and `checkBurnAllowed` status codes accordingly. **For [ERC-777](/EIPS/eip-777) based tokens,** * It is required that `send` function must be overridden with logic that checks the corresponding return status codes: - `checkTransferAllowed` return status code, if transfer happens on behalf of the tokens owner; - `checkTransferFromAllowed` return status code, if transfer happens on behalf of an operator (i.e. delegated transfer). * It is required that `burn` function must be overridden with logic that checks the corresponding `checkBurnAllowed` return status code. * Other functions, such as `mint` must be overridden, if they exist in the token implementation, e.g. if the security token is mintable. `mint` function must call `checkMintAllowed` ad check it return status code. For both cases, * It is required for guaranteed compatibility with ERC-20 and ERC-777 wallets that each checking function returns `0x11` (Allowed) if not overridden with the issuer's custom logic. * It is required that all overridden checking functions must revert if the action is not allowed or an error occurred, according to the returned status code. Inside checker functions the logic is allowed to use any feature available on-chain: perform calls to registry contracts with whitelists/blacklists, use built-in checking logic that is defined on the same contract, or even run off-chain queries through an oracle. ### Documentation Functions We also introduce two new functions that should be used for document management purposes. Function `attachDocument` adds a reference pointing to an off-chain document, with specified name, URI and contents hash. The hashing algorithm is not specified within this standard, but the resulting hash must not be longer than 32 bytes. Function `lookupDocument` gets the referenced document by its name. * It is not required to use documentation functions, they are optional and provided as a part of a legal framework. * It is required that if `attachDocument` function has been used, the document reference must have a unique name, overwriting the references under same name is not allowed. All implementations must check if the reference under the given name is already existing. ## Rationale This EIP targets both ERC-20 and ERC-777 based tokens, although the most emphasis is given to ERC-20 due to its widespread adoption. However, this extension is designed to be compatible with the forthcoming ERC-777 standard, as well. All checking functions are named with prefixes `check` since they return check status code, not booleans, because that is important to facilitate the debugging and tracing process. It is responsibility of the issuer to implement the logic that will handle the return codes appropriately. Some handlers will simply throw errors, other handlers would log information for future process mining. More rationale for status codes can be seen in [ERC-1066](/EIPS/eip-1066). We require two different transfer validation functions: `checkTransferAllowed` and `checkTransferFromAllowed` since the corresponding `transfer` and `transferFrom` are usually called in different contexts. Some token standards such as [ERC-1450](/EIPS/eip-1450) explicitly disallow use of `transfer`, while allowing only `transferFrom`. There might be also different complex scenarios, where `transfer` and `transferFrom` should be treated differently. ERC-777 is relying on its own `send` for transferring tokens, so it is reasonable to switch between checker functions based on its call context. We decided to omit the `checkApprove` function since it would be used in exactly the same context as `checkTransferFromAllowed`. In many cases it is required not only regulate securities transfers, but also restrict burn and `mint` operations, and additional checker functions have been added for that. The documentation functions that we propose here are a must-have tool to create dual-bindings with off-chain legal documents, a great example of this can be seen in [Neufund's Employee Incentive Options Plan](https://medium.com/@ZoeAdamovicz/37376fd0384a) legal framework that implements full legal enforceability: the smart contract refers to printed ESOP Terms & Conditions Document, which itself refers back to smart contract. This is becoming a widely adopted practice even in cases where there are no legal requirements to reference the documents within the security token. However they're almost always required, and it's a good way to attach useful documentation of various types. ## Backwards Compatibility This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20 and ERC-777 tokens. ## Implementation * https://github.com/AtlantPlatform/BaseSecurityToken ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 01 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1462 https://eips.ethereum.org/EIPS/eip-1462 Smart Contract Weakness Classification (SWC) Informational/ https://github.com/ethereum/EIPs/issues/1469 ## Simple Summary This EIP proposes a classification scheme for security weaknesses in Ethereum smart contracts. ## Abstract The SWC is a smart contract specific software weakness classification scheme for developers, tool vendors and security practitioners. The SWC is loosely aligned to the terminologies and structure used in the [Common Weakness Enumeration - CWE](https://cwe.mitre.org) scheme while overlaying a wide range of weakness variants that are specific to smart contracts. The goals of the SWC scheme are as follows: - Provide a straightforward way to classify weaknesses in smart contract systems. - Provide a straightforward way to identify the weakness(es) that lead to a vulnerability in a smart contract system. - Define a common language for describing weaknesses in smart contract systems' architecture, design and code. - Train and increase the performance of smart contract security analysis tools. ## Motivation In the software security industry, it is a widely accepted practice to use a common terminology and to classify security related bugs and errors with a standardized scheme. While this has not stopped vulnerabilities from appearing in software, it has helped communities focusing on web applications, network protocols, IOT devices and various other fields to educate users and developers to understand the nature of security related issues in their software. It has also allowed the security community to quickly understand vulnerabilities that occur in production systems to perform root cause analysis or triage findings from various security analysis sources. In recent years various organizations and companies also published vulnerability data to find the most widespread security issues based on collected vulnerability data. Two examples that are widely used and referred to are the [SANS TOP 25 Most Dangerous Software Errors](https://www.sans.org/top25-software-errors) and the [OWASP TOP 10](https://www.owasp.org/index.php/Top_10-2017_Top_10). None of those publications would have been possible without a common classification scheme. At present no such weakness classification scheme exists for weaknesses specific to Ethereum Smart Contracts. Common language and awareness of security weaknesses is mostly derived from academic papers, best practice guides and published articles. Findings from audit reports and security tool analysis add to the wide range of terminologies that is used to describe the discovered weaknesses. It is often time consuming to understand the technical root cause and the risk associated to findings from different sources even for security experts. ## Rationale While recognizing the current gap, the SWC does not aim to reinvent the wheel in regards to classification of security weaknesses. It rather proposes to build on top of what has worked well in other parts of the software security community - specifically the Common Weakness Enumeration (CWE), a list of software vulnerability types that stands out in terms of adoption and breadth of coverage. While CWE does not describe any weaknesses specific to smart contracts, it does describe related weaknesses at higher abstraction layers. This EIP proposes to create smart contract specific variants while linking back to the larger spectrum of software errors and mistakes listed in the CWE that different platforms and technologies have in common. ## Specification Before discussing the SWC specification it is important to describe the terminology used: - Weakness: A software error or mistake that in the right conditions can by itself or coupled with other weaknesses lead to a vulnerability. - Vulnerability: A weakness or multiple weaknesses which directly or indirectly lead to an undesirable state in a smart contract system. - Variant: A specific weakness that is described in a very low detail specific to Ethereum smart contracts. Each variant is assigned a unique SWC ID. - Relationships: CWE has a wide range of _Base_ and _Class_ types that group weaknesses on higher abstraction layers. The CWE uses _Relationships_ to link SWC smart contract weakness variants to existing _Base_ or _Class_ CWE types. _Relationships_ are used to provide context on how SWCs are linked to the wider group of software security weaknesses and to be able to generate useful visualisations and insights through issue data sets. In its current revision it is proposed to link a SWC to its closest parent in the CWE. - SWC ID: A numeric identifier linked to a variant (e.g. SWC-101). - Test Case: A test case constitutes a micro-sample or real-world smart contract that demonstrates concrete instances of one or multiple SWC variants. Test cases serve as the basis for meaningful weakness classification and are useful to security analysis tool developers. The SWC in its most basic form links a numeric identifier to a weakness variant. For example the identifier _SWC-101_ is linked to the _Integer Overflow and Underflow_ variant. While a list with the weakness title and a unique id is useful by itself, it would also be ambiguous without further details. Therefore the SWC recommends to add a definition and test cases to any weakness variant. **SWC definition** A SWC definition is formatted in markdown to allow good readability and tools to process them easily. It consists of the following attributes. - Title: A name for the weakness that points to the technical root cause. - Relationships: Links a CWE _Base_ or _Class_ type to its CWE variant. The _Integer Overflow and Underflow_ variant for example is linked to [CWE-682 - Incorrect Calculation](https://cwe.mitre.org/data/definitions/682.html). - Description: Describes the nature and potential impact of the weakness on the contract system. - Remediation: Describes ways on how to fix the weakness. - References: Links to external references that contain relevant additional information on the weakness. **Test cases** Test cases include crafted as well as real-world samples of vulnerable smart contracts. A single test case consists of three components: 1. Source code of a smart contract sample; e.g. Solidity, Vyper, etc. 2. Compiled asset from an EVM compiler in machine readable format; e.g. JSON or ethPM. 3. Test result configuration that describes which and how many instances of a weakness variant can be found in a given sample. The YAML schema for the proposed test case configuration is listed below. ```YAML title: SWC config type: object required: - description - issues properties: description: type: string issues: title: Issues type: array items: title: Issue type: object required: - id - count properties: id: type: string count: type: number locations: items: bytecode_offsets: type: object line_numbers: type: object ``` ## Implementation The Smart Contract Weakness Classification registry located in this [GitHub repository](https://github.com/SmartContractSecurity/SWC-registry) uses the SWC scheme proposed in this EIP. A GitHub Pages rendered version is also available [here](https://smartcontractsecurity.github.io/SWC-registry/). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 18 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1470 https://eips.ethereum.org/EIPS/eip-1470 Remote procedure call specification Standards Track/Interface https://ethereum-magicians.org/t/eip-remote-procedure-call-specification/1537 ## Simple Summary This proposal defines a standard set of remote procedure call methods that an Ethereum node should implement. ## Abstract Nodes created by the current generation of Ethereum clients expose inconsistent and incompatible remote procedure call (RPC) methods because no formal Ethereum RPC specification exists. This proposal standardizes such a specification to provide developers with a predictable Ethereum RPC interface regardless of underlying node implementation. ## Specification ### Concepts #### RFC-2119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119](https://www.ietf.org/rfc/rfc2119.txt). #### JSON-RPC Communication with Ethereum nodes is accomplished using [JSON-RPC](https://www.jsonrpc.org/specification), a stateless, lightweight [remote procedure call](https://en.wikipedia.org/wiki/Remote_procedure_call) protocol that uses [JSON](http://www.json.org/) as its data format. Ethereum RPC methods **MUST** be called using [JSON-RPC request objects](https://www.jsonrpc.org/specification#request_object) and **MUST** respond with [JSON-RPC response objects](https://www.jsonrpc.org/specification#response_object). #### Error codes If an Ethereum RPC method encounters an error, the `error` member included on the response object **MUST** be an object containing a `code` member and descriptive `message` member. The following list contains all possible error codes and associated messages: |Code|Message|Meaning|Category| |-|-|-|-| |-32700|Parse error|Invalid JSON|standard| |-32600|Invalid request|JSON is not a valid request object|standard| |-32601|Method not found|Method does not exist|standard| |-32602|Invalid params|Invalid method parameters|standard| |-32603|Internal error|Internal JSON-RPC error|standard| |-32000|Invalid input|Missing or invalid parameters|non-standard| |-32001|Resource not found|Requested resource not found|non-standard| |-32002|Resource unavailable|Requested resource not available|non-standard| |-32003|Transaction rejected|Transaction creation failed|non-standard| |-32004|Method not supported|Method is not implemented|non-standard| |-32005|Limit exceeded|Request exceeds defined limit|non-standard| |-32006|JSON-RPC version not supported|Version of JSON-RPC protocol is not supported|non-standard| Example error response: ```sh { "id": 1337 "jsonrpc": "2.0", "error": { "code": -32003, "message": "Transaction rejected" } } ``` #### Value encoding Specific types of values passed to and returned from Ethereum RPC methods require special encoding: ##### `Quantity` - A `Quantity` value **MUST** be hex-encoded. - A `Quantity` value **MUST** be "0x"-prefixed. - A `Quantity` value **MUST** be expressed using the fewest possible hex digits per byte. - A `Quantity` value **MUST** express zero as "0x0". Examples `Quantity` values: |Value|Valid|Reason| |-|-|-| |0x|`invalid`|empty not a valid quantity| |0x0|`valid`|interpreted as a quantity of zero| |0x00|`invalid`|leading zeroes not allowed| |0x41|`valid`|interpreted as a quantity of 65| |0x400|`valid`|interpreted as a quantity of 1024| |0x0400|`invalid`|leading zeroes not allowed| |ff|`invalid`|values must be prefixed| ##### `Block Identifier` The RPC methods below take a default block identifier as a parameter. - `eth_getBalance` - `eth_getStorageAt` - `eth_getTransactionCount` - `eth_getCode` - `eth_call` - `eth_getProof` Since there is no way to clearly distinguish between a `Data` parameter and a `Quantity` parameter, [EIP-1898](/EIPS/eip-1898) provides a format to specify a block either using the block hash or block number. The block identifier is a JSON `object` with the following fields: |Property|Type|Description| |-|-|-| |`[blockNumber]`|{[`Quantity`](#quantity)}|The block in the canonical chain with this number| |OR `[blockHash]`|{[`Data`](#data)}|The block uniquely identified by this hash. The `blockNumber` and `blockHash` properties are mutually exclusive; exactly one of them must be set.| |`requireCanonical`|{`boolean`}|(optional) Whether or not to throw an error if the block is not in the canonical chain as described below. Only allowed in conjunction with the `blockHash` tag. Defaults to `false`.| If the block is not found, the callee SHOULD raise a JSON-RPC error (the recommended error code is `-32001: Resource not found`. If the tag is `blockHash` and `requireCanonical` is `true`, the callee SHOULD additionally raise a JSON-RPC error if the block is not in the canonical chain (the recommended error code is `-32000: Invalid input` and in any case should be different than the error code for the block not found case so that the caller can distinguish the cases). The block-not-found check SHOULD take precedence over the block-is-canonical check, so that if the block is not found the callee raises block-not-found rather than block-not-canonical. ##### `Data` - A `Data` value **MUST** be hex-encoded. - A `Data` value **MUST** be "0x"-prefixed. - A `Data` value **MUST** be expressed using two hex digits per byte. Examples `Data` values: |Value|Valid|Reason| |-|-|-| |0x|`valid`|interpreted as empty data| |0x0|`invalid`|each byte must be represented using two hex digits| |0x00|`valid`|interpreted as a single zero byte| |0x41|`true`|interpreted as a data value of 65| |0x004200|`true`|interpreted as a data value of 16896| |0xf0f0f|`false`|bytes require two hex digits| |004200|`false`|values must be prefixed| ##### Proposing changes New Ethereum RPC methods and changes to existing methods **MUST** be proposed via the traditional EIP process. This allows for community consensus around new method implementations and proposed method modifications. RPC method proposals **MUST** reach "draft" status before being added to this proposal and the official Ethereum RPC specification defined herein. ### Methods #### web3_clientVersion ##### Description Returns the version of the current client ##### Parameters _(none)_ ##### Returns {`string`} - client version ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "web3_clientVersion", "params": [], }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "Mist/v0.9.3/darwin/go1.4.1" } ``` --- #### web3_sha3 ##### Description Hashes data using the Keccak-256 algorithm ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|data to hash| ##### Returns {[`Data`](#data)} - Keccak-256 hash of the given data ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "web3_sha3", "params": ["0x68656c6c6f20776f726c64"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xc94770007dda54cF92009BFF0dE90c06F603a09f" } ``` --- #### net_listening ##### Description Determines if this client is listening for new network connections ##### Parameters _(none)_ ##### Returns {`boolean`} - `true` if listening is active or `false` if listening is not active ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "net_listening", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": true } ``` --- #### net_peerCount ##### Description Returns the number of peers currently connected to this client ##### Parameters _(none)_ ##### Returns {[`Quantity`](#quantity)} - number of connected peers ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "net_peerCount", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x2" } ``` --- #### net_version ##### Description Returns the chain ID associated with the current network ##### Parameters _(none)_ ##### Returns {`string`} - chain ID associated with the current network Common chain IDs: - `"1"` - Ethereum mainnet - `"3"` - Ropsten testnet - `"4"` - Rinkeby testnet - `"42"` - Kovan testnet **Note:** See EIP-155 for a [complete list](/EIPS/eip-155#list-of-chain-ids) of possible chain IDs. ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "net_version", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "3" } ``` --- #### eth_accounts ##### Description Returns a list of addresses owned by this client ##### Parameters _(none)_ ##### Returns {[`Data[]`](#data)} - array of addresses ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_accounts", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": ["0xc94770007dda54cF92009BFF0dE90c06F603a09f"] } ``` --- #### eth_blockNumber ##### Description Returns the number of the most recent block seen by this client ##### Parameters _(none)_ ##### Returns {[`Quantity`](#quantity)} - number of the latest block ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xc94" } ``` --- #### eth_call ##### Description Executes a new message call immediately without submitting a transaction to the network ##### Parameters |#|Type|Description| |-|-|-| |1|{`object`}|@property {[`Data`](#data)} `[from]` - transaction sender<br/>@property {[`Data`](#data)} `to` - transaction recipient or `null` if deploying a contract<br/>@property {[`Quantity`](#quantity)} `[gas]` - gas provided for transaction execution<br/>@property {[`Quantity`](#quantity)} `[gasPrice]` - price in wei of each gas used<br/>@property {[`Quantity`](#quantity)} `[value]` - value in wei sent with this transaction<br/>@property {[`Data`](#data)} `[data]` - contract code or a hashed method call with encoded args| |2|{[`Quantity`](#quantity)\|`string`\|[`Block Identifier`](#block-identifier)}|block number, or one of `"latest"`, `"earliest"` or `"pending"`, or a block identifier as described in [`Block Identifier`](#block-identifier)| ##### Returns {[`Data`](#data)} - return value of executed contract ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_call", "params": [{ "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", "from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", "gas": "0x76c0", "gasPrice": "0x9184e72a000", "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", "value": "0x9184e72a" }] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x" } ``` --- #### eth_coinbase ##### Description Returns the coinbase address for this client ##### Parameters _(none)_ ##### Returns {[`Data`](#data)} - coinbase address ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_coinbase", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xc94770007dda54cF92009BFF0dE90c06F603a09f" } ``` --- #### eth_estimateGas ##### Description Estimates the gas necessary to complete a transaction without submitting it to the network **Note:** The resulting gas estimation may be significantly more than the amount of gas actually used by the transaction. This is due to a variety of reasons including EVM mechanics and node performance. ##### Parameters |#|Type|Description| |-|-|-| |1|{`object`}|@property {[`Data`](#data)} `[from]` - transaction sender<br/>@property {[`Data`](#data)} `[to]` - transaction recipient<br/>@property {[`Quantity`](#quantity)} `[gas]` - gas provided for transaction execution<br/>@property {[`Quantity`](#quantity)} `[gasPrice]` - price in wei of each gas used<br/>@property {[`Quantity`](#quantity)} `[value]` - value in wei sent with this transaction<br/>@property {[`Data`](#data)} `[data]` - contract code or a hashed method call with encoded args| |2|{[`Quantity`](#quantity)\|`string`}|block number, or one of `"latest"`, `"earliest"` or `"pending"`| ##### Returns {[`Quantity`](#quantity)} - amount of gas required by transaction ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_estimateGas", "params": [{ "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", "from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", "gas": "0x76c0", "gasPrice": "0x9184e72a000", "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", "value": "0x9184e72a" }] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x5208" } ``` --- #### eth_gasPrice ##### Description Returns the current price of gas expressed in wei ##### Parameters _(none)_ ##### Returns {[`Quantity`](#quantity)} - current gas price in wei ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_gasPrice", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x09184e72a000" } ``` --- #### eth_getBalance ##### Description Returns the balance of an address in wei ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|address to query for balance| |2|{[`Quantity`](#quantity)\|`string`\|[`Block Identifier`](#block-identifier)}|block number, or one of `"latest"`, `"earliest"` or `"pending"`, or a block identifier as described in [`Block Identifier`](#block-identifier)| ##### Returns {[`Quantity`](#quantity)} - balance of the provided account in wei ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getBalance", "params": ["0xc94770007dda54cF92009BFF0dE90c06F603a09f", "latest"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x0234c8a3397aab58" } ``` --- #### eth_getBlockByHash ##### Description Returns information about a block specified by hash ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash of a block| |2|{`boolean`}|`true` will pull full transaction objects, `false` will pull transaction hashes| ##### Returns {`null|object`} - `null` if no block is found, otherwise a block object with the following members: - {[`Data`](#data)} `extraData` - "extra data" field of this block - {[`Data`](#data)} `hash` - block hash or `null` if pending - {[`Data`](#data)} `logsBloom` - logs bloom filter or `null` if pending - {[`Data`](#data)} `miner` - address that received this block's mining rewards - {[`Data`](#data)} `nonce` - proof-of-work hash or `null` if pending - {[`Data`](#data)} `parentHash` - parent block hash - {[`Data`](#data)} `receiptsRoot` -root of this block's receipts trie - {[`Data`](#data)} `sha3Uncles` - SHA3 of the uncles data in this block - {[`Data`](#data)} `stateRoot` - root of this block's final state trie - {[`Data`](#data)} `transactionsRoot` - root of this block's transaction trie - {[`Quantity`](#quantity)} `difficulty` - difficulty for this block - {[`Quantity`](#quantity)} `gasLimit` - maximum gas allowed in this block - {[`Quantity`](#quantity)} `gasUsed` - total used gas by all transactions in this block - {[`Quantity`](#quantity)} `number` - block number or `null` if pending - {[`Quantity`](#quantity)} `size` - size of this block in bytes - {[`Quantity`](#quantity)} `timestamp` - unix timestamp of when this block was collated - {[`Quantity`](#quantity)} `totalDifficulty` - total difficulty of the chain until this block - {`Array<Transaction>`} `transactions` - list of transaction objects or hashes - {`Array<Transaction>`} `uncles` - list of uncle hashes ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getBlockByHash", "params":["0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", true] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000", "gasLimit": "0x9f759", "gasUsed": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsBloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parentHash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateRoot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totalDifficulty": "0x027f07", "transactions": [] "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": ["0x1606e5...", "0xd5145a9..."] } } ``` --- #### eth_getBlockByNumber ##### Description Returns information about a block specified by number ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)\|`string`}|block number, or one of `"latest"`, `"earliest"` or `"pending"`| |2|{`boolean`}|`true` will pull full transaction objects, `false` will pull transaction hashes| ##### Returns {`null|object`} - `null` if no block is found, otherwise a block object with the following members: - {[`Data`](#data)} `extraData` - "extra data" field of this block - {[`Data`](#data)} `hash` - block hash or `null` if pending - {[`Data`](#data)} `logsBloom` - logs bloom filter or `null` if pending - {[`Data`](#data)} `miner` - address that received this block's mining rewards - {[`Data`](#data)} `nonce` - proof-of-work hash or `null` if pending - {[`Data`](#data)} `parentHash` - parent block hash - {[`Data`](#data)} `receiptsRoot` -root of this block's receipts trie - {[`Data`](#data)} `sha3Uncles` - SHA3 of the uncles data in this block - {[`Data`](#data)} `stateRoot` - root of this block's final state trie - {[`Data`](#data)} `transactionsRoot` - root of this block's transaction trie - {[`Quantity`](#quantity)} `difficulty` - difficulty for this block - {[`Quantity`](#quantity)} `gasLimit` - maximum gas allowed in this block - {[`Quantity`](#quantity)} `gasUsed` - total used gas by all transactions in this block - {[`Quantity`](#quantity)} `number` - block number or `null` if pending - {[`Quantity`](#quantity)} `size` - size of this block in bytes - {[`Quantity`](#quantity)} `timestamp` - unix timestamp of when this block was collated - {[`Quantity`](#quantity)} `totalDifficulty` - total difficulty of the chain until this block - {`Array<Transaction>`} `transactions` - list of transaction objects or hashes - {`Array<Transaction>`} `uncles` - list of uncle hashes ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getBlockByNumber", "params":["0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", true] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000", "gasLimit": "0x9f759", "gasUsed": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsBloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parentHash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateRoot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totalDifficulty": "0x027f07", "transactions": [] "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": ["0x1606e5...", "0xd5145a9..."] } } ``` --- #### eth_getBlockTransactionCountByHash ##### Description Returns the number of transactions in a block specified by block hash ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash of a block| ##### Returns {[`Quantity`](#quantity)} - number of transactions in the specified block ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getBlockTransactionCountByHash", "params": ["0xc94770007dda54cF92009BFF0dE90c06F603a09f"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xc" } ``` --- #### eth_getBlockTransactionCountByNumber ##### Description Returns the number of transactions in a block specified by block number ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)\|`string`}|block number, or one of `"latest"`, `"earliest"` or `"pending"`| ##### Returns {[`Quantity`](#quantity)} - number of transactions in the specified block ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getBlockTransactionCountByNumber", "params": ["0xe8"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xa" } ``` --- #### eth_getCode ##### Description Returns the contract code stored at a given address ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|address to query for code| |2|{[`Quantity`](#quantity)\|`string`\|[`Block Identifier`](#block-identifier)}|block number, or one of `"latest"`, `"earliest"` or `"pending"`, or a block identifier as described in [`Block Identifier`](#block-identifier)| ##### Returns {[`Data`](#data)} - code from the specified address ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getCode", "params": ["0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", "0x2"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x600160008035811a818181146012578301005b601b6001356025565b8060005260206000f25b600060078202905091905056" } ``` --- #### eth_getFilterChanges ##### Description Returns a list of all logs based on filter ID since the last log retrieval ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)}|ID of the filter| ##### Returns {`Array<Log>`} - array of log objects with the following members: - {[`Data`](#data)} `address` - address from which this log originated - {[`Data`](#data)} `blockHash` - hash of block containing this log or `null` if pending - {[`Data`](#data)} `data` - contains the non-indexed arguments of the log - {[`Data`](#data)} `transactionHash` - hash of the transaction that created this log or `null` if pending - {[`Quantity`](#quantity)} `blockNumber` - number of block containing this log or `null` if pending - {[`Quantity`](#quantity)} `logIndex` - index of this log within its block or `null` if pending - {[`Quantity`](#quantity)} `transactionIndex` - index of the transaction that created this log or `null` if pending - {[`Data[]`](#data)} `topics` - list of order-dependent topics - {`boolean`} `removed` - `true` if this filter has been destroyed and is invalid **Note:** The return value of `eth_getFilterChanges` when retrieving logs from `eth_newBlockFilter` and `eth_newPendingTransactionFilter` filters will be an array of hashes, not an array of Log objects. ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getFilterChanges", "params": ["0x16"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": [{ "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", "blockNumber":"0x1b4", "data":"0x0000000000000000000000000000000000000000000000000000000000000000", "logIndex": "0x1", "topics": [], "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", "transactionIndex": "0x0" }] } ``` --- #### eth_getFilterLogs ##### Description Returns a list of all logs based on filter ID ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)}|ID of the filter| ##### Returns {`Array<Log>`} - array of log objects with the following members: - {[`Data`](#data)} address - address from which this log originated - {[`Data`](#data)} blockHash - hash of block containing this log or `null` if pending - {[`Data`](#data)} data - contains the non-indexed arguments of the log - {[`Data`](#data)} transactionHash - hash of the transaction that created this log or `null` if pending - {[`Quantity`](#quantity)} blockNumber - number of block containing this log or `null` if pending - {[`Quantity`](#quantity)} logIndex - index of this log within its block or `null` if pending - {[`Quantity`](#quantity)} transactionIndex - index of the transaction that created this log or `null` if pending - {`Array<Data>`} topics - list of order-dependent topics - {`boolean`} removed - `true` if this filter has been destroyed and is invalid **Note:** The return value of `eth_getFilterLogs` when retrieving logs from `eth_newBlockFilter` and `eth_newPendingTransactionFilter` filters will be an array of hashes, not an array of Log objects. ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getFilterLogs", "params": ["0x16"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": [{ "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", "blockNumber":"0x1b4", "data":"0x0000000000000000000000000000000000000000000000000000000000000000", "logIndex": "0x1", "topics": [], "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", "transactionIndex": "0x0" }] } ``` --- #### eth_getLogs ##### Description Returns a list of all logs based on a filter object ##### Parameters |#|Type|Description| |-|-|-| |1|{`object`}|@property {[`Quantity`](#quantity)\|`string`} `[fromBlock]` - block number, or one of `"latest"`, `"earliest"` or `"pending"`<br/>@property {[`Quantity`](#quantity)\|`string`} `[toBlock]` - block number, or one of `"latest"`, `"earliest"` or `"pending"`<br/>@property {[`Data`](#data)\|[`Data[]`](#data)} `[address]` - contract address or a list of addresses from which logs should originate<br/>@property {[`Data[]`](#data)} `[topics]` - list of order-dependent topics<br/>@property {[`Data`](#data)} `[blockhash]` - restrict logs to a block by hash| **Note:** If `blockhash` is passed, neither `fromBlock` nor `toBlock` are allowed or respected. ##### Returns {`Array<Log>`} - array of log objects with the following members: - {[`Data`](#data)} `address` - address from which this log originated - {[`Data`](#data)} `blockHash` - hash of block containing this log or `null` if pending - {[`Data`](#data)} `data` - contains the non-indexed arguments of the log - {[`Data`](#data)} `transactionHash` - hash of the transaction that created this log or `null` if pending - {[`Quantity`](#quantity)} `blockNumber` - number of block containing this log or `null` if pending - {[`Quantity`](#quantity)} `logIndex` - index of this log within its block or `null` if pending - {[`Quantity`](#quantity)} `transactionIndex` - index of the transaction that created this log or `null` if pending - {[`Data`](#data)} `topics` - list of order-dependent topics - {`boolean`} `removed` - `true` if this filter has been destroyed and is invalid ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getLogs", "params": [{ "topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"] }] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": [{ "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", "blockNumber":"0x1b4", "data":"0x0000000000000000000000000000000000000000000000000000000000000000", "logIndex": "0x1", "topics": [], "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", "transactionIndex": "0x0" }] } ``` --- #### eth_getStorageAt ##### Description Returns the value from a storage position at an address ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|address of stored data| |2|{[`Quantity`](#quantity)}|index into stored data| |3|{[`Quantity`](#quantity)\|`string`\|[`Block Identifier`](#block-identifier)}|block number, or one of `"latest"`, `"earliest"` or `"pending"`, or a block identifier as described in [`Block Identifier`](#block-identifier)| ##### Returns {[`Data`](#data)} - value stored at the given address and data index ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x00000000000000000000000000000000000000000000000000000000000004d2" } ``` --- #### eth_getTransactionByBlockHashAndIndex ##### Description Returns information about a transaction specified by block hash and transaction index ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash of a block| |2|{[`Quantity`](#quantity)}|index of a transaction in the specified block| ##### Returns {`null|object`} - `null` if no transaction is found, otherwise a transaction object with the following members: - {[`Data`](#data)} `r` - ECDSA signature r - {[`Data`](#data)} `s` - ECDSA signature s - {[`Data`](#data)} `blockHash` - hash of block containing this transaction or `null` if pending - {[`Data`](#data)} `from` - transaction sender - {[`Data`](#data)} `hash` - hash of this transaction - {[`Data`](#data)} `input` - contract code or a hashed method call - {[`Data`](#data)} `to` - transaction recipient or `null` if deploying a contract - {[`Quantity`](#quantity)} `v` - ECDSA recovery ID - {[`Quantity`](#quantity)} `blockNumber` - number of block containing this transaction or `null` if pending - {[`Quantity`](#quantity)} `gas` - gas provided for transaction execution - {[`Quantity`](#quantity)} `gasPrice` - price in wei of each gas used - {[`Quantity`](#quantity)} `nonce` - unique number identifying this transaction - {[`Quantity`](#quantity)} `transactionIndex` - index of this transaction in the block or `null` if pending - {[`Quantity`](#quantity)} `value` - value in wei sent with this transaction ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getTransactionByBlockHashAndIndex", "params":["0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "0x0"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "blockHash": "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "blockNumber": "0x5daf3b", "from": "0xa7d9ddbe1f17865597fbd27ec712455208b6b76d", "gas": "0xc350", "gasPrice": "0x4a817c800", "hash": "0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b", "input": "0x68656c6c6f21", "nonce": "0x15", "r": "0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea", "s": "0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c", "to": "0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb", "transactionIndex": "0x41", "v": "0x25", "value": "0xf3dbb76162000" } } ``` --- #### eth_getTransactionByBlockNumberAndIndex ##### Description Returns information about a transaction specified by block number and transaction index ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)\|`string`}|block number, or one of `"latest"`, `"earliest"` or `"pending"`| |2|{[`Quantity`](#quantity)}|index of a transaction in the specified block| ##### Returns {`null|object`} - `null` if no transaction is found, otherwise a transaction object with the following members: - {[`Data`](#data)} `r` - ECDSA signature r - {[`Data`](#data)} `s` - ECDSA signature s - {[`Data`](#data)} `blockHash` - hash of block containing this transaction or `null` if pending - {[`Data`](#data)} `from` - transaction sender - {[`Data`](#data)} `hash` - hash of this transaction - {[`Data`](#data)} `input` - contract code or a hashed method call - {[`Data`](#data)} `to` - transaction recipient or `null` if deploying a contract - {[`Quantity`](#quantity)} `v` - ECDSA recovery ID - {[`Quantity`](#quantity)} `blockNumber` - number of block containing this transaction or `null` if pending - {[`Quantity`](#quantity)} `gas` - gas provided for transaction execution - {[`Quantity`](#quantity)} `gasPrice` - price in wei of each gas used - {[`Quantity`](#quantity)} `nonce` - unique number identifying this transaction - {[`Quantity`](#quantity)} `transactionIndex` - index of this transaction in the block or `null` if pending - {[`Quantity`](#quantity)} `value` - value in wei sent with this transaction ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getTransactionByBlockNumberAndIndex", "params":["0x29c", "0x0"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "blockHash": "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "blockNumber": "0x5daf3b", "from": "0xa7d9ddbe1f17865597fbd27ec712455208b6b76d", "gas": "0xc350", "gasPrice": "0x4a817c800", "hash": "0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b", "input": "0x68656c6c6f21", "nonce": "0x15", "r": "0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea", "s": "0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c", "to": "0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb", "transactionIndex": "0x41", "v": "0x25", "value": "0xf3dbb76162000" } } ``` --- #### eth_getTransactionByHash ##### Description Returns information about a transaction specified by hash ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash of a transaction| ##### Returns {`null|object`} - `null` if no transaction is found, otherwise a transaction object with the following members: - {[`Data`](#data)} `r` - ECDSA signature r - {[`Data`](#data)} `s` - ECDSA signature s - {[`Data`](#data)} `blockHash` - hash of block containing this transaction or `null` if pending - {[`Data`](#data)} `from` - transaction sender - {[`Data`](#data)} `hash` - hash of this transaction - {[`Data`](#data)} `input` - contract code or a hashed method call - {[`Data`](#data)} `to` - transaction recipient or `null` if deploying a contract - {[`Quantity`](#quantity)} `v` - ECDSA recovery ID - {[`Quantity`](#quantity)} `blockNumber` - number of block containing this transaction or `null` if pending - {[`Quantity`](#quantity)} `gas` - gas provided for transaction execution - {[`Quantity`](#quantity)} `gasPrice` - price in wei of each gas used - {[`Quantity`](#quantity)} `nonce` - unique number identifying this transaction - {[`Quantity`](#quantity)} `transactionIndex` - index of this transaction in the block or `null` if pending - {[`Quantity`](#quantity)} `value` - value in wei sent with this transaction ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getTransactionByHash", "params": ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "blockHash": "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "blockNumber": "0x5daf3b", "from": "0xa7d9ddbe1f17865597fbd27ec712455208b6b76d", "gas": "0xc350", "gasPrice": "0x4a817c800", "hash": "0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b", "input": "0x68656c6c6f21", "nonce": "0x15", "r": "0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea", "s": "0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c", "to": "0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb", "transactionIndex": "0x41", "v": "0x25", "value": "0xf3dbb76162000" } } ``` --- #### eth_getTransactionCount ##### Description Returns the number of transactions sent from an address ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|address to query for sent transactions| |2|{[`Quantity`](#quantity)\|`string`\|[`Block Identifier`](#block-identifier)}|block number, or one of `"latest"`, `"earliest"` or `"pending"`, or a block identifier as described in [`Block Identifier`](#block-identifier)| ##### Returns {[`Quantity`](#quantity)} - number of transactions sent from the specified address ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getTransactionCount", "params": ["0xc94770007dda54cF92009BFF0dE90c06F603a09f", "latest"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x1" } ``` --- #### eth_getTransactionReceipt ##### Description Returns the receipt of a transaction specified by hash **Note:** Transaction receipts are unavailable for pending transactions. ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash of a transaction| ##### Returns {`null|object`} - `null` if no transaction is found, otherwise a transaction receipt object with the following members: - {[`Data`](#data)} `blockHash` - hash of block containing this transaction - {[`Data`](#data)} `contractAddress` - address of new contract or `null` if no contract was created - {[`Data`](#data)} `from` - transaction sender - {[`Data`](#data)} `logsBloom` - logs bloom filter - {[`Data`](#data)} `to` - transaction recipient or `null` if deploying a contract - {[`Data`](#data)} `transactionHash` - hash of this transaction - {[`Quantity`](#quantity)} `blockNumber` - number of block containing this transaction - {[`Quantity`](#quantity)} `cumulativeGasUsed` - gas used by this and all preceding transactions in this block - {[`Quantity`](#quantity)} `gasUsed` - gas used by this transaction - {[`Quantity`](#quantity)} `status` - `1` if this transaction was successful or `0` if it failed - {[`Quantity`](#quantity)} `transactionIndex` - index of this transaction in the block - {`Array<Log>`} `logs` - list of log objects generated by this transaction ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getTransactionReceipt", "params": ["0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "blockHash": '0xc6ef2fc5426d6ad6fd9e2a26abeab0aa2411b7ab17f30a99d3cb96aed1d1055b', "blockNumber": '0xb', "contractAddress": '0xb60e8dd61c5d32be8058bb8eb970870f07233155', "cumulativeGasUsed": '0x33bc', "gasUsed": '0x4dc', "logs": [], "logsBloom": "0x00...0", "status": "0x1", "transactionHash": '0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238', "transactionIndex": '0x1' } } ``` --- #### eth_getUncleByBlockHashAndIndex ##### Description Returns information about an uncle specified by block hash and uncle index position ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash of a block| |2|{[`Quantity`](#quantity)}|index of uncle| ##### Returns {`null|object`} - `null` if no block or uncle is found, otherwise an uncle object with the following members: - {[`Data`](#data)} `extraData` - "extra data" field of this block - {[`Data`](#data)} `hash` - block hash or `null` if pending - {[`Data`](#data)} `logsBloom` - logs bloom filter or `null` if pending - {[`Data`](#data)} `miner` - address that received this block's mining rewards - {[`Data`](#data)} `nonce` - proof-of-work hash or `null` if pending - {[`Data`](#data)} `parentHash` - parent block hash - {[`Data`](#data)} `receiptsRoot` -root of this block's receipts trie - {[`Data`](#data)} `sha3Uncles` - SHA3 of the uncles data in this block - {[`Data`](#data)} `stateRoot` - root of this block's final state trie - {[`Data`](#data)} `transactionsRoot` - root of this block's transaction trie - {[`Quantity`](#quantity)} `difficulty` - difficulty for this block - {[`Quantity`](#quantity)} `gasLimit` - maximum gas allowed in this block - {[`Quantity`](#quantity)} `gasUsed` - total used gas by all transactions in this block - {[`Quantity`](#quantity)} `number` - block number or `null` if pending - {[`Quantity`](#quantity)} `size` - size of this block in bytes - {[`Quantity`](#quantity)} `timestamp` - unix timestamp of when this block was collated - {[`Quantity`](#quantity)} `totalDifficulty` - total difficulty of the chain until this block - {`Array<Transaction>`} `uncles` - list of uncle hashes ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getUncleByBlockHashAndIndex", "params": ["0xc6ef2fc5426d6ad6fd9e2a26abeab0aa2411b7ab17f30a99d3cb96aed1d1055b", "0x0"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000", "gasLimit": "0x9f759", "gasUsed": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsBloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parentHash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateRoot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totalDifficulty": "0x027f07", "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [] } } ``` --- #### eth_getUncleByBlockNumberAndIndex ##### Description Returns information about an uncle specified by block number and uncle index position ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)\|`string`}|block number, or one of `"latest"`, `"earliest"` or `"pending"`| |2|{[`Quantity`](#quantity)}|index of uncle| ##### Returns {`null|object`} - `null` if no block or uncle is found, otherwise an uncle object with the following members: - {[`Data`](#data)} `extraData` - "extra data" field of this block - {[`Data`](#data)} `hash` - block hash or `null` if pending - {[`Data`](#data)} `logsBloom` - logs bloom filter or `null` if pending - {[`Data`](#data)} `miner` - address that received this block's mining rewards - {[`Data`](#data)} `nonce` - proof-of-work hash or `null` if pending - {[`Data`](#data)} `parentHash` - parent block hash - {[`Data`](#data)} `receiptsRoot` -root of this block's receipts trie - {[`Data`](#data)} `sha3Uncles` - SHA3 of the uncles data in this block - {[`Data`](#data)} `stateRoot` - root of this block's final state trie - {[`Data`](#data)} `transactionsRoot` - root of this block's transaction trie - {[`Quantity`](#quantity)} `difficulty` - difficulty for this block - {[`Quantity`](#quantity)} `gasLimit` - maximum gas allowed in this block - {[`Quantity`](#quantity)} `gasUsed` - total used gas by all transactions in this block - {[`Quantity`](#quantity)} `number` - block number or `null` if pending - {[`Quantity`](#quantity)} `size` - size of this block in bytes - {[`Quantity`](#quantity)} `timestamp` - unix timestamp of when this block was collated - {[`Quantity`](#quantity)} `totalDifficulty` - total difficulty of the chain until this block - {`Array<Transaction>`} `uncles` - list of uncle hashes ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getUncleByBlockNumberAndIndex", "params": ["0x29c", "0x0"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000", "gasLimit": "0x9f759", "gasUsed": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsBloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parentHash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateRoot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totalDifficulty": "0x027f07", "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [] } } ``` --- #### eth_getUncleCountByBlockHash ##### Description Returns the number of uncles in a block specified by block hash ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash of a block| ##### Returns {[`Quantity`](#quantity)} - number of uncles in the specified block ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getUncleCountByBlockHash", "params": ["0xc94770007dda54cF92009BFF0dE90c06F603a09f"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xc" } ``` --- #### eth_getUncleCountByBlockNumber ##### Description Returns the number of uncles in a block specified by block number ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)\|`string`}|block number, or one of `"latest"`, `"earliest"` or `"pending"`| ##### Returns {[`Quantity`](#quantity)} - number of uncles in the specified block ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getUncleCountByBlockNumber", "params": ["0xe8"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x1" } ``` --- #### eth_getWork ##### Description Returns a list containing relevant information for proof-of-work ##### Parameters _none_ ##### Returns {[`Data[]`](#data)} - array with the following items: 1. {[`Data`](#data)} - current block header pow-hash 1. {[`Data`](#data)} - seed hash used for the DAG 1. {[`Data`](#data)} - boundary condition ("target"), 2^256 / difficulty ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_getWork", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": [ "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef", "0x5EED00000000000000000000000000005EED0000000000000000000000000000", "0xd1ff1c01710000000000000000000000d1ff1c01710000000000000000000000" ] } ``` --- #### eth_hashrate ##### Description Returns the number of hashes-per-second this node is mining at ##### Parameters _(none)_ ##### Returns {[`Quantity`](#quantity)} - number of hashes-per-second ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_hashrate", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x38a" } ``` --- #### eth_mining ##### Description Determines if this client is mining new blocks ##### Parameters _(none)_ ##### Returns {`boolean`} - `true` if this client is mining or `false` if it is not mining ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_mining", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": true } ``` --- #### eth_newBlockFilter ##### Description Creates a filter to listen for new blocks that can be used with `eth_getFilterChanges` ##### Parameters _none_ ##### Returns {[`Quantity`](#quantity)} - ID of the newly-created filter that can be used with `eth_getFilterChanges` ##### Example ```sh # Request curl -X POST --data '{ "id": 1337 "jsonrpc": "2.0", "method": "eth_newBlockFilter", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x1" } ``` --- #### eth_newFilter ##### Description Creates a filter to listen for specific state changes that can then be used with `eth_getFilterChanges` ##### Parameters |#|Type|Description| |-|-|-| |1|{`object`}|@property {[`Quantity`](#quantity)\|`string`} `[fromBlock]` - block number, or one of `"latest"`, `"earliest"` or `"pending"`<br/>@property {[`Quantity`](#quantity)\|`string`} `[toBlock]` - block number, or one of `"latest"`, `"earliest"` or `"pending"`<br/>@property {[`Data`](#data)\|[`Data[]`](#data)} `[address]` - contract address or a list of addresses from which logs should originate<br/>@property {[`Data[]`](#data)} `[topics]` - list of order-dependent topics| **Note:** Topics are order-dependent. A transaction with a log with topics `[A, B]` will be matched by the following topic filters: - `[]` - "anything" - `[A]` - "A in first position (and anything after)" - `[null, B]` - "anything in first position AND B in second position (and anything after)" - `[A, B]` - "A in first position AND B in second position (and anything after)" - `[[A, B], [A, B]]` - "(A OR B) in first position AND (A OR B) in second position (and anything after)" ##### Returns {[`Quantity`](#quantity)} - ID of the newly-created filter that can be used with `eth_getFilterChanges` ##### Example ```sh # Request curl -X POST --data '{ "id": 1337 "jsonrpc": "2.0", "method": "eth_newFilter", "params": [{ "topics": ["0x0000000000000000000000000000000000000000000000000000000012341234"] }] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x1" } ``` --- #### eth_newPendingTransactionFilter ##### Description Creates a filter to listen for new pending transactions that can be used with `eth_getFilterChanges` ##### Parameters _none_ ##### Returns {[`Quantity`](#quantity)} - ID of the newly-created filter that can be used with `eth_getFilterChanges` ##### Example ```sh # Request curl -X POST --data '{ "id": 1337 "jsonrpc": "2.0", "method": "eth_newPendingTransactionFilter", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x1" } ``` --- #### eth_protocolVersion ##### Description Returns the current Ethereum protocol version ##### Parameters _(none)_ ##### Returns {`string`} - current Ethereum protocol version ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_protocolVersion", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "54" } ``` --- #### eth_sendRawTransaction ##### Description Sends and already-signed transaction to the network ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|signed transaction data| ##### Returns {[`Data`](#data)} - transaction hash, or the zero hash if the transaction is not yet available ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_sendRawTransaction", "params": ["0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" } ``` --- #### eth_sendTransaction ##### Description Creates, signs, and sends a new transaction to the network ##### Parameters |#|Type|Description| |-|-|-| |1|{`object`}|@property {[`Data`](#data)} `from` - transaction sender<br/>@property {[`Data`](#data)} `[to]` - transaction recipient<br/>@property {[`Quantity`](#quantity)} `[gas="0x15f90"]` - gas provided for transaction execution<br/>@property {[`Quantity`](#quantity)} `[gasPrice]` - price in wei of each gas used<br/>@property {[`Quantity`](#quantity)} `[value]` - value in wei sent with this transaction<br/>@property {[`Data`](#data)} `[data]` - contract code or a hashed method call with encoded args<br/>@property {[`Quantity`](#quantity)} `[nonce]` - unique number identifying this transaction| ##### Returns {[`Data`](#data)} - transaction hash, or the zero hash if the transaction is not yet available ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_sendTransaction", "params": [{ "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", "from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", "gas": "0x76c0", "gasPrice": "0x9184e72a000", "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", "value": "0x9184e72a" }] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" } ``` --- #### eth_sign ##### Description Calculates an Ethereum-specific signature in the form of `keccak256("\x19Ethereum Signed Message:\n" + len(message) + message))` ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|address to use for signing| |2|{[`Data`](#data)}|data to sign| ##### Returns {[`Data`](#data)} - signature hash of the provided data ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_sign", "params": ["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" } ``` --- #### eth_signTransaction ##### Description Signs a transaction that can be submitted to the network at a later time using with `eth_sendRawTransaction` ##### Parameters |#|Type|Description| |-|-|-| |1|{`object`}|@property {[`Data`](#data)} `from` - transaction sender<br/>@property {[`Data`](#data)} `[to]` - transaction recipient<br/>@property {[`Quantity`](#quantity)} `[gas="0x15f90"]` - gas provided for transaction execution<br/>@property {[`Quantity`](#quantity)} `[gasPrice]` - price in wei of each gas used<br/>@property {[`Quantity`](#quantity)} `[value]` - value in wei sent with this transaction<br/>@property {[`Data`](#data)} `[data]` - contract code or a hashed method call with encoded args<br/>@property {[`Quantity`](#quantity)} `[nonce]` - unique number identifying this transaction| ##### Returns {[`Data`](#data)} - signature hash of the transaction object ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_signTransaction", "params": [{ "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", "from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", "gas": "0x76c0", "gasPrice": "0x9184e72a000", "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", "value": "0x9184e72a" }] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" } ``` --- #### eth_signTypedData ##### Description Calculates an Ethereum-specific signature in the form of `keccak256("\x19Ethereum Signed Message:\n" + len(message) + message))` ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|address to use for signing| |2|{[`Data`](#data)}|message to sign containing type information, a domain separator, and data| **Note:** Client developers should refer to EIP-712 for complete semantics around [encoding and signing data](/EIPS/eip-712#specification). Dapp developers should refer to EIP-712 for the expected structure of [RPC method input parameters](/EIPS/eip-712#parameters). ##### Returns {[`Data`](#data)} - signature hash of the provided message ##### Example ```sh # Request curl -X POST --data '{ "id": 1337 "jsonrpc": "2.0", "method": "eth_signTypedData", "params": ["0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826", { "types": { "EIP712Domain": [{ "name": "name", "type": "string" }, { "name": "version", "type": "string" }, { "name": "chainId", "type": "uint256" }, { "name": "verifyingContract", "type": "address" }], "Person": [{ "name": "name", "type": "string" }, { "name": "wallet", "type": "address" }], "Mail": [{ "name": "from", "type": "Person" }, { "name": "to", "type": "Person" }, { "name": "contents", "type": "string" }] }, "primaryType": "Mail", "domain": { "name": "Ether Mail", "version": "1", "chainId": 1, "verifyingContract": "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC" }, "message": { "from": { "name": "Cow", "wallet": "0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826" }, "to": { "name": "Bob", "wallet": "0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB" }, "contents": "Hello, Bob!" } }] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": "0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c" } ``` --- #### eth_submitHashrate ##### Description Submit a mining hashrate ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|hash rate| |2|{[`Data`](#data)}|random ID identifying this node| ##### Returns {`boolean`} - `true` if submitting went through successfully, `false` otherwise ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_submitHashrate", "params": [ "0x0000000000000000000000000000000000000000000000000000000000500000", "0x59daa26581d0acd1fce254fb7e85952f4c09d0915afd33d3886cd914bc7d283c" ] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": true } ``` --- #### eth_submitWork ##### Description Submit a proof-of-work solution ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Data`](#data)}|nonce found| |2|{[`Data`](#data)}|header's pow-hash| |3|{[`Data`](#data)}|mix digest| ##### Returns {`boolean`} - `true` if the provided solution is valid, `false` otherwise ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_submitWork", "params": [ "0x0000000000000001", "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef", "0xD1GE5700000000000000000000000000D1GE5700000000000000000000000000" ] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": true } ``` --- #### eth_syncing ##### Description Returns information about the status of this client's network synchronization ##### Parameters _(none)_ ##### Returns {`boolean|object`} - `false` if this client is not syncing with the network, otherwise an object with the following members: - {[`Quantity`](#quantity)} `currentBlock` - number of the most-recent block synced - {[`Quantity`](#quantity)} `highestBlock` - number of latest block on the network - {[`Quantity`](#quantity)} `startingBlock` - block number at which syncing started ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_syncing", "params": [] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": { "currentBlock": '0x386', "highestBlock": '0x454', "startingBlock": '0x384' } } ``` --- #### eth_uninstallFilter ##### Description Destroys a filter based on filter ID **Note:** This should only be called if a filter and its notifications are no longer needed. This will also be called automatically on a filter if its notifications are not retrieved using `eth_getFilterChanges` for a period of time. ##### Parameters |#|Type|Description| |-|-|-| |1|{[`Quantity`](#quantity)}|ID of the filter to destroy| ##### Returns {`boolean`} - `true` if the filter is found and successfully destroyed or `false` if it is not ##### Example ```sh # Request curl -X POST --data '{ "id": 1337, "jsonrpc": "2.0", "method": "eth_uninstallFilter", "params": ["0xb"] }' <url> # Response { "id": 1337, "jsonrpc": "2.0", "result": true } ``` --- ## Rationale Much of Ethereum's effectiveness as an enterprise-grade application platform depends on its ability to provide a reliable and predictable developer experience. Nodes created by the current generation of Ethereum clients expose RPC endpoints with differing method signatures; this forces applications to work around method inconsistencies to maintain compatibility with various Ethereum RPC implementations. Both Ethereum client developers and downstream dapp developers lack a formal Ethereum RPC specification. This proposal standardizes such a specification in a way that's versionable and modifiable through the traditional EIP process. ## Backwards compatibility This proposal impacts Ethereum client developers by requiring that any exposed RPC interface adheres to this specification. This proposal impacts dapp developers by requiring that any RPC calls currently used in applications are made according to this specification. ## Implementation The current generation of Ethereum clients includes several implementations that attempt to expose this RPC specification: |Client Name|Language|Homepage| |-|-|-| |Geth|Go|[geth.ethereum.org](https://geth.ethereum.org)| |Parity|Rust|[parity.io/ethereum](https://parity.io/ethereum)| |Aleth|C++|[cpp-ethereum.org](https://cpp-ethereum.org)| ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 02 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1474 https://eips.ethereum.org/EIPS/eip-1474 Define a maximum block timestamp drift Standards Track/Core https://ethereum-magicians.org/t/define-a-maximum-block-timestamp-drift/1556 ## Simple Summary Include an explicit definition of the acceptable timestamp drift in the protocol specification. ## Abstract On the basis that both Geth and Parity implement the same timestamp validation requirements, this should be written into the reference specification. ## Motivation There is a lack of clarity about how accurate timestamps in the block header must be. The yellow paper describes the timestamp as > A scalar value equal to the reasonable output of Unix’s time() at this block’s inception This causes [confusion](https://ethereum.stackexchange.com/questions/5924/how-do-ethereum-mining-nodes-maintain-a-time-consistent-with-the-network/5926#5926) about the safe use of the `TIMESTAMP` opcode (solidity's `block.timestamp` or `now`) in smart contract development. Differing interpretations of 'reasonable' may create a risk of consenus failures. ## Specification The yellow paper should define a timestamp as: > A scalar value equal to the output of Unix’s time() at this block’s inception. For the purpose of block validation, it must be greater than the previous block's timestamp, and no more than 15 seconds greater than system time. ## Rationale Both [Geth](https://github.com/ethereum/go-ethereum/blob/4e474c74dc2ac1d26b339c32064d0bac98775e77/consensus/ethash/consensus.go#L45) and [Parity](https://github.com/paritytech/parity-ethereum/blob/73db5dda8c0109bb6bc1392624875078f973be14/ethcore/src/verification/verification.rs#L296-L307) reject blocks with timestamp more than 15 seconds in the future. This establishes a defacto standard, which should be made explicit in the reference specification. ## Backwards Compatibility It may be necessary to relax this requirement for blocks which were mined early in the main chain's history, if they would be considered invalid. ## Test Cases These would be important to have. ## Implementation _The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. _ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 09 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1482 https://eips.ethereum.org/EIPS/eip-1482 Digital Identity Aggregator Standards Track/ERC https://github.com/ethereum/EIPs/issues/1495 ## Simple Summary A protocol for aggregating digital identity information that's broadly interoperable with existing, proposed, and hypothetical future digital identity standards. ## Abstract This EIP proposes an identity management and aggregation framework on the Ethereum blockchain. It allows entities to claim an `Identity` via a singular `Identity Registry` smart contract, associate it with Ethereum addresses in a variety of meaningful ways, and use it to interact with smart contracts. This enables arbitrarily complex identity-related functionality. Notably (among other features) ERC-1484 `Identities`: are self-sovereign, can natively support [ERC-725](/EIPS/eip-725) and [ERC-1056](/EIPS/eip-1056) identities, are [DID compliant](https://github.com/NoahZinsmeister/ERC-1484/blob/master/best-practices/DID-Method.md), and can be fully powered by [meta-transactions](https://github.com/NoahZinsmeister/ERC-1484/tree/master/contracts/examples/Providers/MetaTransactions). ## Motivation Emerging identity standards and related frameworks proposed by the Ethereum community (including ERCs/EIPs [725](/EIPS/eip-725), [735](https://github.com/ethereum/EIPs/issues/735), [780](https://github.com/ethereum/EIPs/issues/780), [1056](/EIPS/eip-1056), etc.) define and instrumentalize digital identity in a variety of ways. As existing approaches mature, new standards emerge, and isolated, non-standard approaches to identity develop, coordinating on identity will become increasingly burdensome for blockchain users and developers, and involve the unnecessary duplication of work. The proliferation of on-chain identity solutions can be traced back to the fact that each codifies a notion of identity and links it to specific aspects of Ethereum (claims protocols, per-identity smart contracts, signature verification schemes, etc.). This proposal eschews that approach, instead introducing a protocol layer in between the Ethereum network and individual identity applications. This solves identity management and interoperability challenges by enabling any identity-driven application to leverage an un-opinionated identity management protocol. ## Definitions - `Identity Registry`: A single smart contract which is the hub for all `Identities`. The primary responsibility of the `Registry` is to define and enforce the rules of a global namespace for `Identities`, which are individually denominated by Ethereum Identification Numbers (EINs). - `Identity`: A data structure containing all the core information relevant to an identity, namely: a `Recovery Address`, an `Associated Addresses` set, a `Providers` set, and a `Resolvers` set. `Identities` are denominated by EINs (incrementing `uint` identifiers starting at 1), which are unique but otherwise uninformative. Each `Identity` is a Solidity struct: ```solidity struct Identity { address recoveryAddress; AddressSet.Set associatedAddresses; AddressSet.Set providers; AddressSet.Set resolvers; } ``` - `Associated Address`: An Ethereum address publicly associated with an `Identity`. In order for an address to become an `Associated Address`, an `Identity` must either transact from or produce an appropriately signed message from the candidate address and an existing `Associated Address`, indicating intent to associate. An `Associated Address` can be removed from an `Identity` by transacting/producing a signature indicating intent to disassociate. A given address may only be an `Associated Address` for one `Identity` at any given time. - `Provider`: An Ethereum address (typically but not by definition a smart contract) authorized to act on behalf of `Identities` who have authorized them to do so. This includes but is not limited to managing the `Associated Address`, `Provider`, and `Resolver` sets for an `Identity`. `Providers` exist to facilitate user adoption by making it easier to manage `Identities`. - `Resolver`: A smart contract containing arbitrary information pertaining to `Identities`. A resolver may implement an identity standard, such as ERC-725, or may consist of a smart contract leveraging or declaring identifying information about `Identities`. These could be simple attestation structures or more sophisticated financial dApps, social media dApps, etc. Each `Resolver` added to an `Identity` makes the `Identity` more informative. - `Recovery Address`: An Ethereum address (either an account or smart contract) that can be used to recover lost `Identities` as outlined in the [Recovery](#recovery) section. - `Destruction`: In the event of irrecoverable loss of control of an `Identity`, `Destruction` is a contingency measure to permanently disable the `Identity`. It removes all `Associated Addresses`, `Providers`, and optionally `Resolvers` while preserving the `Identity`. Evidence of the existence of the `Identity` persists, while control over the `Identity` is nullified. ## Specification A digital identity in this proposal can be viewed as an omnibus account, containing more information about an identity than any individual identity application could. This omnibus identity is resolvable to an unlimited number of sub-identities called `Resolvers`. This allows an atomic entity, the `Identity`, to be resolvable to abstract data structures, the `Resolvers`. `Resolvers` recognize `Identities` by any of their `Associated Addresses`, or by their `EIN`. The protocol revolves around claiming an `Identity` and managing `Associated Addresses`, `Providers` and `Resolvers`. Identities can delegate much or all of this responsibility to one or more `Providers`, or perform it directly from an `Associated Address`. `Associated Addresses`/`Providers` may add and remove `Resolvers` and `Providers` indiscriminately. `Associated Addresses` may only be added or removed with the appropriate permission. ### Identity Registry The `Identity Registry` contains functionality to create new `Identities` and for existing `Identities` to manage their `Associated Addresses`, `Providers`, and `Resolvers`. It is important to note that this registry fundamentally requires transactions for every aspect of building out an `Identity`. However, recognizing the importance of accessibility to dApps and identity applications, we empower `Providers` to build out `Identities` on the behalf of users, without requiring users to pay gas costs. An example of this pattern, often referred to as a meta transactions, can be [seen in the reference implementation](https://github.com/NoahZinsmeister/ERC-1484/tree/master/contracts/examples/Providers/MetaTransactions). Due to the fact that multiple addresses can be associated with a given identity (though not the reverse), `Identities` are denominated by `EIN`. This `uint` identifier can be encoded in QR format or mapped to more user-friendly formats, such as a `string`, in registries at the `Provider` or `Resolver` level. ### Address Management The address management function consists of trustlessly connecting multiple user-owned `Associated Addresses` to an `Identity`. It does not give special status to any particular `Associated Address`, rather leaving this (optional) specification to identity applications built on top of the protocol - for instance, `management`, `action`, `claim` and `encryption` keys denominated in the ERC-725 standard, or `identifiers` and `delegates` as denominated in ERC-1056. This allows a user to access common identity data from multiple wallets while still: - retaining the ability to interact with contracts outside of their identity - taking advantage of address-specific permissions established at the application layer of a user's identity. Trustlessness in the address management function is achieved through a robust permissioning scheme. To add an `Associated Address` to an `Identity`, implicit permission from a transaction sender or explicit permission from a signature is required from 1) an address already within the registry and 2) an address to be claimed. Importantly, the transaction need not come from any particular address, as long as permission is established, which allows not only users but third parties (companies, governments, etc.) to bear the overhead of managing identities. To prevent a compromised `Associated Address` from unilaterally removing other `Associated Addresses`, it's only possible to remove an `Associated Address` by transacting or producing a signature from it. All signatures required in ERC-1484 are designed per the [ERC-191](/EIPS/eip-191) v0 specification. To avoid replay attacks, all signatures must include a timestamp within a rolling lagged window of the current `block.timestamp`. For more information, see this [best practices document](https://github.com/NoahZinsmeister/ERC-1484/blob/master/best-practices/VerifyingSignatures.md) in the reference implementation. ### Provider Management While the protocol allows users to directly call identity management functions, it also aims to be more robust and future-proof by allowing `Providers`, typically smart contracts, to perform identity management functions on a user's behalf. A `Provider` set by an `Identity` can perform address management and resolver management functions by passing a user's `EIN` in function calls. ### Resolver Management A `Resolver` is any smart contract that encodes information which resolves to an `Identity`. We remain agnostic about the specific information that can be encoded in a resolver and the functionality that this enables. The existence of `Resolvers` is primarily what makes this ERC an identity *protocol* rather than an identity *application*. `Resolvers` resolve abstract data in smart contracts to an atomic entity, the `Identity`. ### Recovery If users lose control over an `Associated Address`, the `Recovery Address` provides a fallback mechanism. Upon `Identity` creation, a `Recovery Address` is passed as a parameter by the creator. Recovery functionality is triggered in three scenarios: **1. Changing Recovery Address**: If a recovery key is lost, an `Associated Address`/`Provider` can [triggerRecoveryAddressChange](#triggerrecoveryaddresschange)/[triggerRecoveryAddressChangeFor](#triggerrecoveryaddresschangefor). To prevent malicious behavior from someone who has gained control of an `Associated Address` or `Provider` and is changing the `Recovery Address` to one under their control, this action triggers a 14 day challenge period during which the old `Recovery Address` may reject the change by [triggering recovery](#triggerrecovery). If the `Recovery Address` does not reject the change within 14 days, the `Recovery Address` is changed. **2. Recovery**: Recovery occurs when a user recognizes that an `Associated Address` or the `Recovery Address` belonging to the user is lost or stolen. In this instance the `Recovery Address` must call [triggerRecovery](#triggerrecovery). This removes all `Associated Addresses` and `Providers` from the corresponding `Identity` and replaces them with an address passed in the function call. The `Identity` and associated `Resolvers` maintain integrity. The user is now responsible for adding the appropriate un-compromised addresses back to their `Identity`. *Importantly, the `Recovery Address` can be a user-controlled wallet or another address, such as a multisig wallet or smart contract. This allows for arbitrarily sophisticated recovery logic! This includes the potential for recovery to be fully compliant with standards such as [DID](https://decentralized.id/).* **3. Destruction** The Recovery scheme offers considerable power to a `Recovery Address`; accordingly, `Destruction` is a nuclear option to combat malicious control over an `Identity` when a `Recovery Address` is compromised. If a malicious actor compromises a user's `Recovery Address` and triggers recovery, any address removed in the `Recovery` process can call [triggerDestruction](#triggerdestruction) within 14 days to permanently disable the `Identity`. The user would then need to create a new `Identity`, and would be responsible for engaging in recovery schemes for any identity applications built in the `Resolver` or `Provider` layers. #### Alternative Recovery Considerations We considered many possible alternatives when devising the Recovery process outlined above. We ultimately selected the scheme that was most un-opinionated, modular, and consistent with the philosophy behind the `Associated Address`, `Provider`, and `Resolver` components. Still, we feel that it is important to highlight some of the other recovery options we considered, to provide a rationale as to how we settled on what we did. **High Level Concerns** Fundamentally, a Recovery scheme needs to be resilient to a compromised address taking control of a user's `Identity`. A secondary concern is preventing a compromised address from maliciously destroying a user's identity due to off-chain utility, which is not an optimal scenario, but is strictly better than if they've gained control. **Alternative 1: Nuclear Option** This approach would allow any `Associated Address` to destroy an `Identity` whenever another `Associated Address` is compromised. While this may seem severe, we strongly considered it because this ERC is an identity *protocol*, not an identity *application*. This means that though a user's compromised `Identity` is destroyed, they should still have recourse to whatever restoration mechanisms are available in each of their actual identities at the `Resolver` and/or `Provider` level. We ultimately dismissed this approach for two main reasons: - It is not robust in cases where a user has only one `Associated Address` - It would increase the frequency of recovery requests to identity applications due to its unforgiving nature. **Alternative 2: Unilateral Address Removal via Providers** This would allow `Associated Addresses`/`Providers` to remove `Associated Addresses` without a signature from said address. This implementation would allow `Providers` to include arbitrarily sophisticated schemes for removing a rogue address - for instance, multi-sig requirements, centralized off-chain verification, user controlled master addresses, deferral to a jurisdictional contract, and more. To prevent a compromised `Associated Address` from simply setting a malicious `Provider` to remove un-compromised addresses, it would have required a waiting period between when a `Provider` is set and when they would be able to remove an `Associated Address`. We dismissed this approach because we felt it placed too high of a burden on `Providers`. If a `Provider` offered a sophisticated range of functionality to a user, but post-deployment a threat was found in the Recovery logic of the provider, `Provider`-specific infrastructure would need to be rebuilt. We also considered including a flag that would allow a user to decide whether or not a `Provider` may remove `Associated Addresses` unilaterally. Ultimately, we concluded that only allowing removal of `Associated Addresses` via the `Recovery Address` enables equally sophisticated recovery logic while separating the functionality from `Providers`, leaving less room for users to relinquish control to potentially flawed implementations. ## Rationale We find that at a protocol layer, identities should not rely on specific claim or attestation structures, but should instead be a part of a trustless framework upon which arbitrarily sophisticated claim and attestation structures may be built. The main criticism of existing identity solutions is that they're overly restrictive. We aim to limit requirements, keep identities modular and future-proof, and remain un-opinionated regarding any functionality a particular identity component may have. This proposal gives users the option to interact on the blockchain using an robust `Identity` rather than just an address. ## Implementation **The reference implementation for ERC-1484 may be found in [NoahZinsmeister/ERC-1484](https://github.com/NoahZinsmeister/ERC-1484).** #### identityExists Returns a `bool` indicating whether or not an `Identity` denominated by the passed `EIN` exists. ```solidity function identityExists(uint ein) public view returns (bool); ``` #### hasIdentity Returns a `bool` indicating whether or not the passed `_address` is associated with an `Identity`. ```solidity function hasIdentity(address _address) public view returns (bool); ``` #### getEIN Returns the `EIN` associated with the passed `_address`. Throws if the address is not associated with an `EIN`. ```solidity function getEIN(address _address) public view returns (uint ein); ``` #### isAssociatedAddressFor Returns a `bool` indicating whether or not the passed `_address` is associated with the passed `EIN`. ```solidity function isAssociatedAddressFor(uint ein, address _address) public view returns (bool); ``` #### isProviderFor Returns a `bool` indicating whether or not the passed `provider` has been set by the passed `EIN`. ```solidity function isProviderFor(uint ein, address provider) public view returns (bool); ``` #### isResolverFor Returns a `bool` indicating whether or not the passed `resolver` has been set by the passed `EIN`. ```solidity function isResolverFor(uint ein, address resolver) public view returns (bool); ``` #### getIdentity Returns the `recoveryAddress`, `associatedAddresses`, `providers` and `resolvers` of the passed `EIN`. ```solidity function getIdentity(uint ein) public view returns ( address recoveryAddress, address[] memory associatedAddresses, address[] memory providers, address[] memory resolvers ); ``` #### createIdentity Creates an `Identity`, setting the `msg.sender` as the sole `Associated Address`. Returns the `EIN` of the new `Identity`. ```solidity function createIdentity(address recoveryAddress, address[] memory providers, address[] memory resolvers) public returns (uint ein); ``` Triggers event: [IdentityCreated](#identitycreated) #### createIdentityDelegated Performs the same logic as `createIdentity`, but can be called by any address. This function requires a signature from the `associatedAddress` to ensure their consent. ```solidity function createIdentityDelegated( address recoveryAddress, address associatedAddress, address[] memory providers, address[] memory resolvers, uint8 v, bytes32 r, bytes32 s, uint timestamp ) public returns (uint ein); ``` Triggers event: [IdentityCreated](#identitycreated) #### addAssociatedAddress Adds the `addressToAdd` to the `EIN` of the `approvingAddress`. The `msg.sender` must be either of the `approvingAddress` or the `addressToAdd`, and the signature must be from the other one. ```solidity function addAssociatedAddress( address approvingAddress, address addressToAdd, uint8 v, bytes32 r, bytes32 s, uint timestamp ) public ``` Triggers event: [AssociatedAddressAdded](#associatedaddressadded) #### addAssociatedAddressDelegated Adds the `addressToAdd` to the `EIN` of the `approvingAddress`. Requires signatures from both the `approvingAddress` and the `addressToAdd`. ```solidity function addAssociatedAddressDelegated( address approvingAddress, address addressToAdd, uint8[2] memory v, bytes32[2] memory r, bytes32[2] memory s, uint[2] memory timestamp ) public ``` Triggers event: [AssociatedAddressAdded](#associatedaddressadded) #### removeAssociatedAddress Removes the `msg.sender` as an `Associated Address` from its `EIN`. ```solidity function removeAssociatedAddress() public; ``` Triggers event: [AssociatedAddressRemoved](#associatedaddressremoved) #### removeAssociatedAddressDelegated Removes the `addressToRemove` from its associated `EIN`. Requires a signature from the `addressToRemove`. ```solidity function removeAssociatedAddressDelegated(address addressToRemove, uint8 v, bytes32 r, bytes32 s, uint timestamp) public; ``` Triggers event: [AssociatedAddressRemoved](#associatedaddressremoved) #### addProviders Adds an array of `Providers` to the `Identity` of the `msg.sender`. ```solidity function addProviders(address[] memory providers) public; ``` Triggers event: [ProviderAdded](#provideradded) #### addProvidersFor Performs the same logic as `addProviders`, but must be called by a `Provider`. ```solidity function addProvidersFor(uint ein, address[] memory providers) public; ``` Triggers event: [ProviderAdded](#provideradded) #### removeProviders Removes an array of `Providers` from the `Identity` of the `msg.sender`. ```solidity function removeProviders(address[] memory providers) public; ``` Triggers event: [ProviderRemoved](#providerremoved) #### removeProvidersFor Performs the same logic as `removeProviders`, but is called by a `Provider`. ```solidity function removeProvidersFor(uint ein, address[] memory providers) public; ``` Triggers event: [ProviderRemoved](#providerremoved) #### addResolvers Adds an array of `Resolvers` to the `EIN` of the `msg.sender`. ```solidity function addResolvers(address[] memory resolvers) public; ``` Triggers event: [ResolverAdded](#resolveradded) #### addResolversFor Performs the same logic as `addResolvers`, but must be called by a `Provider`. ```solidity function addResolversFor(uint ein, address[] memory resolvers) public; ``` Triggers event: [ResolverAdded](#resolveradded) #### removeResolvers Removes an array of `Resolvers` from the `EIN` of the `msg.sender`. ```solidity function removeResolvers(address[] memory resolvers) public; ``` Triggers event: [ResolverRemoved](#resolverremoved) #### removeResolversFor Performs the same logic as `removeResolvers`, but must be called by a `Provider`. ```solidity function removeResolversFor(uint ein, address[] memory resolvers) public; ``` Triggers event: [ResolverRemoved](#resolverremoved) #### triggerRecoveryAddressChange Initiates a change in the current `recoveryAddress` for the `EIN` of the `msg.sender`. ```solidity function triggerRecoveryAddressChange(address newRecoveryAddress) public; ``` Triggers event: [RecoveryAddressChangeTriggered](#recoveryaddresschangetriggered) #### triggerRecoveryAddressChangeFor Initiates a change in the current `recoveryAddress` for a given `EIN`. ```solidity function triggerRecoveryAddressChangeFor(uint ein, address newRecoveryAddress) public; ``` Triggers event: [RecoveryAddressChangeTriggered](#recoveryaddresschangetriggered) #### triggerRecovery Triggers `EIN` recovery from the current `recoveryAddress`, or the old `recoveryAddress` if changed within the last 2 weeks. ```solidity function triggerRecovery(uint ein, address newAssociatedAddress, uint8 v, bytes32 r, bytes32 s, uint timestamp) public; ``` Triggers event: [RecoveryTriggered](#recoverytriggered) #### triggerDestruction Triggers destruction of an `EIN`. This renders the `Identity` permanently unusable. ```solidity function triggerDestruction(uint ein, address[] memory firstChunk, address[] memory lastChunk, bool clearResolvers) public; ``` Triggers event: [IdentityDestroyed](#identitydestroyed) ### Events #### IdentityCreated MUST be triggered when an `Identity` is created. ```solidity event IdentityCreated( address indexed initiator, uint indexed ein, address recoveryAddress, address associatedAddress, address[] providers, address[] resolvers, bool delegated ); ``` #### AssociatedAddressAdded MUST be triggered when an address is added to an `Identity`. ```solidity event AssociatedAddressAdded( address indexed initiator, uint indexed ein, address approvingAddress, address addedAddress, bool delegated ); ``` #### AssociatedAddressRemoved MUST be triggered when an address is removed from an `Identity`. ```solidity event AssociatedAddressRemoved(address indexed initiator, uint indexed ein, address removedAddress, bool delegated); ``` #### ProviderAdded MUST be triggered when a provider is added to an `Identity`. ```solidity event ProviderAdded(address indexed initiator, uint indexed ein, address provider, bool delegated); ``` #### ProviderRemoved MUST be triggered when a provider is removed. ```solidity event ProviderRemoved(address indexed initiator, uint indexed ein, address provider, bool delegated); ``` #### ResolverAdded MUST be triggered when a resolver is added. ```solidity event ResolverAdded(address indexed initiator, uint indexed ein, address resolvers, bool delegated); ``` #### ResolverRemoved MUST be triggered when a resolver is removed. ```solidity event ResolverRemoved(address indexed initiator, uint indexed ein, address resolvers, bool delegated); ``` #### RecoveryAddressChangeTriggered MUST be triggered when a recovery address change is triggered. ```solidity event RecoveryAddressChangeTriggered( address indexed initiator, uint indexed ein, address oldRecoveryAddress, address newRecoveryAddress, bool delegated ); ``` #### RecoveryTriggered MUST be triggered when recovery is triggered. ```solidity event RecoveryTriggered( address indexed initiator, uint indexed ein, address[] oldAssociatedAddresses, address newAssociatedAddress ); ``` #### IdentityDestroyed MUST be triggered when an `Identity` is destroyed. ```solidity event IdentityDestroyed(address indexed initiator, uint indexed ein, address recoveryAddress, bool resolversReset); ``` ### Solidity Interface ```solidity interface IdentityRegistryInterface { function isSigned(address _address, bytes32 messageHash, uint8 v, bytes32 r, bytes32 s) external pure returns (bool); // Identity View Functions ///////////////////////////////////////////////////////////////////////////////////////// function identityExists(uint ein) external view returns (bool); function hasIdentity(address _address) external view returns (bool); function getEIN(address _address) external view returns (uint ein); function isAssociatedAddressFor(uint ein, address _address) external view returns (bool); function isProviderFor(uint ein, address provider) external view returns (bool); function isResolverFor(uint ein, address resolver) external view returns (bool); function getIdentity(uint ein) external view returns ( address recoveryAddress, address[] memory associatedAddresses, address[] memory providers, address[] memory resolvers ); // Identity Management Functions /////////////////////////////////////////////////////////////////////////////////// function createIdentity(address recoveryAddress, address[] calldata providers, address[] calldata resolvers) external returns (uint ein); function createIdentityDelegated( address recoveryAddress, address associatedAddress, address[] calldata providers, address[] calldata resolvers, uint8 v, bytes32 r, bytes32 s, uint timestamp ) external returns (uint ein); function addAssociatedAddress( address approvingAddress, address addressToAdd, uint8 v, bytes32 r, bytes32 s, uint timestamp ) external; function addAssociatedAddressDelegated( address approvingAddress, address addressToAdd, uint8[2] calldata v, bytes32[2] calldata r, bytes32[2] calldata s, uint[2] calldata timestamp ) external; function removeAssociatedAddress() external; function removeAssociatedAddressDelegated(address addressToRemove, uint8 v, bytes32 r, bytes32 s, uint timestamp) external; function addProviders(address[] calldata providers) external; function addProvidersFor(uint ein, address[] calldata providers) external; function removeProviders(address[] calldata providers) external; function removeProvidersFor(uint ein, address[] calldata providers) external; function addResolvers(address[] calldata resolvers) external; function addResolversFor(uint ein, address[] calldata resolvers) external; function removeResolvers(address[] calldata resolvers) external; function removeResolversFor(uint ein, address[] calldata resolvers) external; // Recovery Management Functions /////////////////////////////////////////////////////////////////////////////////// function triggerRecoveryAddressChange(address newRecoveryAddress) external; function triggerRecoveryAddressChangeFor(uint ein, address newRecoveryAddress) external; function triggerRecovery(uint ein, address newAssociatedAddress, uint8 v, bytes32 r, bytes32 s, uint timestamp) external; function triggerDestruction( uint ein, address[] calldata firstChunk, address[] calldata lastChunk, bool resetResolvers ) external; // Events ////////////////////////////////////////////////////////////////////////////////////////////////////////// event IdentityCreated( address indexed initiator, uint indexed ein, address recoveryAddress, address associatedAddress, address[] providers, address[] resolvers, bool delegated ); event AssociatedAddressAdded( address indexed initiator, uint indexed ein, address approvingAddress, address addedAddress ); event AssociatedAddressRemoved(address indexed initiator, uint indexed ein, address removedAddress); event ProviderAdded(address indexed initiator, uint indexed ein, address provider, bool delegated); event ProviderRemoved(address indexed initiator, uint indexed ein, address provider, bool delegated); event ResolverAdded(address indexed initiator, uint indexed ein, address resolvers); event ResolverRemoved(address indexed initiator, uint indexed ein, address resolvers); event RecoveryAddressChangeTriggered( address indexed initiator, uint indexed ein, address oldRecoveryAddress, address newRecoveryAddress ); event RecoveryTriggered( address indexed initiator, uint indexed ein, address[] oldAssociatedAddresses, address newAssociatedAddress ); event IdentityDestroyed(address indexed initiator, uint indexed ein, address recoveryAddress, bool resolversReset); } ``` ## Backwards Compatibility `Identities` established under this standard consist of existing Ethereum addresses; accordingly, there are no backwards compatibility issues. Deployed, non-upgradeable smart contracts that wish to become `Resolvers` for `Identities` will need to write wrapper contracts that resolve addresses to `EIN`-denominated `Identities`. ## Additional References - [ERC-1484 Reference Implementation](https://github.com/NoahZinsmeister/ERC-1484) - [ERC-191 Signatures](/EIPS/eip-191) - [ERC-725 Identities](/EIPS/eip-725) - [ERC-1056 Identities](/EIPS/eip-1056) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 12 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1484 https://eips.ethereum.org/EIPS/eip-1484 TEthashV1 Standards Track/Core https://ethereum-magicians.org/t/anti-eth-asic-mining-eip-1488-pr/1807 ## Simple Summary This EIP modifies ethash in order to break ASIC miners specialized for the current ethash mining algorithm. ## Abstract This EIP pursue "obsolete current ASIC miners" by modifying PoW algorithm in a very low risk manner and update to latest hash algorithm from deprecated FNV Hash algorithms. Following TEthashV1 algorithm suggests safe transition of PoW algorithms and secure the FNV Algorithm in MIX Parts. ## Motivation Provide original Ethash proof of work verification with minimal set of changes by updating FNV0 algorithm ## Specification #### 1. Reference materials on ETHASH FNV0 #### Where FNV Applied on ETHASH - In [ETHASH](https://web.archive.org/web/20200505215203/https://github.com/ethereum/wiki/wiki/Ethash), FNV Hash is used on * 1) On data aggregation function, MIX parts. * Ethash Algorithm ``` Header + Nonce | Keccak | **[MIX 0]** --> **[DAG Page]** | | Mixing <--| ... | **[Mix 63]** | |-----> Mix64 [Process] ---> Mix Digest [32B] ``` * FNV used in DAG Generation and Mixing for random access or DAG Page. #### 2. Current applied Ethash FNV hash implementation is deprecated now. [FNV-0_hash (deprecated)](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-0_hash_(deprecated)) It is a simple way of hashing algorithm ``` hash = 0 for each byte_of_data to be hashed hash = hash × FNV_prime hash = hash XOR octet_of_data return hash ``` When analysed FNV-0 , there's very weak [avalanche effect](https://simple.wikipedia.org/wiki/Avalanche_effect), when hash input changes on 1~2bits. refer [FNV-Analysis reference section](https://github.com/tao-foundation/FNV-Analysis#how-to-test-and-analysis-reference-test-code) We need to research and apply newer FNV hash or short message hash algorithm. #### 3. FNV1A hash algorithm description Previous proposed algorithm based on FNV1 [EIP-1355](/EIPS/eip-1355) There's an implementation that looks like "Missing Offset Bias" at **FNV1A**. Quotation of [original algorithm FNV1A](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-1a_hash) ``` use hash offset FNV-1a hash The FNV-1a hash differs from the FNV-1 hash by only the order in which the multiply and XOR is performed:[8][10] hash = FNV_offset_basis for each byte_of_data to be hashed hash = hash XOR byte_of_data hash = hash × FNV_prime return hash ``` FNV_offset_basis and computation order change of xor and multiplication Makes one more xor and multiply computation, but more secure hash effects than FNV0. and make dispersion boundary condition (0, even number, ..) by using of Prime Number. #### 4. Real Implementation for FNV1A Consider real computation resources, in TEthashV1 uses hash byte_of_data to 4bytes aligned data. In TETHashV1, Adapts fully follow the FNV1A implementation. - TETHASHV1 FNV1A implementation Following are reference implementation of FNV1A adapted in TETHashV1. ```cpp // Reference Pseudo c/cpp implementation #define FNV_PRIME 0x01000193U #define FNV_OFFSET_BASIS 0x811c9dc5U #define fnv1a(x, y) ((((FNV_OFFSET_BASIS^(x))*FNV_PRIME) ^ (y)) * FNV_PRIME) #define fnv1a_reduce(a,b,c,d) (fnv1a(fnv1a(fnv1a(a, b), c), d)) ``` Another Byte aligned implementation of FNV1A , call to FNV1c ```cpp #define FNV_PRIME 0x01000193U #define FNV_OFFSET_BASIS 0x811c9dc5U #define fnv1i(x) ( (( (( (( \ ( ((FNV_OFFSET_BASIS)^( ((x)>>24)&0x000000ff )) * FNV_PRIME) \ ^ (((x)>>16 )&0x000000ff)) * FNV_PRIME) \ ^ (((x)>>8 )&0x000000ff)) * FNV_PRIME) \ ^ (((x) )&0x000000ff)) * FNV_PRIME) \ ) #define fnv1c(x, y) ((fnv1i(x) ^ (y)) * FNV_PRIME) ``` #### 5. [FNV-Analysis](https://github.com/tao-foundation/FNV-Analysis) FNV Mix Algorithm Analysis for TEthashV1 #### How to test and analysis reference test code. You can compile it with simple in terminal. No additional library needs, ```sh gcc -o fnvtest fnvcltest.c ``` And You can execute it ``` fnvtest F(00,00)::VEC(0, 0, ffffffff, 0):: FNV :00000000, DF=00000000(00) DS(00000000), FNV1 :00000000, DF=00000000(00) DS(00000000), FNV1a:117697cd, DF=117697cd(17) DS(117697cd), FNV1c:1210d00f, DF=127f8dbf(20) DS(11a1725f), F___RC=efe1b9c4, DF:efe1b9c4(19) , F1__RC=deb68dfe, DF:deb68dfe(22) , F1A_RC=99bad28b, DF:99bad28b(17) , F1C_RC=e29fa497, DF:e29fa497(18) F(00,01)::VEC(0, 1, ffffffff, 0):: FNV :00000001, DF=00000001(01) DS(00000001), FNV1 :01000193, DF=01000193(06) DS(01000193), FNV1a:1076963a, DF=010001f7(09) DS(01000193), FNV1c:1110ce7c, DF=03001e73(11) DS(01000193), F___RC=fefffe6d, DF:111e47a9(14) , F1__RC=d9fd8597, DF:074b0869(12) , F1A_RC=72c287e0, DF:eb78556b(19) , F1C_RC=6b6991ef, DF:89f63578(17) F(00,02)::VEC(0, 2, ffffffff, 0):: FNV :00000002, DF=00000003(02) DS(00000001), FNV1 :02000326, DF=030002b5(08) DS(01000193), FNV1a:0f7694a7, DF=1f00029d(11) DS(01000193), FNV1c:1410d335, DF=05001d49(09) DS(030004b9), F___RC=d8fd8404, DF:26027a69(13) , F1__RC=9b16d24c, DF:42eb57db(19) , F1A_RC=c17f0ecb, DF:b3bd892b(18) , F1C_RC=a5be8e78, DF:ced71f97(21) F(00,03)::VEC(0, 3, ffffffff, 0):: FNV :00000003, DF=00000001(01) DS(00000001), FNV1 :030004b9, DF=0100079f(10) DS(01000193), FNV1a:0e769314, DF=010007b3(09) DS(01000193), FNV1c:1310d1a2, DF=07000297(09) DS(01000193), F___RC=b2fb099b, DF:6a068d9f(16) , F1__RC=5c301f01, DF:c726cd4d(17) , F1A_RC=94cf402e, DF:55b04ee5(16) , F1C_RC=aea1a025, DF:0b1f2e5d(17) F(00,04)::VEC(0, 4, ffffffff, 0):: FNV :00000004, DF=00000007(03) DS(00000001), FNV1 :0400064c, DF=070002f5(10) DS(01000193), FNV1a:0d769181, DF=03000295(07) DS(01000193), FNV1c:0e10c9c3, DF=1d001861(09) DS(050007df), F___RC=8cf88f32, DF:3e0386a9(14) , F1__RC=1d496bb6, DF:417974b7(17) , F1A_RC=89401d59, DF:1d8f5d77(20) , F1C_RC=e4e96c7c, DF:4a48cc59(13) F(00,05)::VEC(0, 5, ffffffff, 0):: FNV :00000005, DF=00000001(01) DS(00000001), FNV1 :050007df, DF=01000193(06) DS(01000193), FNV1a:0c768fee, DF=01001e6f(11) DS(01000193), FNV1c:0d10c830, DF=030001f3(09) DS(01000193), F___RC=66f614c9, DF:ea0e9bfb(20) , F1__RC=de62b86b, DF:c32bd3dd(19) , F1A_RC=346e222c, DF:bd2e3f75(21) , F1C_RC=502e5f82, DF:b4c733fe(20) F(00,06)::VEC(0, 6, ffffffff, 0):: FNV :00000006, DF=00000003(02) DS(00000001), FNV1 :06000972, DF=03000ead(10) DS(01000193), FNV1a:0b768e5b, DF=070001b5(09) DS(01000193), FNV1c:1010cce9, DF=1d0004d9(10) DS(030004b9), F___RC=40f39a60, DF:26058ea9(13) , F1__RC=9f7c0520, DF:411ebd4b(16) , F1A_RC=b376a527, DF:8718870b(13) , F1C_RC=1241a9a4, DF:426ff626(17) F(00,07)::VEC(0, 7, ffffffff, 0):: FNV :00000007, DF=00000001(01) DS(00000001), FNV1 :07000b05, DF=01000277(08) DS(01000193), FNV1a:0a768cc8, DF=01000293(06) DS(01000193), FNV1c:0f10cb56, DF=1f0007bf(15) DS(01000193), F___RC=1af11ff7, DF:5a028597(13) , F1__RC=609551d5, DF:ffe954f5(22) , F1A_RC=14293bea, DF:a75f9ecd(21) , F1C_RC=49d34bba, DF:5b92e21e(16) F(00,08)::VEC(0, 8, ffffffff, 0):: FNV :00000008, DF=0000000f(04) DS(00000001), FNV1 :08000c98, DF=0f00079d(12) DS(01000193), FNV1a:09768b35, DF=030007fd(12) DS(01000193), FNV1c:1a10dca7, DF=150017f1(12) DS(0b001151), F___RC=f4eea58e, DF:ee1fba79(21) , F1__RC=21ae9e8a, DF:413bcf5f(19) , F1A_RC=eeebb7a5, DF:fac28c4f(17) , F1C_RC=7da04f47, DF:347304fd(16) F(00,09)::VEC(0, 9, ffffffff, 0):: FNV :00000009, DF=00000001(01) DS(00000001), FNV1 :09000e2b, DF=010002b3(07) DS(01000193), FNV1a:087689a2, DF=01000297(07) DS(01000193), FNV1c:1910db14, DF=030007b3(10) DS(01000193), F___RC=ceec2b25, DF:3a028eab(14) , F1__RC=e2c7eb3f, DF:c36975b5(18) , F1A_RC=54e1aef8, DF:ba0a195d(15) , F1C_RC=d425e1af, DF:a985aee8(16) F(00,0a)::VEC(0, a, ffffffff, 0):: FNV :0000000a, DF=00000003(02) DS(00000001), FNV1 :0a000fbe, DF=03000195(07) DS(01000193), FNV1a:0776880f, DF=0f0001ad(10) DS(01000193), FNV1c:1c10dfcd, DF=050004d9(08) DS(030004b9), F___RC=a8e9b0bc, DF:66059b99(15) , F1__RC=a3e137f4, DF:4126dccb(15) , F1A_RC=213fcd63, DF:75de639b(20) , F1C_RC=7e1d2751, DF:aa38c6fe(18) F(00,0b)::VEC(0, b, ffffffff, 0):: FNV :0000000b, DF=00000001(01) DS(00000001), FNV1 :0b001151, DF=01001eef(12) DS(01000193), FNV1a:0676867c, DF=01000e73(09) DS(01000193), FNV1c:1b10de3a, DF=070001f7(11) DS(01000193), F___RC=82e73653, DF:2a0e86ef(16) , F1__RC=64fa84a9, DF:c71bb35d(19) , F1A_RC=5598ce46, DF:74a70325(14) , F1C_RC=6400c630, DF:1a1de161(14) F(00,0c)::VEC(0, c, ffffffff, 0):: FNV :0000000c, DF=00000007(03) DS(00000001), FNV1 :0c0012e4, DF=070003b5(10) DS(01000193), FNV1a:057684e9, DF=03000295(07) DS(01000193), FNV1c:1610d65b, DF=0d000861(07) DS(050007df), F___RC=5ce4bbea, DF:de038db9(17) , F1__RC=2613d15e, DF:42e955f7(18) , F1A_RC=6a220ff1, DF:3fbac1b7(20) , F1C_RC=6e781da4, DF:0a78db94(15) F(00,0d)::VEC(0, d, ffffffff, 0):: FNV :0000000d, DF=00000001(01) DS(00000001), FNV1 :0d001477, DF=01000693(07) DS(01000193), FNV1a:04768356, DF=010007bf(11) DS(01000193), FNV1c:1510d4c8, DF=03000293(07) DS(01000193), F___RC=36e24181, DF:6a06fa6b(17) , F1__RC=e72d1e13, DF:c13ecf4d(18) , F1A_RC=168d4944, DF:7caf46b5(19) , F1C_RC=65bbcfa1, DF:0bc3d205(13) F(00,0e)::VEC(0, e, ffffffff, 0):: FNV :0000000e, DF=00000003(02) DS(00000001), FNV1 :0e00160a, DF=0300027d(09) DS(01000193), FNV1a:037681c3, DF=07000295(08) DS(01000193), FNV1c:1810d981, DF=0d000d49(09) DS(030004b9), F___RC=10dfc718, DF:263d8699(15) , F1__RC=a8466ac8, DF:4f6b74db(20) , F1A_RC=93e667bf, DF:856b2efb(19) , F1C_RC=76f80ee3, DF:1343c142(11) F(00,0f)::VEC(0, f, ffffffff, 0):: FNV :0000000f, DF=00000001(01) DS(00000001), FNV1 :0f00179d, DF=01000197(07) DS(01000193), FNV1a:02768030, DF=010001f3(08) DS(01000193), FNV1c:1710d7ee, DF=0f000e6f(13) DS(01000193), F___RC=eadd4caf, DF:fa028bb7(17) , F1__RC=695fb77d, DF:c119ddb5(17) , F1A_RC=0f485682, DF:9cae313d(17) , F1C_RC=3667e8dc, DF:409fe63f(18) F(00,10)::VEC(0, 10, ffffffff, 0):: FNV :00000010, DF=0000001f(05) DS(00000001), FNV1 :10001930, DF=1f000ead(13) DS(01000193), FNV1a:01767e9d, DF=0300fead(14) DS(01000193), FNV1c:0210b6df, DF=15006131(09) DS(1500210f), F___RC=c4dad246, DF:2e079ee9(17) , F1__RC=2a790432, DF:4326b34f(16) , F1A_RC=d10adebd, DF:de42883f(16) , F1C_RC=1ce48e12, DF:2a8366ce(15) ``` `F(00,01)` : is input x,y `VEC(0, 1, ffffffff, 0)` : is `fnv_reduce` input vector (a,b,c,d) `FNV :00000001, DF=00000001(01) DS(00000001)` : * `FNV(00,01)` result is 00000001 , * `DF` : is changed bitcounts, compared with previous outputs, in this case prev[00,00] current[00,01] input is 1bit changed, and output result 1bit changed. * `DS` : is distances of previous result and current result , ABS(prev_fnvresult,current_fnvresult). ** Basically, `DF` is higher is best on hash algorithm. `F___RC=fefffe6d, DF:111e47a9(14)` : `fnv_reduce = fnv(fnv(fnv(a,b),c),d) ` result is fefffe6d , and Different Bits counts are `14` bits. ## Rationale In case of ethash algorithm, it can't prevent ASIC forever. And, current ethash algorithm's FNV function is deprecated. So, It needs to be upgraded and it will make current ethash based ASICs obsolete. And current TETHASHV1 FNV1A implementation is based on most of ethash , which is verified for a long time. Another propose of big differencing the Ethash algorithm need to crypto analysis for a long times and need to GPU code optimization times. **Verification and Optimization timeline Examples** original ethminer (2015) -> claymore optimized miner (2016) [1year] genoil ethminer (2015) -> ethereum-mining/ethminer (2017) [2year] ## Test Results:: Tethash miner has 2~3% of hashrate degrade on GPU, due to more core computation time. ## Copyright This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/). Thu, 01 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1485 https://eips.ethereum.org/EIPS/eip-1485 Human Cost Accounting Standard (Like Gas but for humans) Standards Track/ERC https://github.com/freeworkculture/kazini/issues/11 ## Simple Summary A standard interface for Human Capital Accounting tokens. ## Abstract The following standard allows for the implementation of a standard API for HUCAP tokens within smart contracts. This standard provides basic functionality to discover, track and transfer the motivational hierarchy of human resources. While blockchain architecture has succeeded in the financialisation of integrity by way of transparency; correspondingly real world outcomes will be proportional to the degree of individualisation of capital by way of knowledge. ## Motivation The Ethereum protocol architecture has a deterministic world-view bounded to the random reality of the human domain that supplies the intentions and logic. The yellow paper formally defines the EVM as a state machine with only deterministic parameters and state transition operators. Oracle requests to another on-chain contract, and/or off-chain HTTP lookups still make for multiple deterministic transactions. A standard interface that allows the appraisal of individual capabilities concurrently with output and the overall knowledge-base will reduce market search costs and increase the autonomous insertion of mindful innovation into the blockchain ecosystem. We provide for simple smart contracts to define and track an arbitrarily large number of HUCAP assets. Additional applications are discussed below. The Belief-Desire-Intention model is a plan-theoretic framework for establishing means-end coherence in agent based modelling system. The blockchain's cryptographic security architecture reliably scales to a blockchain based PKI web-of-trust hierarchies. ERC-20 token standard allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges. ERC-721 token standard allows wallet/broker/auction applications to work with any NFT on Ethereum. ERC-1155 Crypto Item standard allows a smart contract interface where one can represent any number of ERC-20 and ERC-721 assets in a single contract. This standard is inspired by the belief–desire–intention (BDI) model of human practical reasoning developed by Michael Bratman as a way of explaining future-directed intention. A BDI agent is a particular type of bounded rational software agent, imbued with particular mental attitudes, viz: Beliefs, Desires and Intentions (BDI). The model identifies commitment as the distinguishing factor between desire and intention, and a noteworthy property that leads to (1) temporal persistence in plans and in the sense of explicit reference to time, (2) further plans being made on the basis of those to which it is already committed, (3) hierarchical nature of plans, since the overarching plan remains in effect while subsidiary plans are being executed. The BDI software model is an attempt to solve a problem of plans and planning choice and the execution thereof. The complement of which tenders a sufficient metric for indicating means-end coherence and ascribing cost baselines to such outcomes. ## Specification #### Main Interface ```solidity pragma solidity ^0.4.25; pragma experimental ABIEncoderV2; /** @title ERC-**** Human Capital Accounting Standard @dev See https://github.com/freeworkculture/kazini/issues/11 Note: the ERC-165 identifier for this interface is 0xf23a6e61. */ interface IERC_HUCAP { /** @notice Compute the index value of an Agents BDI in the ecosystem. @param _address Set the stance of an agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function updateIndex() internal returns (bool); /** @notice Get the active/inactive and states of an Agent in the ecosystem. @param _address Set the stance of an agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function iam() view public returns (bool iam_, IERC_HUCAP_TYPES.IS state_); /** @notice Fetch the bdi index value of an Agent in the ecosystem. @param _address Set the stance of an agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function index() view public returns (uint8 index_); /** @notice Count of Public Keys in key ring of an Agent in the ecosystem. @param _address Set the stance of an agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function ringLength() view public returns (uint ringlength_); /** @notice Get the PGP Public Key Id of an Agent in the ecosystem. @param "" Set the stance of an agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function keyId() view public returns (bytes32 KEYID_); /** @notice Get the merit data of an Agent in the ecosystem. @param "" Set the stance of an agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function merits() view public returns ( uint experience_, bytes32 reputation_, bytes32 talent_, uint8 index_, bytes32 hash_); /** @notice Get the accreditation of an Agent in the ecosystem. @param "" Set the stance of an agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function kbase() view public returns (IERC_HUCAP_TYPES.KBase kbase_); /** @notice Get the desire of an Agent in the ecosystem. @param _desire Pro-attitude @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function desire(bytes1 _desire) view external returns (bytes32); /** @notice Get the intention of an Agent in the ecosystem. @param _intention Conduct-controlling pro-attitude @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function intention(bool _intention) view external returns (bytes32); /** @notice Cycle the intention of an Agent in the ecosystem. @param _intention Conduct-controlling pro-attitude @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function flipIntention() external returns (bool); /** @notice Get the user data of an Agent in the ecosystem. @param "" Conduct-controlling pro-attitude @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function getDoer() view external returns ( bytes32 fPrint, bool iam_, bytes32 email, bytes32 fName, bytes32 lName, uint age, bytes32 data_); /** @notice Get the belief data of an Agent in the ecosystem. @param _kbase Source address @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function getBelief(IERC_HUCAP_TYPES.KBase _kbase) view external returns ( bytes32 country_, bytes32 cAuthority_, bytes32 score_); /** @notice Get the desire data of an Agent in the ecosystem. @param _desire Pro-attitides @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function getDesire(bytes1 _desire) view external returns (bytes32,bool); /** @notice Get the intention of an Agent in the ecosystem. @param _intention Conduct-controlling pro-attitude @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function getIntention(bool _intention) view external returns (IERC_HUCAP_TYPES.IS,bytes32,uint256); /** @notice Sign the Public Key of an Agent in the ecosystem. @param _address Address of key to sign, must belong to an Agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function sign(address _address) public onlyOwner returns (uint, bool signed); /** @notice Sign the Public Key of an Agent in the ecosystem. @param "" internal helper function to add key in keyring @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function sign() external onlyDoer returns (uint, bool signed); /** @notice Revoke the Public Key of an Agent in the ecosystem. @param _address Address of key to revoke, must belong to an Agent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function revoke(address _address) external onlyDoer returns (uint, bool revoked); /** @notice Revoke the Public Key of an Agent in the ecosystem. @param "" internal helper function to remove key from keyring @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function revoke() external onlyDoer returns (uint, bool revoked); /** @notice Set the trust level for a Public Key of an Agent in the ecosystem. @param _level Degree of trust @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function trust(Trust _level) returns (bool); /** @notice Increment the number of keys in the keyring of an Agent in the ecosystem. @param _keyd Target key @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function incSigns(bytes32 _keyd) external ProxyKey returns (uint); /** @notice Decrement the number of keys in the keyring of an Agent in the ecosystem. @param _keyd Target key @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function decSigns(bytes32 _keyd) external ProxyKey returns (uint); /** @notice Set the knowledge credentials of an Agent in the ecosystem. @param _kbase Level of accreditation @param _country Source country @param _cAuthority Accreditation authority @param _score Accreditation @param _year Year of Accreditation @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function setbdi( KBase _kbase, bytes32 _country, bytes32 _cAuthority, bytes32 _score, uint _year ) external ProxyBDI returns (bool qualification_); /** @notice Set the SNA metrics of an Agent in the ecosystem @param _refMSD Minimum shortest distance @param _refRank Rank of target key @param _refSigned No of keys signed I have signed @param _refSigs No. of keys that have signed my key @param _refTrust Degree of tructThrows on any error rather than return a false flag to minimize user errors @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function setbdi( uint _refMSD, uint _refRank, uint _refSigned, uint _refSigs, bytes32 _refTrust ) external ProxyBDI returns (bool reputation_); /** @notice Set the talents of an Agent in the ecosystem @param _talent Agent's talent @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function setbdi(bytes32 _talent) external ProxyBDI returns (bool talent_); /** @notice Set the desires of an Agent in the ecosystem @param _desire Pro-attitude @param _goal A goal is an instatiated pro-attitude @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function setbdi(bytes1 _desire, Desire _goal) public onlyDoer returns (bool); /** @notice Set the intention of an Agent in the ecosystem @param _service Conducting-controlling pro-attitude @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function setbdi(Intention _service) public onlyDoer returns (bool); /** @notice Set the targeted intention of an Agent in the ecosystem. @param _intention Conduct-controlling pro-attitude @param _state Agent stance @dev For the purpose of Throws on any error rather than return a false flag to minimize user errors */ function intention(bool _intention, IERC_HUCAP_TYPES.IS _state) external returns (IERC_HUCAP_TYPES.IS); /* End of interface IERC_HUCAP */ } ``` #### User Defined Types Extension Interface ```solidity interface IERC_HUCAP_TYPES { /* Enums*/ // Weights 1, 2, 4, 8, 16, 32, 64, 128 256 enum KBase {PRIMARY,SECONDARY,TERTIARY,CERTIFICATION,DIPLOMA,LICENSE,BACHELOR,MASTER,DOCTORATE} enum IS { CLOSED, CREATOR, CURATOR, ACTIVE, INACTIVE, RESERVED, PROVER } /* Structus */ struct Clearance { bytes32 Zero; bytes32 Unknown; bytes32 Generic; bytes32 Poor; bytes32 Casual; bytes32 Partial; bytes32 Complete; bytes32 Ultimate; } /* End of interface IERC_HUCAP_TYPES */ } ``` #### Web-of-trust Extension Interface ```solidity pragma solidity ^0.4.25; pragma experimental ABIEncoderV2; interface IERC_HUCAP_KEYSIGNING_EXTENSION { bytes32 constant public _InterfaceId_ERC165_ = "CREATOR 0.0118 XOR OF ALL FUNCTIONS IN THE INTERFACE"; // Complies to ERC165 // KEY MASKING TABLE // bytes32 constant public MASK = 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff; // bytes32 constant public KEYID = 0xffffffffffffffffffffffffffffffffff90EBAC34FC40EAC30FC9CB464A2E56; // EXAMPLE PGP PUBLIC KEY ID // bytes32 constant public KEY_CERTIFICATION = 0x01ffffffffffffff << 192; // “C” Key Certification // bytes32 constant public SIGN_DATA = 0x02ffffffffffffff << 192; // “S” Sign Data // bytes32 constant public ENCRYPT_COMMUNICATIONS = 0x04ffffffffffffff << 192; // “E” Encrypt Communications // Clearance constant public Trust = 0x03ff << 192; // Trust: Unknown // BYTES32 Value with // Public Key Id, masking // Key Certification masking // Split Key masking // Generic masking // Ordinary masking // Trust.Unknown masking // bytes32 constant public DOER = 0x11ff10ff100f03ffff00ffffffffffffffff90EBAC34FC40EAC30FC9CB464A2E56; bytes32 constant public KEY_CERTIFICATION = 0x01ffffffffffffff << 192; // “C” Key Certification bytes32 constant public SIGN_DATA = 0x02ffffffffffffff << 192; // “S” Sign Data bytes32 constant public ENCRYPT_COMMUNICATIONS = 0x04ffffffffffffff << 192; // “E” Encrypt Communications bytes32 constant public ENCRYPT_STORAGE = 0x08ffffffffffffff << 192; // “E” Encrypt Storage bytes32 constant public SPLIT_KEY = 0x10ffffffffffffff << 192; // Split key bytes32 constant public AUTHENTICATION = 0x20ffffffffffffff << 192; // “A” Authentication bytes32 constant public MULTI_SIGNATURE = 0x80ffffffffffffff << 192; // Held by more than one person bytes32 constant public TRUST_AMOUNT = 0xffffffffffff00ff << 192; bytes32 constant public BINARY_DOCUMENT = 0xffff00ffffffffff << 192; // 0x00: Signature of a binary document. bytes32 constant public CANONICAL_DOCUMENT = 0xffff01ffffffffff << 192; // 0x01: Signature of a canonical text document. bytes32 constant public STANDALONE_SIGNATURE = 0xffff02ffffffffff << 192; // 0x02: Standalone signature. bytes32 constant public GENERIC = 0xffff10ffffffffff << 192; // 0x10: Generic certification of a User ID and Public-Key packet. bytes32 constant public PERSONA = 0xffff11ffffffffff << 192; // 0x11: Persona certification of a User ID and Public-Key packet. bytes32 constant public CASUAL = 0xffff12ffffffffff << 192; // 0x12: Casual certification of a User ID and Public-Key packet. bytes32 constant public POSITIVE = 0xffff13ffffffffff << 192; // 0x13: Positive certification of a User ID and Public-Key packet. bytes32 constant public SUBKEY_BINDING = 0xffff18ffffffffff << 192; // 0x18: Subkey Binding Signature bytes32 constant public PRIMARY_KEY_BINDING = 0xffff19ffffffffff << 192; // 0x19: Primary Key Binding Signature bytes32 constant public DIRECTLY_ON_KEY = 0xffff1Fffffffffff << 192; // 0x1F: Signature directly on a key bytes32 constant public KEY_REVOCATION = 0xffff20ffffffffff << 192; // 0x20: Key revocation signature bytes32 constant public SUBKEY_REVOCATION = 0xffff28ffffffffff << 192; // 0x28: Subkey revocation signature bytes32 constant public CERTIFICATION_REVOCATION = 0xffff30ffffffffff << 192; // 0x30: Certification revocation signature bytes32 constant public TIMESTAMP = 0xffff40ffffffffff << 192; // 0x40: Timestamp signature. bytes32 constant public THIRD_PARTY_CONFIRMATION = 0xffff50ffffffffff << 192; // 0x50: Third-Party Confirmation signature. bytes32 constant public ORDINARY = 0xffffffff100fffff << 192; bytes32 constant public INTRODUCER = 0xffffffff010fffff << 192; bytes32 constant public ISSUER = 0xffffffff001fffff << 192; // EDGES MASKING TABLE Clearance internal TRUST = Clearance({ Zero: 0x01ff << 192, Unknown: 0x03ff << 192, Generic: 0x07ff << 192, Poor: 0xF0ff << 192, Casual: 0xF1ff << 192, Partial: 0xF3ff << 192, Complete: 0xF7ff << 192, Ultimate: 0xFFff << 192 }); /** /// @notice Cycle through state transition of an Agent in the ecosystem. /// @param _address toggle on/off a doer agent // @dev `anybody` can retrieve the talent data in the contract */ function flipTo(address _address) external onlyOwner returns (IS); /** /// @notice Turn Agent in the ecosystem to on/off. /// @param _address toggle on/off a doer agent // @dev `anybody` can retrieve the talent data in the contract */ function toggle(address _address) external onlyOwner returns (bool); /** /// @notice Set the trust level of an Agent in the ecosystem. /// @param _level toggle on/off a doer agent // @dev `anybody` can retrieve the talent data in the contract */ function trust(Trust _level) returns (bytes32 Trust); event LogCall(address indexed from, address indexed to, address indexed origin, bytes _data); /* End of interface IERC_HUCAP_KEYSIGNING_EXTENSION */ } ``` #### Human Capital Accounting Extension Interface ```solidity pragma solidity ^0.4.25; pragma experimental ABIEncoderV2; interface IERC_HUCAP_TRACKUSERS_EXTENSION { /// @notice Instantiate an Agent in the ecosystem with default data. /// @param _address initialise a doer agent // @dev `anybody` can retrieve the talent data in the contract function initAgent(Doers _address) external onlyControlled returns (bool); /// @notice Get the data by uuid of an Agent in the ecosystem. /// @param _uuid Get the address of a unique uid // @dev `anybody` can retrieve the talent data in the contract function getAgent(bytes32 _uuid) view external returns (address); /// @notice Get the data of all Talents in the ecosystem. /// @param _address Query if address belongs to an agent // @dev `anybody` can retrieve the talent data in the contract function iam(address _address) view public returns (bool); /// @notice Get the data of all Talents in the ecosystem. /// @param _address Query if address belongs to a doer // @dev `anybody` can retrieve the talent data in the contract function isDoer(address _address) view public returns (IS); /// @notice Get the number of doers that can be spawned by a Creators. /// The query condition of the contract // @dev `anybody` can retrieve the count data in the contract function getAgent(address _address) view public returns (bytes32 keyid_, IS state_, bool active_, uint myDoers_); /// @notice Get the data of all Talents in the ecosystem. /// @param _talent The talent whose frequency is being queried // @dev `anybody` can retrieve the talent data in the contract function getTalents(bytes32 _talent) view external returns (uint talentK_, uint talentI_, uint talentR_, uint talentF_); /// @notice Increment a kind of talent in the ecosystem. /// @param The talent whose frequency is being queried // @dev `anybody` can retrieve the talent data in the contract function incTalent() payable public onlyDoer returns (bool); /// @notice Decrement a kind of talent in the ecosystem.. /// @param The talent whose frequency is being queried // @dev `anybody` can retrieve the talent data in the contract function decTalent() payable public onlyDoer returns (bool); /// @notice Set the Public-Key Id of an Agent in the ecosystem. /// @param _address Set the Public-key Id of an agent // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, bytes32 _keyId) external onlyControlled returns (bytes32); /// @notice Transition the states of an Agent in the ecosystem. /// @param _address Set the stance of an agent // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, IS _state) external onlyControlled returns (IS); /// @notice Set the active status of an Agent in the ecosystem. /// @param _address Toggle the true/false status of an agent // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, bool _active) external onlyControlled returns (bool); /// @notice Set the data of all Intentions of Agents in the ecosystem. /// @param _serviceId Track number of offers available // @dev `anybody` can retrieve the talent data in the contract function setAllPromises(bytes32 _serviceId) external onlyControlled; /* End of interface IERC_HUCAP_TRACKUSERS_EXTENSION */ } ``` ## Rationale [WIP] ## Backwards Compatibility [WIP] ## Test Cases [WIP] ## Implementation [WIP] ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 12 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1491 https://eips.ethereum.org/EIPS/eip-1491 Upgradable Smart Contract Standards Track/ERC https://github.com/ethereum/EIPs/issues/1503 ## Simple Summary A standard interface/guideline that makes a smart contract upgradable. ## Abstract Ethereum smart contracts have suffered a number of security issues in the past few years. The cost of fixing such a bug in smart contract is significant; for example, the consequences of The DAO attack in June 2016 caused tremendous financial loss and the hard fork of Ethereum blockchain. The following standard makes it possible to upgrade a standard API within smart contracts. This standard provides basic functionalities to upgrade the operations of the contract without data migration. To ensure the decentralization/community interests, it also contains a voting mechanism to control the upgrading process. ## Motivation Smart contract is immutable after deployment. If any security risk is identified or program bug is detected, developers always have to destruct the old contract, deploy a new one and potentially migrate the data (hard fork) to the new contract. In some cases, deploying a smart contract with bugs and potential security vulnerabilities can cause a significant amount of financial loss. We propose this upgradable contract to fix the current situation. With the upgradable contract, developers can deploy a new version of smart contract after previous deployment and retain the data at the same time. For example, after an ERC20-compliant token contract is deployed, the users exploit a vulnerability in the source code. Without the support of upgradable contract, developers have to fix this issue by deploy a new, secured contract otherwise the attackers would take advantage of the security hole, which may cause a tremendous financial loss. A challenge is how to migrate data from the old contract to a new one. With the upgradable contract below, this will become relatively easy as developers only have to upgrade the Handler contract to fix bugs while the Data contract will remain the same. ## Specification The upgradable contract consists of three parts: - **Handler contract** (implements **Handler interface**) defines operations and provides services. This contract can be upgraded; - **Data contract** keeps the resources (data) and is controlled by the Handler contract; - **Upgrader contract (optional)** deals with the voting mechanism and upgrades the Handler contract. The voters are pre-defined by the contract owner. > The following codes are exact copies of the [ERC-1504 Upgradable Smart Contract.](https://gist.github.com/swordghost/77c96a972106af6ec6ccea9c2d66e768) ### Handler contract and Handler interface Functions of the Handler contract vary with requirements, so developers would better design interfaces for Handler contracts to limit them and make sure external applications are always supported. Below is the specification of Handler interface. In the Handler interface we define the following actions: - Initialize the Data contract; - Register the Upgrader contract address; - Destruct the Handler contract after upgrading is done; - Verify the current Handler is the working one → it should always return true. Developers have to define their business-related functions as well. ```solidity /// Handler interface. /// Handler defines business related functions. /// Use the interface to ensure that your external services are always supported. /// Because of function live(), we design IHandler as an abstract contract rather than a true interface. contract IHandler { /// Initialize the data contarct. /// @param _str value of exmStr of Data contract. /// @param _int value of exmInt of Data contract. /// @param _array value of exmArray of Data contract. function initialize (string _str, uint256 _int, uint16 [] _array) public; /// Register Upgrader contract address. /// @param _upgraderAddr address of the Upgrader contract. function registerUpgrader (address _upgraderAddr) external; /// Upgrader contract calls this to check if it is registered. /// @return if the Upgrader contract is registered. function isUpgraderRegistered () external view returns(bool); /// Handler has been upgraded so the original one has to self-destruct. function done() external; /// Check if the Handler contract is a working Handler contract. /// It is used to prove the contract is a Handler contract. /// @return always true. function live() external pure returns(bool) { return true; } /** Functions - define functions here */ /** Events - add events here */ } ``` The process of deploying a Handler contract: 1. Deploy Data contract; 2. Deploy a Handler contract at a given address specified in the Data contract; 3. Register the Handler contract address by calling setHandler() in the Data contract, or use an Upgrader contract to switch the Handler contract, which requires that Data contract is initialized; 4. Initialize Data contract if haven’t done it already. ### Data Contract Below is the specification of Data contract. There are three parts in the Data contract: - **Administrator Data**: owner’s address, Handler contract’s address and a boolean indicating whether the contract is initialized or not; - **Upgrader Data**: Upgrader contract’s address, upgrade proposal’s submission timestamp and proposal’s time period; - **Resource Data**: all other resources that the contract needs to keep and manage. ```solidity /// Data Contract contract DataContract { /** Management data */ /// Owner and Handler contract address private owner; address private handlerAddr; /// Ready? bool private valid; /** Upgrader data */ address private upgraderAddr; uint256 private proposalBlockNumber; uint256 private proposalPeriod; /// Upgrading status of the Handler contract enum UpgradingStatus { /// Can be upgraded Done, /// In upgrading InProgress, /// Another proposal is in progress Blocked, /// Expired Expired, /// Original Handler contract error Error } /** Data resources - define variables here */ /** Modifiers */ /// Check if msg.sender is the Handler contract. It is used for setters. /// If fail, throw PermissionException. modifier onlyHandler; /// Check if msg.sender is not permitted to call getters. It is used for getters (if necessary). /// If fail, throw GetterPermissionException. modifier allowedAddress; /// Check if the contract is working. /// It is used for all functions providing services after initialization. /// If fail, throw UninitializationException. modifier ready; /** Management functions */ /// Initializer. Just the Handler contract can call it. /// @param _str default value of this.exmStr. /// @param _int default value of this.exmInt. /// @param _array default value of this.exmArray. /// exception PermissionException msg.sender is not the Handler contract. /// exception ReInitializationException contract has been initialized. /// @return if the initialization succeeds. function initialize (string _str, uint256 _int, uint16 [] _array) external onlyHandler returns(bool); /// Set Handler contract for the contract. Owner must set one to initialize the Data contract. /// Handler can be set by owner or Upgrader contract. /// @param _handlerAddr address of a deployed Handler contract. /// @param _originalHandlerAddr address of the original Handler contract, only used when an Upgrader contract want to set the Handler contract. /// exception PermissionException msg.sender is not the owner nor a registered Upgrader contract. /// exception UpgraderException Upgrader contract does not provide a right address of the original Handler contract. /// @return if Handler contract is successfully set. function setHandler (address _handlerAddr, address _originalHandlerAddr) external returns(bool); /** Upgrader contract functions */ /// Register an Upgrader contract in the contract. /// If a proposal has not been accepted until proposalBlockNumber + proposalPeriod, it can be replaced by a new one. /// @param _upgraderAddr address of a deployed Upgrader contract. /// exception PermissionException msg.sender is not the owner. /// exception UpgraderConflictException Another Upgrader contract is working. /// @return if Upgrader contract is successfully registered. function startUpgrading (address _upgraderAddr) public returns(bool); /// Getter of proposalPeriod. /// exception UninitializationException uninitialized contract. /// exception GetterPermissionException msg.sender is not permitted to call the getter. /// @return this.proposalPeriod. function getProposalPeriod () public view isReady allowedAddress returns(uint256); /// Setter of proposalPeriod. /// @param _proposalPeriod new value of this.proposalPeriod. /// exception UninitializationException uninitialized contract. /// exception PermissionException msg.sender is not the owner. /// @return if this.proposalPeriod is successfully set. function setProposalPeriod (uint256 _proposalPeriod) public isReady returns(bool); /// Return upgrading status for Upgrader contracts. /// @param _originalHandlerAddr address of the original Handler contract. /// exception UninitializationException uninitialized contract. /// @return Handler contract's upgrading status. function canBeUpgraded (address _originalHandlerAddr) external view isReady returns(UpgradingStatus); /// Check if the contract has been initialized. /// @return if the contract has been initialized. function live () external view returns(bool); /** Getters and setters of data resources: define functions here */ } ``` ### Upgrader Contract (Optional) Handler contract can be upgraded by calling setHandler() of Data contract. If the owner wants to collect ideas from users, an Upgrader contract will help him/her manage voting and upgrading. Below is the specification of Upgrader contract: - The Upgrader contract has the ability to take votes from the registered voters. - The contract owner is able to add voters any time before the proposal expires; - Voter can check the current status of the proposal (succeed or expired). - Developers are able to delete this Upgrader contract by calling done() any time after deployment. The Upgrader contract works as follows: 1. Verify the Data contract, its corresponding Handler contract and the new Handler contract have all been deployed; 2. Deploy an Upgrader contract using Data contract address, previous Handler contract address and new Handler contract address; 3. Register upgrader address in the new Handler contract first, then the original handler and finally the Data contract; 4. Call startProposal() to start the voting process; 5. Call getResolution() before the expiration; 6. Upgrading succeed or proposal is expired. Note: - Function done() can be called at any time to let upgrader destruct itself. - Function status() can be called at any time to show caller status of the upgrader. ```solidity /// Handler upgrader contract Upgrader { // Data contract DataContract public data; // Original Handler contract IHandler public originalHandler; // New Handler contract address public newHandlerAddr; /** Marker */ enum UpgraderStatus { Preparing, Voting, Success, Expired, End } UpgraderStatus public status; /// Check if the proposal is expired. /// If so, contract would be marked as expired. /// exception PreparingUpgraderException proposal has not been started. /// exception ReupgradingException upgrading has been done. /// exception ExpirationException proposal is expired. modifier notExpired { require(status != UpgraderStatus.Preparing, "Invalid proposal!"); require(status != UpgraderStatus.Success, "Upgrading has been done!"); require(status != UpgraderStatus.Expired, "Proposal is expired!"); if (data.canBeUpgraded(address(originalHandler)) != DataContract.UpgradingStatus.InProgress) { status = UpgraderStatus.Expired; require(false, "Proposal is expired!"); } _; } /// Start voting. /// Upgrader must do upgrading check, namely checking if Data contract and 2 Handler contracts are ok. /// exception RestartingException proposal has been already started. /// exception PermissionException msg.sender is not the owner. /// exception UpgraderConflictException another upgrader is working. /// exception NoPreparationException original or new Handler contract is not prepared. function startProposal () external; /// Anyone can try to get resolution. /// If voters get consensus, upgrade the Handler contract. /// If expired, self-destruct. /// Otherwise, do nothing. /// exception PreparingUpgraderException proposal has not been started. /// exception ExpirationException proposal is expired. /// @return status of proposal. function getResolution() external returns(UpgraderStatus); /// Destruct itself. /// exception PermissionException msg.sender is not the owner. function done() external; /** Other voting mechanism related variables and functions */ } ``` ### Caveats Since the Upgrader contract in [ERC-1504](/EIPS/eip-1504) has a simple voting mechanism, it is prone to all the limitations that the voting contract is facing: - The administrator can only be the owner of data and Handler contracts. Furthermore, only the administrator has the power to add voters and start a proposal. - It requires voters to be constantly active, informative and attentive to make a upgrader succeed. - The voting will only be valid in a given time period. If in a given time period the contract cannot collect enough “yes” to proceed, the proposal will be marked expired. ## Rationale ### Data Contract and Handler Contract A smart contract is actually a kind of software, which provides some kind of services. From the perspective of software engineering, a service consists of **resources** that abstract the data and **operations** that abstract the process logic on the data. The requirement of upgrading is mostly on the logic part. Therefore, in order to make a smart contract upgradable, we divide it into two parts: 1. Data contract keeps the resources; 2. Handler contract contains operations. The Handler contract can be upgraded in the future while the Data contract is permanent. Handler contract can manipulate the variables in Data contract through the getter and setter functions provided by Data contract. ### Upgrader Contract and Voting Mechanism In order to prevent centralization and protect the interests of the community and stakeholders, we also design a voting mechanism in the Upgrader contract. Upgrader contract contains addresses of Data contract and two Handler contracts, and collects votes from pre-defined voters to upgrade the Handler contract when the pre-set condition is fulfilled. For simplicity, the upgradable contract comes with a very minimal version of the voting mechanism. If the contract owner wants to implement a more complex voting mechanism, he/she can modify the existing voting mechanism to incorporate upgradability. The expiration mechanism (see modifier notExpried in Upgrader contract and related functions in Data contract) and upgrading check (see function startProposal() in Upgrader contract) to the contract are mandatory. ### Gas and Complexity (regarding the enumeration extension) Using an upgrader will cost some gas. If the Handler contract is upgraded by the owner, it just costs gas that a contract call will cost, which is usually significantly lower than creating and deploying a new contract. Although upgrading contract may take some efforts and gas, it is a much less painful than deprecating the insecure contract/creating a new contract or hard fork (e.g. DAO attack). Contract creation requires a significant amount of effort and gas. One of the advantages of upgradable contracts is that the contract owners don’t have to create new contracts; instead, they only need to upgrade parts of contract that cause issues, which is less expensive compared to data loss and blockchain inconsistency. In other words, upgradable contracts make Data contract more scalable and flexible. ### Community Consensus Thank you to those who helped on review and revise the proposal: - [@lsankar4033](https://github.com/lsankar4033) from MIT - more The proposal is initiated and developed by the team Renaissance and the Research Group of Blockchain System @ Center for Operating System at Peking University. We have been very inclusive in this process and invite anyone with questions or contributions into our discussion. However, this standard is written only to support the identified use cases which are listed herein. ## Implementations 1. [Renaissance](https://www.renaissance.app) - a protocol that connect creators and fans financially 2. [ERC-1504](/EIPS/eip-1504) - a reference implementation ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 17 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1504 https://eips.ethereum.org/EIPS/eip-1504 Standard for Insurance Policies as ERC-721 Non Fungible Tokens Standards Track/ERC https://github.com/ethereum/EIPs/issues/1523 ## Simple Summary A standard interface for insurance policies, based on ERC 721. ## Abstract The following standard allows for the implementation of a standard API for insurance policies within smart contracts. Insurance policies are financial assets which are unique in some aspects, as they are connected to a customer, a specific risk, or have other unique properties like premium, period, carrier, underwriter etc. Nevertheless, there are many potential applications where insurance policies can be traded, transferred or otherwise treated as an asset. The ERC 721 standard already provides the standard and technical means to handle policies as a specific class of non fungible tokens. insurance In this proposal, we define a minimum metadata structure with properties which are common to the greatest possible class of policies. ## Motivation For a decentralized insurance protocol, a standard for insurance policies is crucial for interoperability of the involved services and application. It allows policies to be bundled, securitized, traded in a uniform and flexible way by many independent actors like syndicates, brokers, and insurance companies. ## Specification The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. An ERC-1523 compliant insurance policy is a non-fungible token which **MUST adhere to the ERC-721 token standard** and **MUST implement theERC721Metadata and the ERC721Enumerable interface**: ```solidity /// @title ERC-1523 Insurance Policy Standard /// Note: the ERC-165 identifier for this interface is 0x5a04be32 interface ERC1523 /* is ERC721, ERC721Metadata, ERC721Enumerable */ { } ``` The implementor MAY choose values for the ```name``` and ```symbol```. The **policy metadata extension** is **RECOMMENDED** for ERC-1523 smart contracts. This allows your smart contract to be interrogated for policy metadata. ```solidity /// @title ERC-1523 Insurance Policy Standard, optional policy metadata extension /// @dev See ... /// Note: the ERC-165 identifier for this interface is 0x5a04be32 interface ERC1523PolicyMetadata /* is ERC1523 */ { /// @notice Metadata string for a given property. /// Properties are identified via hash of their property path. /// e.g. the property "name" in the ERC721 Metadata JSON Schema has the path /properties/name /// and the property path hash is the keccak256() of this property path. /// this allows for efficient addressing of arbitrary properties, as the set of properties is potentially unlimited. /// @dev Throws if `_propertyPathHash` is not a valid property path hash. function policyMetadata(uint256 _tokenId, bytes32 _propertyPathHash) external view returns (string _property); } ``` In analogy to the “ERC721 Metadata JSON Schema”, the tokenURI **MUST** point to a JSON file with the following properties: ```json { "title": "Asset Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this NFT represents", }, "description": { "type": "string", "description": "Describes the asset to which this NFT represents", }, \[additional parameters according to the following table\] } } ``` ### Additional parameters for the metadata JSON Schema | Parameter | Type | Mandatory | Description | | ------------- | ------------- | ----------| ---------------------------------------------------------------------------------- | | carrier | string | yes | Describes the carrier which takes the primary risk | | risk | string | yes | Describes the risk | | status | string | yes | Describes the status of the policy, e.g. applied for, underwritten, expired | | parameters | string | no | Describes further parameters characterizing the risk | | terms | string | no | Describes legal terms & conditions which apply for this policy | | premium | string | no | A string representation of the premium, **MAY** contain currency denominator | | sum_insured | string | no | A string representation of the sum insured, **MAY** contain currency denominator | Parameters which are mandatory **MUST** be included in the metadata JSON. Other parameters **MAY** be included. However, the proposed optional parameters **SHOULD** be used for the intended purpose, so e.g. if the premium amount would be included in the metadata, the parameter name **SHOULD** be "premium". All parameters **MAY** be plain text or **MAY** also be URIs pointing to resources which contain the respective information, and which **MAY** be protected by an authentication mechanism. ## Rationale Insurance policies form an important class of financial assets, and it is natural to express those assets as a class of non-fungible tokens which adhere to the established ERC-721 standard. We propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy. Standardization is key because we expect decentralized insurance to receive widespread adoption and it is crucial to establish a unified standard to enable composability and the creation of universal toolsets. We therefore propose a standardized naming scheme for the different parameters describing an insurance policy. We propose three mandatory parameters which need to be included in every NFT and further parameters which **MAY** be used, and for which we only standardize the naming conventions. ### Mandatory parameters While policies can have a multitude of possible properties, it is common that policies are issued by some entity, which is basically the entity responsible for paying out claims. Second, an insurance policy is typically related to a specific risk. Some risks are unique, but there are cases where many policies share the same risk (e.g. all flight delay policies for the same flight). In general, the relation of policies to risks is a many-to-one relation with the special case of a one-to-one relation. Third, a policy has a lifecycle of different statuses. Therefore the NFT We believe that those four properties are necessary to describe a policy. For many applications, those properties may be even sufficient. ### Optional parameters Most policies need more parameters to characterize the risk and other features, like premium, period etc. The naming conventions are listed in the above table. However, any implementation **MAY** chose to implement more properties. ### On-chain vs. off-chain metadata For some applications it will be sufficient to store the metadata in an off-chain repository or database which can be addressed by the tokenURI resource locator. For more advanced applications, it can be desirable to have metadata available on-chain. Therefore, we require that the ```tokenURI``` **MUST** point to a JSON with the above structure, while the implementation of the ```policyMetadata``` function is **OPTIONAL**. ## Backwards Compatibility ## Test Cases ## Implementation ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 10 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1523 https://eips.ethereum.org/EIPS/eip-1523 Transparent Contract Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1538 Replaced by [EIP-2535 Diamond Standard](/EIPS/eip-2535). ## Simple Summary This standard provides a contract architecture that makes upgradeable contracts flexible, unlimited in size, and transparent. A transparent contract publicly documents the full history of all changes made to it. All changes to a transparent contract are reported in a standard format. ## Abstract A transparent contract is a proxy contract design pattern that provides the following: 1. A way to add, replace and remove multiple functions of a contract atomically (at the same time). 1. Standard events to show what functions are added, replaced and removed from a contract, and why the changes are made. 2. A standard way to query a contract to discover and retrieve information about all functions exposed by it. 3. Solves the 24KB maximum contract size limitation, making the maximum contract size of a transparent contract practically unlimited. This standard makes the worry about contract size a thing of the past. 4. Enables an upgradeable contract to become immutable in the future if desired. ## Motivation A fundamental benefit of Ethereum contracts is that their code is immutable, thereby acquiring trust by trustlessness. People do not have to trust others if it is not possible for a contract to be changed. However, a fundamental problem with trustless contracts that cannot be changed is that they cannot be changed. #### Bugs Bugs and security vulnerabilities are unwittingly written into immutable contracts that ruin them. #### Improvements Immutable, trustless contracts cannot be improved, resulting in increasingly inferior contracts over time. Contract standards evolve, new ones come out. People, groups and organizations learn over time what people want and what is better and what should be built next. Contracts that cannot be improved not only hold back the authors that create them, but everybody who uses them. #### Upgradeable Contracts vs. Centralized Private Database Why have an upgradeable contract instead of a centralized, private, mutable database? Here are some reasons: 1. Because of the openness of storage data and verified code, it is possible to show a provable history of trustworthiness. 2. Because of the openness, bad behavior can be spotted and reported when it happens. 3. Independent security and domain experts can review the change history of contracts and vouch for their history of trustworthiness. 4. It is possible for an upgradeable contract to become immutable and trustless. 5. An upgradeable contract can have parts of it that are not upgradeable and so are partially immutable and trustless. #### Immutability In some cases immutable, trustless contracts are the right fit. This is the case when a contract is only needed for a short time or it is known ahead of time that there will never be any reason to change or improve it. ### Middle Ground Transparent contracts provide a middle ground between immutable trustless contracts that can't be improved and upgradeable contracts that can't be trusted. ### Purposes 1. Create upgradeable contracts that earn trust by showing a provable history of trustworthiness. 2. Document the development of contracts so their development and change is provably public and can be understood. 3. Create upgradeable contracts that can become immutable in the future if desired. 4. Create contracts that are not limited by a max size. ### Benefits & Use Cases This standard is for use cases that benefit from the following: 1. The ability to add, replace or remove multiple functions of a contract atomically (at the same time). 2. Each time a function is added, replaced or removed, it is documented with events. 3. Build trust over time by showing all changes made to a contract. 4. Unlimited contract size. 5. The ability to query information about functions currently supported by the contract. 6. One contract address that provides all needed functionality and never needs to be replaced by another contract address. 7. The ability for a contract to be upgradeable for a time, and then become immutable. 8. Add trustless guarantees to a contract with "unchangeable functions". ### New Software Possibilities This standard enables a form of contract version control software to be written. Software and user interfaces can be written to filter the `FunctionUpdate` and `CommitMessage` events of a contract address. Such software can show the full history of changes of any contract that implements this standard. User interfaces and software can also use this standard to assist or automate changes of contracts. ## Specification > **Note:** The solidity `delegatecall` opcode enables a contract to execute a function from another contract, but it is executed as if the function was from the calling contract. Essentially `delegatecall` enables a contract to "borrow" another contract's function. Functions executed with `delegatecall` affect the storage variables of the calling contract, not the contract where the functions are defined. ### General Summary A transparent contract delegates or forwards function calls to it to other contracts using `delegatecode`. A transparent contract has an `updateContract` function that enables multiple functions to be added, replaced or removed. An event is emitted for every function that is added, replaced or removed so that all changes to a contract can be tracked in a standard way. A transparent contract is a contract that implements and complies with the design points below. ### Terms 1. In this standard a **delegate contract** is a contract that a transparent contract fallback function forwards function calls to using `delegatecall`. 2. In this standard an **unchangeable function** is a function that is defined directly in a transparent contract and so cannot be replaced or removed. ### Design Points A contract is a transparent contract if it implements the following design points: 1. A transparent contract is a contract that contains a fallback function, a constructor, and zero or more unchangeable functions that are defined directly within it. 2. The constructor of a transparent contract associates the `updateContract` function with a contract that implements the ERC1538 interface. The `updateContract` function can be an "unchangeable function" that is defined directly in the transparent contract or it can be defined in a delegate contract. Other functions can also be associated with contracts in the constructor. 3. After a transparent contract is deployed functions are added, replaced and removed by calling the `updateContract` function. 4. The `updateContract` function associates functions with contracts that implement those functions, and emits the `CommitMessage` and `FunctionUpdate` events that document function changes. 5. The `FunctionUpdate` event is emitted for each function that is added, replaced or removed. The `CommitMessage` event is emitted one time for each time the `updateContract` function is called and is emitted after any `FunctionUpdate` events are emitted. 6. The `updateContract` function can take a list of multiple function signatures in its `_functionSignatures` parameter and so add/replace/remove multiple functions at the same time. 7. When a function is called on a transparent contract it executes immediately if it is an "unchangeable function". Otherwise the fallback function is executed. The fallback function finds the delegate contract associated with the function and executes the function using `delegatecall`. If there is no delegate contract for the function then execution reverts. 8. The source code of a transparent contract and all delegate contracts used by it are publicly viewable and verified. The transparent contract address is the address that users interact with. The transparent contract address never changes. Only delegate addresses can change by using the `updateContracts` function. Typically some kind of authentication is needed for adding/replacing/removing functions from a transparent contract, **however the scheme for authentication or ownership is not part of this standard**. ### Example Here is an example of an implementation of a transparent contract. Please note that the example below is an **example only. It is not the standard**. A contract is a transparent contract when it implements and complies with the design points listed above. ```solidity pragma solidity ^0.5.7; contract ExampleTransparentContract { // owner of the contract address internal contractOwner; event OwnershipTransferred(address indexed previousOwner, address indexed newOwner); // maps functions to the delegate contracts that execute the functions // funcId => delegate contract mapping(bytes4 => address) internal delegates; // maps each function signature to its position in the funcSignatures array. // signature => index+1 mapping(bytes => uint256) internal funcSignatureToIndex; event CommitMessage(string message); event FunctionUpdate(bytes4 indexed functionId, address indexed oldDelegate, address indexed newDelegate, string functionSignature); // this is an example of an "unchangeable function". // return the delegate contract address for the supplied function signature function delegateAddress(string calldata _functionSignature) external view returns(address) { require(funcSignatureToIndex[bytes(_functionSignature)] != 0, "Function signature not found."); return delegates[bytes4(keccak256(bytes(_functionSignature)))]; } // add a function using the updateContract function // this is an internal helper function function addFunction(address _erc1538Delegate, address contractAddress, string memory _functionSignatures, string memory _commitMessage) internal { // 0x03A9BCCF == bytes4(keccak256("updateContract(address,string,string)")) bytes memory funcdata = abi.encodeWithSelector(0x03A9BCCF, contractAddress, _functionSignatures, _commitMessage); bool success; assembly { success := delegatecall(gas, _erc1538Delegate, add(funcdata, 0x20), mload(funcdata), funcdata, 0) } require(success, "Adding a function failed"); } constructor(address _erc1538Delegate) public { contractOwner = msg.sender; emit OwnershipTransferred(address(0), msg.sender); // adding ERC1538 updateContract function bytes memory signature = "updateContract(address,string,string)"; bytes4 funcId = bytes4(keccak256(signature)); delegates[funcId] = _erc1538Delegate; emit FunctionUpdate(funcId, address(0), _erc1538Delegate, string(signature)); emit CommitMessage("Added ERC1538 updateContract function at contract creation"); // associate "unchangeable functions" with this transparent contract address // prevents function selector clashes with delegate contract functions // uses the updateContract function string memory functions = "delegateAddress(string)"; addFunction(_erc1538Delegate, address(this), functions, "Associating unchangeable functions"); // adding ERC1538Query interface functions functions = "functionByIndex(uint256)functionExists(string)delegateAddresses()delegateFunctionSignatures(address)functionById(bytes4)functionBySignature(string)functionSignatures()totalFunctions()"; // "0x01234567891011121314" is an example address of an ERC1538Query delegate contract addFunction(_erc1538Delegate, 0x01234567891011121314, functions, "Adding ERC1538Query functions"); // additional functions could be added at this point } // Making the fallback function payable makes it work for delegate contract functions // that are payable and not payable. function() external payable { // Delegate every function call to a delegate contract address delegate = delegates[msg.sig]; require(delegate != address(0), "Function does not exist."); assembly { let ptr := mload(0x40) calldatacopy(ptr, 0, calldatasize) let result := delegatecall(gas, delegate, ptr, calldatasize, 0, 0) let size := returndatasize returndatacopy(ptr, 0, size) switch result case 0 {revert(ptr, size)} default {return (ptr, size)} } } } ``` As can be seen in the above example, every function call is delegated to a delegate contract, unless the function is defined directly in the transparent contract (making it an unchangeable function). The constructor function adds the `updateContract` function to the transparent contract, which is then used to add other functions to the transparent contract. Each time a function is added to a transparent contract the events `CommitMessage` and `FunctionUpdate` are emitted to document exactly what functions where added or replaced and why. The delegate contract that implements the `updateContract` function implements the following interface: ### ERC1538 Interface ```solidity pragma solidity ^0.5.7; /// @title ERC1538 Transparent Contract Standard /// @dev Required interface /// Note: the ERC-165 identifier for this interface is 0x61455567 interface ERC1538 { /// @dev This emits when one or a set of functions are updated in a transparent contract. /// The message string should give a short description of the change and why /// the change was made. event CommitMessage(string message); /// @dev This emits for each function that is updated in a transparent contract. /// functionId is the bytes4 of the keccak256 of the function signature. /// oldDelegate is the delegate contract address of the old delegate contract if /// the function is being replaced or removed. /// oldDelegate is the zero value address(0) if a function is being added for the /// first time. /// newDelegate is the delegate contract address of the new delegate contract if /// the function is being added for the first time or if the function is being /// replaced. /// newDelegate is the zero value address(0) if the function is being removed. event FunctionUpdate( bytes4 indexed functionId, address indexed oldDelegate, address indexed newDelegate, string functionSignature ); /// @notice Updates functions in a transparent contract. /// @dev If the value of _delegate is zero then the functions specified /// in _functionSignatures are removed. /// If the value of _delegate is a delegate contract address then the functions /// specified in _functionSignatures will be delegated to that address. /// @param _delegate The address of a delegate contract to delegate to or zero /// to remove functions. /// @param _functionSignatures A list of function signatures listed one after the other /// @param _commitMessage A short description of the change and why it is made /// This message is passed to the CommitMessage event. function updateContract(address _delegate, string calldata _functionSignatures, string calldata _commitMessage) external; } ``` ### Function Signatures String Format The text format for the `_functionSignatures` parameter is simply a string of function signatures. For example: `"myFirstFunction()mySecondFunction(string)"` This format is easy to parse and is concise. Here is an example of calling the `updateContract` function that adds the ERC721 standard functions to a transparent contract: ```javascript functionSignatures = "approve(address,uint256)balanceOf(address)getApproved(uint256)isApprovedForAll(address,address)ownerOf(uint256)safeTransferFrom(address,address,uint256)safeTransferFrom(address,address,uint256,bytes)setApprovalForAll(address,bool)transferFrom(address,address,uint256)" tx = await transparentContract.updateContract(erc721Delegate.address, functionSignatures, "Adding ERC721 functions"); ``` ### Removing Functions Functions are removed by passing `address(0)` as the first argument to the `updateContract` function. The list of functions that are passed in are removed. ### Source Code Verification The transparent contract source code and the source code for the delegate contracts should be verified in a provable way by a third party source such as etherscan.io. <!-- A transparent contract must implement the [ERC-165 Standard Interface Detection standard](/EIPS/eip-165) via a delegate contract by adding the `supportsInterface` function using the `updateContract` function. The interfaceID for the ERC1538 standard is `0x61455567`. --> ### Function Selector Clash A function selector clash occurs when a function is added to a contract that hashes to the same four-byte hash as an existing function. This is unlikely to occur but should be prevented in the implementation of the `updateContract` function. See the [reference implementation of ERC1538](https://github.com/mudgen/transparent-contracts-erc1538) to see an example of how function clashes can be prevented. ### ERC1538Query Optionally, the function signatures of a transparent contract can be stored in an array in the transparent contract and queried to get what functions the transparent contract supports and what their delegate contract addresses are. The following is an optional interface for querying function information from a transparent contract: ```solidity pragma solidity ^0.5.7; interface ERC1538Query { /// @notice Gets the total number of functions the transparent contract has. /// @return The number of functions the transparent contract has, /// not including the fallback function. function totalFunctions() external view returns(uint256); /// @notice Gets information about a specific function /// @dev Throws if `_index` >= `totalFunctions()` /// @param _index The index position of a function signature that is stored in an array /// @return The function signature, the function selector and the delegate contract address function functionByIndex(uint256 _index) external view returns( string memory functionSignature, bytes4 functionId, address delegate ); /// @notice Checks to see if a function exists /// @param The function signature to check /// @return True if the function exists, false otherwise function functionExists(string calldata _functionSignature) external view returns(bool); /// @notice Gets all the function signatures of functions supported by the transparent contract /// @return A string containing a list of function signatures function functionSignatures() external view returns(string memory); /// @notice Gets all the function signatures supported by a specific delegate contract /// @param _delegate The delegate contract address /// @return A string containing a list of function signatures function delegateFunctionSignatures(address _delegate) external view returns(string memory); /// @notice Gets the delegate contract address that supports the given function signature /// @param The function signature /// @return The delegate contract address function delegateAddress(string calldata _functionSignature) external view returns(address); /// @notice Gets information about a function /// @dev Throws if no function is found /// @param _functionId The id of the function to get information about /// @return The function signature and the contract address function functionById(bytes4 _functionId) external view returns( string memory signature, address delegate ); /// @notice Get all the delegate contract addresses used by the transparent contract /// @return An array of all delegate contract addresses function delegateAddresses() external view returns(address[] memory); } ``` See the [reference implementation of ERC1538](https://github.com/mudgen/transparent-contracts-erc1538) to see how this is implemented. The text format for the list of function signatures returned from the `delegateFunctionSignatures` and `functionSignatures` functions is simply a string of function signatures. Here is an example of such a string: `"approve(address,uint256)balanceOf(address)getApproved(uint256)isApprovedForAll(address,address)ownerOf(uint256)safeTransferFrom(address,address,uint256)safeTransferFrom(address,address,uint256,bytes)setApprovalForAll(address,bool)transferFrom(address,address,uint256)"` ### How To Deploy A Transparent Contract 1. Create and deploy to a blockchain a contract that implements the ERC1538 interface. You can skip this step if there is already such a contract deployed to the blockchain. 2. Create your transparent contract with a fallback function as given above. Your transparent contract also needs a constructor that adds the `updateContract` function. 3. Deploy your transparent contract to a blockchain. Pass in the address of the ERC1538 delegate contract to your constructor if it requires it. See the [reference implementation](https://github.com/mudgen/transparent-contracts-erc1538) for examples of these contracts. ### Wrapper Contract for Delegate Contracts that Depend on Other Delegate Contracts In some cases some delegate contracts may need to call external/public functions that reside in other delegate contracts. A convenient way to solve this problem is to create a contract that contains empty implementations of functions that are needed and import and extend this contract in delegate contracts that call functions from other delegate contracts. This enables delegate contracts to compile without having to provide implementations of the functions that are already given in other delegate contracts. This is a way to save gas, prevent reaching the max contract size limit, and prevent duplication of code. This strategy was given by @amiromayer. [See his comment for more information.](https://github.com/ethereum/EIPs/issues/1538#issuecomment-451985155) Another way to solve this problem is to use assembly to call functions provided by other delegate contracts. ### Decentralized Authority It is possible to extend this standard to add consensus functionality such as an approval function that multiple different people call to approve changes before they are submitted with the `updateContract` function. Changes only go into effect when the changes are fully approved. The `CommitMessage` and ` FunctionUpdate` events should only be emitted when changes go into effect. ## Security > This standard refers to **owner(s)** as one or more individuals that have the power to add/replace/remove functions of an upgradeable contract. ### General The owners(s) of an upgradeable contract have the ability to alter, add or remove data from the contract's data storage. Owner(s) of a contract can also execute any arbitrary code in the contract on behalf of any address. Owners(s) can do these things by adding a function to the contract that they call to execute arbitrary code. This is an issue for upgradeable contracts in general and is not specific to transparent contracts. >**Note:** The design and implementation of contract ownership is **not** part of this standard. The examples given in this standard and in the reference implementation are just **examples** of how it could be done. ### Unchangeable Functions "Unchangeable functions" are functions defined in a transparent contract itself and not in a delegate contract. The owner(s) of a transparent contract are not able to replace these functions. The use of unchangeable functions is limited because in some cases they can still be manipulated if they read or write data to the storage of the transparent contract. Data read from the transparent contract's storage could have been altered by the owner(s) of the contract. Data written to the transparent contract's storage can be undone or altered by the owner(s) of the contract. In some cases unchangeble functions add trustless guarantees to a transparent contract. ### Transparency Contracts that implement this standard emit an event every time a function is added, replaced or removed. This enables people and software to monitor the changes to a contract. If any bad acting function is added to a contract then it can be seen. To comply with this standard all source code of a transparent contract and delegate contracts must be publicly available and verified. Security and domain experts can review the history of change of any transparent contract to detect any history of foul play. ## Rationale ### String of Function Signatures Instead of bytes4[] Array of Function Selectors The `updateContract` function takes a `string` list of functions signatures as an argument instead of a `bytes4[]` array of function selectors for three reasons: 1. Passing in function signatures enables the implementation of `updateContract` to prevent selector clashes. 2. A major part of this standard is to make upgradeable contracts more transparent by making it easier to see what has changed over time and why. When a function is added, replaced or removed its function signature is included in the FunctionUpdate event that is emitted. This makes it relatively easy to write software that filters the events of a contract to display to people what functions have been added/removed and changed over time without needing access to the source code or ABI of the contract. If only four-byte function selectors were provided this would not be possible. 3. By looking at the source code of a transparent contract it is not possible to see all the functions that it supports. This is why the ERC1538Query interface exists, so that people and software have a way to look up and examine or show all functions currently supported by a transparent contract. Function signatures are used so that ERC1538Query functions can show them. ### Gas Considerations Delegating function calls does have some gas overhead. This is mitigated in two ways: 1. Delegate contracts can be small, reducing gas costs. Because it costs more gas to call a function in a contract with many functions than a contract with few functions. 2. Because transparent contracts do not have a max size limitation it is possible to add gas optimizing functions for use cases. For example someone could use a transparent contract to implement the ERC721 standard and implement batch transfer functions from the [ERC1412 standard](https://github.com/ethereum/EIPs/issues/1412) to help reduce gas (and make batch transfers more convenient). ### Storage The standard does not specify how data is stored or organized by a transparent contract. But here are some suggestions: **Inherited Storage** 1. The storage variables of a transparent contract consist of the storage variables defined in the transparent contract source code and the source code of delegate contracts that have been added. 2. A delegate contract can use any storage variable that exists in a transparent contract as long as it defines within it all the storage variables that exist, in the order that they exist, up to and including the ones being used. 3. A delegate contract can create new storage variables as long as it has defined, in the same order, all storage variables that exist in the transparent contract. Here is a simple way inherited storage could be implemented: 1. Create a storage contract that contains the storage variables that your transparent contract and delegate contracts will use. 2. Make your delegate contracts inherit the storage contract. 3. If you want to add a new delegate contract that adds new storage variables then create a new storage contract that adds the new storage variables and inherits from the old storage contract. Use your new storage contract with your new delegate contract. 4. Repeat steps 2 or 3 for every new delegate contract. **Unstructured Storage** Assembly is used to store and read data at specific storage locations. An advantage to this approach is that previously used storage locations don't have to be defined or mentioned in a delegate contract if they aren't used by it. **Eternal Storage** Data can be stored using a generic API based on the type of data. [See ERC930 for more information.](https://github.com/ethereum/EIPs/issues/930) ### Becoming Immutable It is possible to make a transparent contract become immutable. This is done by calling the `updateContract` function to remove the `updateContract` function. With this gone it is no longer possible to add, replace and remove functions. ### Versions of Functions Software or a user can verify what version of a function is called by getting the delegate contract address of the function. This can be done by calling the `delegateAddress` function from the ERC1538Query interface if it is implemented. This function takes a function signature as an argument and returns the delegate contract address where it is implemented. ### Best Practices, Tools and More Information > More information, tools, tutorials and best practices concerning transparent contracts need to be developed and published. Below is a growing list of articles concerning transparent contracts and their use. If you have an article about transparent contracts you would like to share then please submit a comment to this issue about it to get it added. [ERC1538: Future Proofing Smart Contracts and Tokens](https://coinjournal.net/erc1538-future-proofing-smart-contacts-and-tokens/) [The ERC1538 improving towards the “transparent contract” standard](https://www.crypto-economy.net/en/ethereum-eth-erc1538-transparent-contract-standard/) ### Inspiration This standard was inspired by ZeppelinOS's implementation of [Upgradeability with vtables](https://github.com/zeppelinos/labs/tree/master/upgradeability_with_vtable). This standard was also inspired by the design and implementation of the [Mokens contract](https://etherscan.io/address/0xc1eab49cf9d2e23e43bcf23b36b2be14fc2f8838#code) from the [Mokens project](https://github.com/Mokens/MIPs/blob/master/MIPS/mip-2-Goals-and-Objectives.md). The Mokens contract has been [upgraded to implement this standard](https://etherscan.io/address/0x0ac5637fe62ec14fd9e237a81a9679d4adef701f#code). ## Backwards Compatibility This standard makes a contract compatible with future standards and functionality because new functions can be added and existing functions can be replaced or removed. This standard future proofs a contract. ## Implementation A reference implementation of this standard is given in the [transparent-contracts-erc1538](https://github.com/mudgen/transparent-contracts-erc1538) repository. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 31 Oct 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1538 https://eips.ethereum.org/EIPS/eip-1538 Fee market change for ETH 1.0 chain Standards Track/Core https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783 ## Simple Summary A transaction pricing mechanism that includes fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with transient congestion. ## Abstract We introduce a new [EIP-2718](/EIPS/eip-2718) transaction type, with the format `0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])`. There is a base fee per gas in protocol, which can move up or down each block according to a formula which is a function of gas used in parent block and gas target (block gas limit divided by elasticity multiplier) of parent block. The algorithm results in the base fee per gas increasing when blocks are above the gas target, and decreasing when blocks are below the gas target. The base fee per gas is burned. Transactions specify the maximum fee per gas they are willing to give to miners to incentivize them to include their transaction (aka: priority fee). Transactions also specify the maximum fee per gas they are willing to pay total (aka: max fee), which covers both the priority fee and the block's network fee per gas (aka: base fee). Senders will always pay the base fee per gas of the block their transaction was included in, and they will pay the priority fee per gas set in the transaction, as long as the combined amount of the two fees doesn't exceed the transaction's maximum fee per gas. ## Motivation Ethereum historically priced transaction fees using a simple auction mechanism, where users send transactions with bids ("gasprices") and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. This leads to several large sources of inefficiency: * **Mismatch between volatility of transaction fee levels and social cost of transactions**: bids to include transactions on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. It's absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 10x more when the cost per gas is 10 nanoeth compared to when the cost per gas is 1 nanoeth; in both cases, it's a difference between 8 million gas and 8.02 million gas. * **Needless delays for users**: because of the hard per-block gas limit coupled with natural volatility in transaction volume, transactions often wait for several blocks before getting included, but this is socially unproductive; no one significantly gains from the fact that there is no "slack" mechanism that allows one block to be bigger and the next block to be smaller to meet block-by-block differences in demand. * **Inefficiencies of first price auctions**: The current approach, where transaction senders publish a transaction with a bid a maximum fee, miners choose the highest-paying transactions, and everyone pays what they bid. This is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required. But even these algorithms often end up not working very well, leading to frequent fee overpayment. * **Instability of blockchains with no block reward**: In the long run, blockchains where there is no issuance (including Bitcoin and Zcash) at present intend to switch to rewarding miners entirely through transaction fees. However, there are known issues with this that likely leads to a lot of instability, incentivizing mining "sister blocks" that steal transaction fees, opening up much stronger selfish mining attack vectors, and more. There is at present no good mitigation for this. The proposal in this EIP is to start with a base fee amount which is adjusted up and down by the protocol based on how congested the network is. When the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly. Because these base fee changes are constrained, the maximum difference in base fee from block to block is predictable. This then allows wallets to auto-set the gas fees for users in a highly reliable fashion. It is expected that most users will not have to manually adjust gas fees, even in periods of high network activity. For most users the base fee will be estimated by their wallet and a small priority fee, which compensates miners taking on orphan risk (e.g. 1 nanoeth), will be automatically set. Users can also manually set the transaction max fee to bound their total costs. An important aspect of this fee system is that miners only get to keep the priority fee. The base fee is always burned (i.e. it is destroyed by the protocol). This ensures that only ETH can ever be used to pay for transactions on Ethereum, cementing the economic value of ETH within the Ethereum platform and reducing risks associated with miner extractable value (MEV). Additionally, this burn counterbalances Ethereum inflation while still giving the block reward and priority fee to miners. Finally, ensuring the miner of a block does not receive the base fee is important because it removes miner incentive to manipulate the fee in order to extract more fees from users. ## Specification Block validity is defined in the reference implementation below. The `GASPRICE` (`0x3a`) opcode **MUST** return the `effective_gas_price` as defined in the reference implementation below. As of `FORK_BLOCK_NUMBER`, a new [EIP-2718](/EIPS/eip-2718) transaction is introduced with `TransactionType` 2. The intrinsic cost of the new transaction is inherited from [EIP-2930](/EIPS/eip-2930), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. The [EIP-2718](/EIPS/eip-2718) `TransactionPayload` for this transaction is `rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])`. The `signature_y_parity, signature_r, signature_s` elements of this transaction represent a secp256k1 signature over `keccak256(0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list]))`. The [EIP-2718](/EIPS/eip-2718) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`. *Note: `//` is integer division, round down.* ```python from typing import Union, Dict, Sequence, List, Tuple, Literal from dataclasses import dataclass, field from abc import ABC, abstractmethod @dataclass class TransactionLegacy: signer_nonce: int = 0 gas_price: int = 0 gas_limit: int = 0 destination: int = 0 amount: int = 0 payload: bytes = bytes() v: int = 0 r: int = 0 s: int = 0 @dataclass class Transaction2930Payload: chain_id: int = 0 signer_nonce: int = 0 gas_price: int = 0 gas_limit: int = 0 destination: int = 0 amount: int = 0 payload: bytes = bytes() access_list: List[Tuple[int, List[int]]] = field(default_factory=list) signature_y_parity: bool = False signature_r: int = 0 signature_s: int = 0 @dataclass class Transaction2930Envelope: type: Literal[1] = 1 payload: Transaction2930Payload = Transaction2930Payload() @dataclass class Transaction1559Payload: chain_id: int = 0 signer_nonce: int = 0 max_priority_fee_per_gas: int = 0 max_fee_per_gas: int = 0 gas_limit: int = 0 destination: int = 0 amount: int = 0 payload: bytes = bytes() access_list: List[Tuple[int, List[int]]] = field(default_factory=list) signature_y_parity: bool = False signature_r: int = 0 signature_s: int = 0 @dataclass class Transaction1559Envelope: type: Literal[2] = 2 payload: Transaction1559Payload = Transaction1559Payload() Transaction2718 = Union[Transaction1559Envelope, Transaction2930Envelope] Transaction = Union[TransactionLegacy, Transaction2718] @dataclass class NormalizedTransaction: signer_address: int = 0 signer_nonce: int = 0 max_priority_fee_per_gas: int = 0 max_fee_per_gas: int = 0 gas_limit: int = 0 destination: int = 0 amount: int = 0 payload: bytes = bytes() access_list: List[Tuple[int, List[int]]] = field(default_factory=list) @dataclass class Block: parent_hash: int = 0 uncle_hashes: Sequence[int] = field(default_factory=list) author: int = 0 state_root: int = 0 transaction_root: int = 0 transaction_receipt_root: int = 0 logs_bloom: int = 0 difficulty: int = 0 number: int = 0 gas_limit: int = 0 # note the gas_limit is the gas_target * ELASTICITY_MULTIPLIER gas_used: int = 0 timestamp: int = 0 extra_data: bytes = bytes() proof_of_work: int = 0 nonce: int = 0 base_fee_per_gas: int = 0 @dataclass class Account: address: int = 0 nonce: int = 0 balance: int = 0 storage_root: int = 0 code_hash: int = 0 INITIAL_BASE_FEE = 1000000000 INITIAL_FORK_BLOCK_NUMBER = 10 # TBD BASE_FEE_MAX_CHANGE_DENOMINATOR = 8 ELASTICITY_MULTIPLIER = 2 class World(ABC): def validate_block(self, block: Block) -> None: parent_gas_target = self.parent(block).gas_limit // ELASTICITY_MULTIPLIER parent_gas_limit = self.parent(block).gas_limit # on the fork block, don't account for the ELASTICITY_MULTIPLIER to avoid # unduly halving the gas target. if INITIAL_FORK_BLOCK_NUMBER == block.number: parent_gas_target = self.parent(block).gas_limit parent_gas_limit = self.parent(block).gas_limit * ELASTICITY_MULTIPLIER parent_base_fee_per_gas = self.parent(block).base_fee_per_gas parent_gas_used = self.parent(block).gas_used transactions = self.transactions(block) # check if the block used too much gas assert block.gas_used <= block.gas_limit, 'invalid block: too much gas used' # check if the block changed the gas limit too much assert block.gas_limit < parent_gas_limit + parent_gas_limit // 1024, 'invalid block: gas limit increased too much' assert block.gas_limit > parent_gas_limit - parent_gas_limit // 1024, 'invalid block: gas limit decreased too much' # check if the gas limit is at least the minimum gas limit assert block.gas_limit >= 5000 # check if the base fee is correct if INITIAL_FORK_BLOCK_NUMBER == block.number: expected_base_fee_per_gas = INITIAL_BASE_FEE elif parent_gas_used == parent_gas_target: expected_base_fee_per_gas = parent_base_fee_per_gas elif parent_gas_used > parent_gas_target: gas_used_delta = parent_gas_used - parent_gas_target base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1) expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta else: gas_used_delta = parent_gas_target - parent_gas_used base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta assert expected_base_fee_per_gas == block.base_fee_per_gas, 'invalid block: base fee not correct' # execute transactions and do gas accounting cumulative_transaction_gas_used = 0 for unnormalized_transaction in transactions: # Note: this validates transaction signature and chain ID which must happen before we normalize below since normalized transactions don't include signature or chain ID signer_address = self.validate_and_recover_signer_address(unnormalized_transaction) transaction = self.normalize_transaction(unnormalized_transaction, signer_address) signer = self.account(signer_address) signer.balance -= transaction.amount assert signer.balance >= 0, 'invalid transaction: signer does not have enough ETH to cover attached value' # the signer must be able to afford the transaction assert signer.balance >= transaction.gas_limit * transaction.max_fee_per_gas # ensure that the user was willing to at least pay the base fee assert transaction.max_fee_per_gas >= block.base_fee_per_gas # Prevent impossibly large numbers assert transaction.max_fee_per_gas < 2**256 # Prevent impossibly large numbers assert transaction.max_priority_fee_per_gas < 2**256 # The total must be the larger of the two assert transaction.max_fee_per_gas >= transaction.max_priority_fee_per_gas # priority fee is capped because the base fee is filled first priority_fee_per_gas = min(transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas) # signer pays both the priority fee and the base fee effective_gas_price = priority_fee_per_gas + block.base_fee_per_gas signer.balance -= transaction.gas_limit * effective_gas_price assert signer.balance >= 0, 'invalid transaction: signer does not have enough ETH to cover gas' gas_used = self.execute_transaction(transaction, effective_gas_price) gas_refund = transaction.gas_limit - gas_used cumulative_transaction_gas_used += gas_used # signer gets refunded for unused gas signer.balance += gas_refund * effective_gas_price # miner only receives the priority fee; note that the base fee is not given to anyone (it is burned) self.account(block.author).balance += gas_used * priority_fee_per_gas # check if the block spent too much gas transactions assert cumulative_transaction_gas_used == block.gas_used, 'invalid block: gas_used does not equal total gas used in all transactions' # TODO: verify account balances match block's account balances (via state root comparison) # TODO: validate the rest of the block def normalize_transaction(self, transaction: Transaction, signer_address: int) -> NormalizedTransaction: # legacy transactions if isinstance(transaction, TransactionLegacy): return NormalizedTransaction( signer_address = signer_address, signer_nonce = transaction.signer_nonce, gas_limit = transaction.gas_limit, max_priority_fee_per_gas = transaction.gas_price, max_fee_per_gas = transaction.gas_price, destination = transaction.destination, amount = transaction.amount, payload = transaction.payload, access_list = [], ) # 2930 transactions elif isinstance(transaction, Transaction2930Envelope): return NormalizedTransaction( signer_address = signer_address, signer_nonce = transaction.payload.signer_nonce, gas_limit = transaction.payload.gas_limit, max_priority_fee_per_gas = transaction.payload.gas_price, max_fee_per_gas = transaction.payload.gas_price, destination = transaction.payload.destination, amount = transaction.payload.amount, payload = transaction.payload.payload, access_list = transaction.payload.access_list, ) # 1559 transactions elif isinstance(transaction, Transaction1559Envelope): return NormalizedTransaction( signer_address = signer_address, signer_nonce = transaction.payload.signer_nonce, gas_limit = transaction.payload.gas_limit, max_priority_fee_per_gas = transaction.payload.max_priority_fee_per_gas, max_fee_per_gas = transaction.payload.max_fee_per_gas, destination = transaction.payload.destination, amount = transaction.payload.amount, payload = transaction.payload.payload, access_list = transaction.payload.access_list, ) else: raise Exception('invalid transaction: unexpected number of items') @abstractmethod def parent(self, block: Block) -> Block: pass @abstractmethod def block_hash(self, block: Block) -> int: pass @abstractmethod def transactions(self, block: Block) -> Sequence[Transaction]: pass # effective_gas_price is the value returned by the GASPRICE (0x3a) opcode @abstractmethod def execute_transaction(self, transaction: NormalizedTransaction, effective_gas_price: int) -> int: pass @abstractmethod def validate_and_recover_signer_address(self, transaction: Transaction) -> int: pass @abstractmethod def account(self, address: int) -> Account: pass ``` ## Backwards Compatibility Legacy Ethereum transactions will still work and be included in blocks, but they will not benefit directly from the new pricing system. This is due to the fact that upgrading from legacy transactions to new transactions results in the legacy transaction's `gas_price ` entirely being consumed either by the `base_fee_per_gas` and the `priority_fee_per_gas`. ### Block Hash Changing The datastructure that is passed into keccak256 to calculate the block hash is changing, and all applications that are validating blocks are valid or using the block hash to verify block contents will need to be adapted to support the new datastructure (one additional item). If you only take the block header bytes and hash them you should still correctly get a hash, but if you construct a block header from its constituent elements you will need to add in the new one at the end. ### GASPRICE Previous to this change, `GASPRICE` represented both the ETH paid by the signer per gas for a transaction as well as the ETH received by the miner per gas. As of this change, `GASPRICE` now only represents the amount of ETH paid by the signer per gas, and the amount a miner was paid for the transaction is no longer accessible directly in the EVM. ## Security Considerations ### Increased Max Block Size/Complexity This EIP will increase the maximum block size, which could cause problems if miners are unable to process a block fast enough as it will force them to mine an empty block. Over time, the average block size should remain about the same as without this EIP, so this is only an issue for short term size bursts. It is possible that one or more clients may handle short term size bursts poorly and error (such as out of memory or similar) and client implementations should make sure their clients can appropriately handle individual blocks up to max size. ### Transaction Ordering With most people not competing on priority fees and instead using a baseline fee to get included, transaction ordering now depends on individual client internal implementation details such as how they store the transactions in memory. It is recommended that transactions with the same priority fee be sorted by time the transaction was received to protect the network from spamming attacks where the attacker throws a bunch of transactions into the pending pool in order to ensure that at least one lands in a favorable position. Miners should still prefer higher gas premium transactions over those with a lower gas premium, purely from a selfish mining perspective. ### Miners Mining Empty Blocks It is possible that miners will mine empty blocks until such time as the base fee is very low and then proceed to mine half full blocks and revert to sorting transactions by the priority fee. While this attack is possible, it is not a particularly stable equilibrium as long as mining is decentralized. Any defector from this strategy will be more profitable than a miner participating in the attack for as long as the attack continues (even after the base fee reached 0). Since any miner can anonymously defect from a cartel, and there is no way to prove that a particular miner defected, the only feasible way to execute this attack would be to control 50% or more of hashing power. If an attacker had exactly 50% of hashing power, they would make no Ether from priority fee while defectors would make double the Ether from priority fees. For an attacker to turn a profit, they need to have some amount over 50% hashing power, which means they can instead execute double spend attacks or simply ignore any other miners which is a far more profitable strategy. Should a miner attempt to execute this attack, we can simply increase the elasticity multiplier (currently 2x) which requires they have even more hashing power available before the attack can even be theoretically profitable against defectors. ### ETH Burn Precludes Fixed Supply By burning the base fee, we can no longer guarantee a fixed Ether supply. This could result in economic instability as the long term supply of ETH will no longer be constant over time. While a valid concern, it is difficult to quantify how much of an impact this will have. If more is burned on base fee than is generated in mining rewards then ETH will be deflationary and if more is generated in mining rewards than is burned then ETH will be inflationary. Since we cannot control user demand for block space, we cannot assert at the moment whether ETH will end up inflationary or deflationary, so this change causes the core developers to lose some control over Ether's long term quantity. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 13 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1559 https://eips.ethereum.org/EIPS/eip-1559 EthereumStratum/2.0.0 Standards Track/Interface https://github.com/AndreaLanfranchi/EthereumStratum-2.0.0/issues ## Abstract This draft contains the guidelines to define a new standard for the Stratum protocol used by Ethereum miners to communicate with mining pool servers. ### Conventions The key words `MUST`, `MUST NOT`, `REQUIRED`, `SHALL`, `SHALL NOT`, `SHOULD`, `SHOULD NOT`, `RECOMMENDED`, `MAY`, and `OPTIONAL` in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). The definition `mining pool server`, and it's plural form, is to be interpreted as `work provider` and later in this document can be shortened as `pool` or `server`. The definition `miner(s)`, and it's plural form, is to be interpreted as `work receiver/processor` and later in this document can be shortened as `miner` or `client`. ### Rationale Ethereum does not have an official Stratum implementation yet. It officially supports only getWork which requires miners to constantly pool the work provider. Only recently go-ethereum have implemented a [push mechanism](https://github.com/ethereum/go-ethereum/pull/17347) to notify clients for mining work, but whereas the vast majority of miners do not run a node, it's main purpose is to facilitate mining pools rather than miners. The Stratum protocol on the other hand relies on a standard stateful TCP connection which allows two-way exchange of line-based messages. Each line contains the string representation of a JSON object following the rules of either [JSON-RPC 1.0](https://www.jsonrpc.org/specification_v1) or [JSON-RPC 2.0](https://www.jsonrpc.org/specification). Unfortunately, in absence of a well defined standard, various flavours of Stratum have bloomed for Ethereum mining as a derivative work for different mining pools implementations. The only attempt to define a standard was made by NiceHash with their [EthereumStratum/1.0.0](https://github.com/nicehash/Specifications/blob/master/EthereumStratum_NiceHash_v1.0.0.txt) implementation which is the main source this work inspires from. Mining activity, thus the interaction among pools and miners, is at it's basics very simple, and can be summarized with "_please find a number (nonce) which coupled to this data as input for a given hashing algorithm produces, as output, a result which is below a certain target_". Other messages which may or have to be exchanged among parties during a session are needed to support this basic concept. Due to the simplicity of the subject, the proponent, means to stick with JSON formatted objects rather than investigating more verbose solutions, like for example [Google's Protocol Buffers](https://developers.google.com/protocol-buffers/docs/overview) which carry the load of strict object definition. ### Stratum design flaws The main Stratum design flaw is the absence of a well defined standard. This implies that miners (and mining software developers) have to struggle with different flavours which make their life hard when switching from one pool to another or even when trying to "guess" which is the flavour implemented by a single pool. Moreover all implementations still suffer from an excessive verbosity for a chain with a very small block time like Ethereum. A few numbers may help understand. A normal `mining.notify` message weigh roughly 240 bytes: assuming the dispatch of 1 work per block to an audience of 50k connected TCP sockets means the transmission of roughly 1.88TB of data a month. And this can be an issue for large pools. But if we see the same figures the other way round, from a miner's perspective, we totally understand how mining decentralization is heavily affected by the quality of internet connections. ### Sources of inspiration - [NiceHash EthereumStratum/1.0.0](https://github.com/nicehash/Specifications/blob/master/EthereumStratum_NiceHash_v1.0.0.txt) - [Zcash variant of the Stratum protocol](https://github.com/zcash/zips/blob/23d74b0373c824dd51c7854c0e3ea22489ba1b76/drafts/str4d-stratum/draft1.rst#json-rpc-1-0) ## Specification The Stratum protocol is an instance of [JSON-RPC-2.0](https://www.jsonrpc.org/specification). The miner is a JSON-RPC client, and the server is a JSON-RPC server. All communications exist within the scope of a `session`. A session starts at the moment a client opens a TCP connection to the server till the moment either party do voluntary close the very same connection or it gets broken. Servers **MAY** support session resuming if this is initially negotiated (on first session handshaking) between the client and the server. During a session all messages exchanged among server and client are line-based which means all messages are JSON strings terminated by ASCII LF character (which may also be denoted as `\n` in this document). The LF character **MUST NOT** appear elsewhere in a message. Client and server implementations **MUST** assume that once they read a LF character, the current message has been completely received and can be processed. Line messages are of three types: - `Requests` : messages for which the issuer expects a response. The receiver **MUST** reply back to any request individually - `Responses` : solicited messages by a previous request. The responder **MUST** label the response with the same identifier of the originating request. - `Notifications` : unsolicited messages for which the issuer is not interested nor is expecting a response. Nevertheless a response (eg. an acknowledgement) **MAY** be sent by the receiver. During a `session` both parties **CAN** exchange messages of the above depicted three types. ### JSON-RPC-2.0 Compliances As per [JSON-RPC-2.0](https://www.jsonrpc.org/specification) specification requests and responses differ from notifications by the identifier (`id`) member in the JSON object: - Requests **MUST** have an `id` member - Responses **MUST** have an `id` member valued exactly as the `id` member of the request this response is for - Notifications **MUST NOT** have an `id` member ### JSON-RPC-2.0 Defiances In order to get the most concise messages among parties of a session/conversation this implementation enforces the following defiances: - JSON member `jsonrpc` (always valued to "2.0") **MUST ALWAYS BE OMITTED** - JSON member `id` **MUST NOT** be `null`. When member is present, mandatorily in requests and responses, it **MUST** be valued to an integer Number ranging from 0 to 65535. Please note that a message with `"id": 0` **MUST NOT** be interpreted as a notification: it's a request with identifier 0 - JSON member `id` **MUST** be only of type primitive number. The removal of other identifier types (namely strings) is due to the need to reduce the number of bytes transferred. ## Conventions - The representation of a JSON object is, at it's base, a string - The conversation among the client and the server is made of strings. Each string ending with a LF (ASCII char 10) denotes a `line`. Each line **MUST** contain only one JSON root object. Eventually the root object **MAY** contain additional JSON objects in it's members. - Aside the `LF` delimiter each `line` **MUST** be made of printable ASCII chars in the range 32..126 - It's implicit and mandatory that each line message corresponds to a well formatted JSON object: see [JSON documentation](https://www.json.org/) - JSON objects are made of `members` which can be of type : primitive of string/number, JSON object, JSON arrays - JSON `member`'s names are strings which **MUST** be composed of printable chars only in the ASCII range 48..57 (numbers) and 97..122 (lower case letters). - JSON `member`'s names **MUST NOT** begin with a number. - JSON values `arrays` : although the JSON notation allows the insertion of different data types within the same array, this behavior is generally not accepted in coding languages. Due to this, by the means of EthereumStratum/2.0.0, all implementers **MUST** assume that an array is made of elements of the very same data type. - JSON values `booleans` : the JSON notation allows to express boolean values as `true` or `false`. In EthereumStratum/2.0.0, for better compatibility within arrays, boolean values will be expressed in the hex form of "0" (false) or "1" (true) - JSON values `strings` : any string value **MUST** be composed of printable ASCII chars only in the ASCII range 32..126. Each string is delimited by a `"` (ASCII 34) at the beginning and at the end. Should the string value contain a `"` this must be escaped as `\"` - Hex values : a Hexadecimal representation of a number is actually a string data type. As a convention, and to reduce the number of transmitted bytes, the prefix "0x" **MUST** always be omitted. In addition any hex number **MUST** be transferred only for their significant part i.e. the non significant zeroes **MUST** be omitted (example : the decimal `456` must be represented as `"1c8"` and not as `"01c8"` although the conversion produces the same decimal value). This directive **DOES NOT APPLY** to hashes and extranonces - Hex values casing : all letters in Hexadecimal values **MUST** be lower case. (example : the decimal `456` must be represented as `"1c8"` and not as `"1C8"` although the conversion produces the same decimal value). This directive **DOES NOT APPLY** to hashes. - Numbers : any non-fractional number **MUST** be transferred by it's hexadecimal representation ### Requests The JSON representation of `request` object is made of these parts: - mandatory `id` member of type Integer : the identifier established by the issuer - mandatory `method` member of type String : the name of the method to be invoked on the receiver side - optional `params` member : in case the method invocation on the receiver side requires the application of additional parameters to be executed. The type **CAN** be Object (with named members of different types) or Array of single type. In case of an array the parameters will be applied by their ordinal position. If the method requested for invocation on the receiver side does not require the application of additional parameters this member **MUST NOT** be present. The notation `"params" : null` **IS NOT PERMITTED** ### Responses The JSON representation of `response` object is made of these parts: - mandatory `id` member of type Integer : the identifier of the request this response corresponds to - optional `error` member : whether an error occurred during the parsing of the method or during it's execution this member **MUST** be present and valued. If no errors occurred this member **MUST NOT** be present. For a detailed structure of the `error` member see below. - optional `result` member : This has to be set, if the corresponding request requires a result from the user. If no errors occurred by invoking the corresponding function, this member **MUST** be present even if one or more information are null. The type can be of Object or single type Array or Primitive string/number. If no data is meant back for the issuer (the method is void on the receiver) or an error occurred this member **MUST NOT** be present. You'll notice here some differences with standard JSON-RPC-2.0. Namely the result member is not always required. Basically a response like this: ```json {"id": 2} ``` means "request received and processed correctly with no data to send back". To better clarify the concept and clear the field of free interpretations let's take another example of **wrong response** ```json {"id": 2, "result": false} ``` This response syntax leaves room to many interpretations: is it an error? is `false` the legit response value to the issued request? For this reason responses, we reiterate, **MUST BE** of two types: - success responses : no error occurred during the processing, the request was legit, syntactically correct, and the receiver had no issues processing it. This kind of responses **MUST NOT** have the `error` member and **MAY** have the `result` member if a value is expected back to the issuer. - failure responses : something wrong with the request, it's syntax, it's validity scope, or server processing problems. This kind of responses **MUST HAVE** the `error` member and **MAY** have the `result` member. The latter deserves a better explanation: failure responses can be distinguished by a severity degree. Example 1 : a client submits a solution and server rejects it cause it's not below target. Server **MUST** respond like this; ```json { "id": 31, "error": { "code": 406, "message" : "Bad nonce" } } ``` Example 2 : a client submits a solution and server **accepts** it **but** it accounts the share as stale. Server **MUST** respond like this; ```json { "id": 31, "error": { "code": 202, "message" : "Stale" } } ``` Example 3 : a client submits an authorization request specifying an invalid workername. Server authorizes the account but rejects worker name. Server **MUST** respond like this; ```json { "id": 1, "error": { "code": 215, "message" : "Invalid Worker Name" } } ``` Example 1 depicts the condition of a severe failure while Example 2 and 3 depict a situation where the request has been accepted and processed properly but the result **MAY NOT** be what expected by the client. It's up to the client to evaluate the severity of the error and decide whether to proceed or not. Using proper error codes pools may properly inform miners of the condition of their requests. Error codes **MUST** honor this scheme: - Error codes 2xx : request accepted and processed but some additional info in the `error` member may give hint - Error codes 3xx : server could not process the request due to a lack of authorization by the client - Error codes 4xx : server could not process the request due to syntactic problems (method not found, missing params, wrong data types ecc.) or passed `param` values are not valid. - Error codes 5xx : server could not process the request due to internal errors ### Notifications A notification message has the very same representation of a `request` with the only difference the `id` member **MUST NOT** be present. This means the issuer is not interested nor expects any response to this message. It's up to the receiver to take actions accordingly. For instance the receiver **MAY** decide to execute the method, or, in case of errors or methods not allowed, drop the connection thus closing the session. #### Error member As seen above a `response` **MAY** contain an `error` member. When present this member **MUST** be an Object with: - mandatory member `code` : a Number which identifies the error occurred - mandatory member `message` : a short human readable sentence describing the error occurred - optional member `data` : a Structured or Primitive value that contains additional information about the error. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.). ## Protocol Flow - Client starts session by opening a TCP socket to the server - Client advertises and request protocol compatibility - Server confirms compatibility and declares ready - Client starts/resumes a session - Client sends request for authorization for each of it's workers - Server replies back with responses for each authorization - Server sends `mining.set` for constant values to be adopted for following mining jobs - Server sends `mining.notify` with minimal job info - Client mines on job - Client sends `mining.submit` if any solution found for the job - Server replies whether solution is accepted - Server optionally sends `mining.set` for constant values to be adopted for following mining jobs (if something changed) - Server sends `mining.notify` with minimal job info - ... (continue) - Eventually either party closes session and TCP connection ### Session Handling - Hello ~~One of the worst annoyances until now is that server, at the very moment of socket connection, does not provide any useful information about the stratum flavour implemented. This means the client has to start a conversation by iteratively trying to connect via different protocol flavours. This proposal amends the situation making mandatory for the server to advertise itself to the client. When a new client connects to the server, the server **MUST** send a `mining.hello` notification :~~ It's been noted that charging the server of the duty to advertise itself as first message of the conversation could potentially be harmful in respect of traffic amplification attacks using spoofed IP addresses or in traditional DDos attacks where an attacker need to spend very little resources to force the server to send a large packet back. For this reason the duty of first advertisement is kept on client which will issue a `mining.hello` request like this: ```json { "id" : 0, "method": "mining.hello", "params": { "agent": "ethminer-0.17", "host" : "somemininigpool.com", "port" : "4d2", "proto": "EthereumStratum/2.0.0" } } ``` The `params` member object has these mandatory members: - `agent` (string) the mining software version - `host` (string) the host name of the server this client is willing to connect to - `port` (hex) the port number of the server this client is willing to connect to - `proto` (string) which reports the stratum flavour requested and expected to be implemented by the server; The rationale behind sending host and port is it enables virtual hosting, where virtual pools or private URLs might be used for DDoS protection, but that are aggregated on Stratum server backends. As with HTTP, the server CANNOT trust the host string. The port is included separately to parallel the client.reconnect method (see below). If the server is prepared to start/resume a session with such requirements it **MUST** reply back with a response like this: ```json { "id" : 0, "result": { "proto" : "EthereumStratum/2.0.0", "encoding" : "gzip", "resume" : "1", "timeout" : "b4", "maxerrors" : "5", "node" : "Geth/v1.8.18-unstable-f08f596a/linux-amd64/go1.10.4" } } ``` Where the `result` is an object made of 5 mandatory members - `proto` (string) which **MUST** match the exact version requested by the client - `encoding` (string) which value states whether or not all **next messages** should be gzip compressed or not. Possible values are "gzip" or "plain" - `resume` (hex) which value states whether or not the host can resume a previously created session; - `timeout` (hex) which reports the number of seconds after which the server is allowed to drop connection if no messages from the client - `maxerrors` (hex) the maximum number of errors the server will bear before abruptly close connection - `node` (string) the node software version underlying the pool When the server replies back with `"encoding" : "gzip"` to the client, both parties **MUST** gzip compress all next messages. In case the client is not capable of compression it **MUST** close the connection immediately. Should the server, after this reply, receive other messages as plain text, it **MUST** close the connection. Eventually the client will continue with `mining.subscribe` (further on descripted) Otherwise, in case of errors or rejection to start the conversation, the server **MAY** reply back with an error giving the other party useful information or, at server's maintainers discretion, abruptly close the connection. ```json { "id" : 0, "error": { "code": 400, "message" : "Bad protocol request" } } ``` or ```json { "id" : 0, "error": { "code": 403, "message" : "Forbidden - Banned IP address" } } ``` _The above two JSON error values are only samples_ Eventually the server will close the connection. Why a pool should advertise the node's version? It's a matter of transparency : miners should know whether or not pool have upgraded to latest patches/releases for node's software. ### Session Handling - Bye Disconnection are not gracefully handled in Stratum. Client disconnections from pool may be due to several errors and this leads to waste of TCP sockets on server's side which wait for keepalive timeouts to trigger. A useful notification is `mining.bye` which, once processed, allows both parties of the session to stop receiving and gracefully close TCP connections ```json { "method": "mining.bye" } ``` The party receiving this message aknowledges the other party wants to stop the conversation and closes the socket. The issuer will close too. The explicit issuance of this notification implies the session gets abandoned so no session resuming will be possible even on server which support session-resuming. Client reconnecting to the same server which implements session resuming **SHOULD** expect a new session id and **MUST** re-authorize all their workers. ### Session Handling - Session Subscription After receiving the response to `mining.hello` from server, the client, in case the server does support session resuming **MAY** request to resume a previously interrupted session with `mining.subscribe` request: ```json { "id": 1, "method": "mining.subscribe", "params": "s-12345" } ``` where `params` is the id of the session the client wants to resume. Otherwise, if client wants to start a new session **OR** server does not support session resuming, the request of subscription **MUST** omit the `params` member: ```json { "id": 1, "method": "mining.subscribe" } ``` ### Session Handling - Response to Subscription A server receiving a client session subscription **MUST** reply back with ```json { "id": 1, "result": "s-12345" } ``` A server receiving a subscription request with `params` being a string holding the session id. This cases may apply - If session resuming is not supported `result` will hold a new session Id which **MUST** be a different value from the `session` member issued by client in previous `mining.subscribe` method - If session resuming is supported it will retrieve working values from cache and `result` will have the same id requested by the client. This means a session is "resumed": as a consequence the server **CAN** start pushing jobs omitting to precede them with `mining.set` (see below) and the client **MUST** continue to use values lastly received within the same session scope. In addition the client **CAN** omit to re-authorize all it's workers. - If session resuming is supported but the requested session has expired or it's cache values have been purged `result` will hold a new session Id which **MUST** be a different value from the `session` member issued by client in previous `mining.subscribe` method. As a consequence the server **MUST** wait for client to request authorization for it's workers and **MUST** send `mining.set` values before pushing jobs. The client **MUST** prepare for a new session discarding all previously cached values (if any). A server implementing session-resuming **MUST** cache: - The session Ids - Any active job per session - The extraNonce - Any authorized worker Servers **MAY** drop entries from the cache on their own schedule. It's up to server to enforce session validation for same agent and/or ip. A client which successfully subscribes and resumes session (the `session` value in server response is identical to `session` value requested by client on `mining.subscribe`) **CAN** omit to issue the authorization request for it's workers. ### Session Handling - Noop There are cases when a miner struggles to find a solution in a reasonable time so it may trigger the timeout imposed by the server in case of no communications (the server, in fact, may think the client got disconnected). To mitigate the problem a new method `mining.noop`(with no additional parameters) may be requested by the client. ```json { "id": 50, "method": "mining.noop" } ``` ### Session Handling - Reconnect Under certain circumstances the server may need to free some resources and or to relocate miners to another machine. Until now the only option for servers was to abruptly close the connection. On the miner's side this action is interpreted as a server malfunction and they, more often than not, switch to a failover pool. The implementation of the notification `mining.reconnect` helps client to better merge with logic of handling of large mining pools. ```json { "method": "mining.reconnect", "params": { "host": "someotherhost.com", "port": "d80", "resume": "1" } } ``` This notification is meant only from servers to clients. Should a server receive such a notification it will simply ignore it. After the notification has been properly sent, the server is ALLOWED to close the connection, while the client will take the proper actions to reconnect to the suggested end-point. The `host` member in `params` object **SHOULD** report a host DNS name and not an IP address: TLS encrypted connections require to validate the CN name in the certificate which, 99% of the cases, is a host name. The third member `resume` of the `params` object sets whether or not the receiving server is prepared for session resuming. After this notification has been issued by the server, the client should expect no further messages and **MUST** disconnect. ### Workers Authorization The miner **MUST** authorize at least one worker in order to begin receiving jobs and submit solutions or hashrates. The miner **MAY** authorize multiple workers in the same session. The server **MUST** allow authorization for multiple workers within a session and **MUST** validate at least one authorization from the client before starting to send jobs. A `worker` is a tuple of the address where rewards must be credited coupled with identifier of the machine actually doing the work. For Ethereum the most common form is `<account>.<MachineName>`. The same account can be bound to multiple machines. For pool's allowing anonymous mining the account is the address where rewards must be credited, while, for pools requiring registration, the account is the login name. Each time a solution is submitted by the client it must be labelled with the Worker identifier. It's up to server to keep the correct accounting for different addresses. The syntax for the authorization request is the following: ```json { "id": 2, "method": "mining.authorize", "params": ["<account>[.<MachineName>]", "password"] } ``` `params` member must be an Array of 2 string elements. For anonymous mining the "password" can be any string value or empty but not null. Pools allowing anonymous mining will simply ignore the value. The server **MUST** reply back either with an error or, in case of success, with ```json { "id": 2, "result": "w-123" } ``` Where the `result` member is a string which holds an unique - within the scope of the `session` - token which identifies the authorized worker. For every further request issued by the client, and related to a Worker action, the client **MUST** use the token given by the server in response to an `mining.authorize` request. This reduces the number of bytes transferred for solution and /or hashrate submission. If client is resuming a previous session it **CAN** omit the authorization request for it's workers and, in this case, **MUST** use the tokens assigned in the originating session. It's up to the server to keep the correct map between tokens and workers. The server receiving an authorization request where the credentials match previously authorized ones within the same session **MUST** reply back with the previously generated unique token. ### Prepare for mining A lot of data is sent over the wire multiple times with useless redundancy. For instance the seed hash is meant to change only every 30000 blocks (roughly 5 days) while fixed-diff pools rarely change the work target. Moreover pools must optimize the search segments among miners trying to assign to every session a different "startNonce" (AKA extraNonce). For this purpose the `notification` method `mining.set` allows to set (on miner's side) only those params which change less frequently. The server will keep track of seed, target and extraNonce at session level and will push a notification `mining.set` whenever any (or all) of those values change to the connected miner. ```json { "method": "mining.set", "params": { "epoch" : "dc", "target" : "0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba", "algo" : "ethash", "extranonce" : "af4c" } } ``` At the beginning of each `session` the server **MUST** send this notification before any `mining.notify`. All values passed by this notification will be valid for all **NEXT** jobs until a new `mining.set` notification overwrites them. Description of members is as follows: - optional `epoch` (hex) : unlike all actual Stratum implementations the server should inform the client of the epoch number instead of passing the seed hash. This is enforced by two reasons: the main one is that client has only one way to compute the epoch number and this is by a linear search from epoch 0 iteratively trying increasing epochs till the hash matches the seed hash. Second reason is that epoch number is more concise than seed hash. In the end the seed hash is only transmitted to inform the client about the epoch and is not involved in the mining algorithm. - optional `target` (hex) : this is the boundary hash already adjusted for pool difficulty. Unlike in EthereumStratum/1.0.0, which provides a `mining.set_difficulty` notification of an _index of difficulty_, the proponent opt to pass directly the boundary hash. If omitted the client **MUST** assume a boundary of `"0x00000000ffff0000000000000000000000000000000000000000000000000000"` - optional `algo` (string) : the algorithm the miner is expected to mine on. If omitted the client **MUST** assume `"algo": "ethash"` - optional `extranonce` (hex) : a starting search segment nonce assigned by server to clients so they possibly do not overlap their search segments. If server wants to "cancel" a previously set extranonce it must pass this member valued as an empty string. Whenever the server detects that one, or two, or three or four values change within the session, the server will issue a notification with one, or two or three or four members in the `param` object. For this reason on each **new** session the server **MUST** pass all four members. As a consequence the miner is instructed to adapt those values on **next** job which gets notified. The new `algo` member is defined to be prepared for possible presence of algorithm variants to ethash, namely ethash1a or ProgPow. Pools providing multicoin switching will take care to send a new `mining.set` to miners before pushing any job after a switch. The client which can't support the data provided in the `mining.set` notification **MAY** close connection or stay idle till new values satisfy it's configuration (see `mining.noop`). All client's implementations **MUST** be prepared to accept new extranonces during the session: unlike in EthereumStratum/1.0.0 the optional client advertisement `mining.extranonce.subscribe` is now implicit and mandatory. The miner receiving the `extranonce` **MUST** initialize the search segment for next job resizing the extranonce to a hex of 16 bytes thus appending as many zeroes as needed. Extranonce "af4c" means "_search segment of next jobs starts from 0xaf4c000000000000_" If `extranonce` is valued to an empty string, or it's never been set within the session scope, the client is free pick any starting point of it's own search segment on subsequent `mining.notify` jobs. ### A detail of "extranonce" Miners connected to a pool might likely process the very same nonces thus wasting a lot of duplicate jobs. A `nonce` is any valid number which, applied to algorithm and job specifications, produces a result which is below a certain target. For every job pushed by server to client(s) there are 2^64 possible nonces to test. To be noted that: - Any nonce in the 2^64 has the very same possibility to be the right one. - A certain hashing job can be solved by more than one nonce Every "test" over a number is called a hash. Assuming a miner should receive a job for each block and considering the actual average block time of 15 seconds that would mean a miner should try ``` ( 2^64 / 15 ) / 1T ~ 1,229,782.94 TeraHashes per second ``` This computation capacity is well beyond any miner on the market (including ASICs). For this reason single miners can process only small chunks (segments) of this humongous range. The way miners pick the segments to search on is beyond the scope of this work. Fact is as miners are not coordinated there is no knowledge - for a single miner - of segments picked by other miners. Extranonce concept is here to mitigate this possibility of duplicate jobs charging the server (the work provider) to give miners, at the maximum possible extent, different segments to search on. Giving the above assumptions we can depict a nonce as any number in the hex range: ``` Min 0x0000000000000000 Max 0xffffffffffffffff ``` _the prefix 0x is voluntarily inserted here only to give a better visual representation_. The `extranonce` is, at it's basics, the message of the server saying the client "_I give you the first number to start search from_". More in detail the `extranonce` is the leftmost part of that number. Assume a pool notifies the client the usage of extranonce `ab5d` this means the client will see it's search segment narrowed as ``` Min 0xab5d000000000000 Max 0xab5dffffffffffff ``` Pushing an extranonce of 4 bytes (like in the example) will give pool the possibility to separate segment 65535 different miners ( or if you prefer 0xffff miners ) while leaving the miner still a segment of 2^48 possible nonces to search on. Recalculating, as above, the computation capacity needed to search this segment we get ``` ( 2^48 / 15 ) / 1T ~ 18.76 TeraHashes per second ``` Which is still a wide segment where miners can randomly (or using other ergodic techniques) pick their internal search segments. Extranonce **MUST** be passed with all relevant bytes (no omission of left zeroes) for a specific reason. Assume an extranonce of "01ac" : it has the same decimal value of "1ac" but the number of bytes changes thus changing available search segment ``` When "01ac" When "1ac" Segment is Segment is Min 0x01ac000000000000 Min 0x1ac0000000000000 Max 0x01acffffffffffff Max 0x1acfffffffffffff ``` As you can see resulting segments are quite different This all said pools (server), when making use of extranonce, **MUST** observe a maximum length of 6 bytes (hex). ### Jobs notification When available server will dispatch jobs to connected miners issuing a `mining.notify` notification. ```json { "method": "mining.notify", "params": [ "bf0488aa", "6526d5" "645cf20198c2f3861e947d4f67e3ab63b7b2e24dcc9095bd9123e7b33371f6cc", "0" ] } ``` `params` member is made of 4 mandatory elements: - 1st element is jobId as specified by pool. To reduce the amount of data sent over the wire pools **SHOULD** keep their job IDs as concise as possible. Pushing a Job id which is identical to headerhash is a bad practice and is highly discouraged. - 2nd element is the hex number of the block id - 3rd element is the headerhash. - 4th element is an hex boolean indicating whether or not eventually found shares from previous jobs will be accounted for sure as stale. ### Solution submission When a miner finds a solution for a job he is mining on it sends a `mining.submit` request to server. ```json { "id": 31, "method": "mining.submit", "params": [ "bf0488aa", "68765fccd712", "w-123" ] } ``` First element of `params` array is the jobId this solution refers to (as sent in the `mining.notify` message from the server). Second element is the `miner nonce` as hex. Third element is the token given to the worker previous `mining.authorize` request. Any `mining.submit` request bound to a worker which was not successfully authorized - i.e. the token does not exist in the session - **MUST** be rejected. You'll notice in the sample above the `miner nonce` is only 12 bytes wide (should be 16). Why? That's because in the previous `mining.set` the server has set an `extranonce` of `af4c`. This means the full nonce is `af4c68765fccd712` In presence of extranonce the miner **MUST** submit only the chars to append to the extranonce to build the final hex value. If no extranonce is set for the session or for the work the miner **MUST** send all 16 bytes. It's server duty to keep track of the tuples `job ids <-> extranonces` per session. When the server receives this request it either responds success using the short form ```json {"id": 31} ``` or, in case of any error or condition with a detailed error object ```json { "id": 31, "error": { "code": 404, "message" : "Job not found" } } ``` Client **should** treat errors as "soft" errors (stales) or "hard" (bad nonce computation, job not found etc.). Errors in 5xx range are server errors and suggest the miner to abandon the connection and switch to a failover. ### Hashrate Most pools offer statistic information, in form of graphs or by API calls, about the calculated hashrate expressed by the miner while miners like to compare this data with the hashrate they read on their devices. Communication about parties of these information have never been coded in Stratum and most pools adopt the method from getWork named `eth_submitHashrate`. In this document we propose an official implementation of the `mining.hashrate` request. This method behaves differently when issued from client or from server. #### Client communicates it's hashrate to server. ```json { "id" : 16, "method": "mining.hashrate", "params": [ "500000", "w-123" ] } ``` where `params` is an array made of two elements: the first is a hexadecimal string representation (32 bytes) of the hashrate the miner reads on it's devices and the latter is the authorization token issued to worker this hashrate is refers to (see above for `mining.authorization`). Server **MUST** respond back with either an aknowledgment message ```json {"id": 16 } ``` Optionally the server can reply back reporting it's findings about calculated hashrate **for the same worker**. ```json { "id": 16, "result" : [ "4f0000", "w-123" ] } ``` In case of errors - for example when the client submits too frequently - with ```json { "id": 16, "error" : { "code": 220, "message": "Enhance your calm. Too many requests" } } ``` #### Server communicates hashrate to client Optionally the server can **notify** client about it's overall performance (according to schedule set on server) with a `mining.hashrate` notification composed like this ```json { "method": "mining.hashrate", "params": { "interval": 60, "hr": "500000", "accepted": [3692,20], "rejected": 0, } } ``` Where `params` is an object which holds these members for values of the **whole session**: - `interval` (number) the width, in minutes, of the observation window. "_in the last x minutes we calculated ..._" - `hr` (hex) representation of the hashrate the pool has calculated for the miner - `accepted` is an array of two number elements : the first is the overall count of accepted shares and the second is the number of stale shares. The array must be interpreted as "total accepted of which x are stale" - `rejected` (number) the overall number of rejected shares The client will eventually take internal actions to reset/restart it's workers. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 09 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1571 https://eips.ethereum.org/EIPS/eip-1571 contenthash field for ENS Standards Track/ERC ## Abstract This EIP introduces the new `contenthash` field for ENS resolvers, allowing for a better defined system of mapping names to network and content addresses. Additionally the `content` and `multihash` fields are deprecated. ## Motivation Multiple applications including [Metamask](https://metamask.io/) and mobile clients such as [Status](https://status.im) have begun resolving ENS names to content hosted on distributed systems such as [IPFS](https://ipfs.io/) and [Swarm](https://swarm-guide.readthedocs.io). Due to the various ways content can be stored and addressed, a standard is required so these applications know how to resolve names and that domain owners know how their content will be resolved. The `contenthash` field allows for easy specification of network and content addresses in ENS. ## Specification The field `contenthash` is introduced, which permits a wide range of protocols to be supported by ENS names. Resolvers supporting this field MUST return `true` when the `supportsInterface` function is called with argument `0xbc1c58d1`. The fields `content` and `multihash` are deprecated. The value returned by `contenthash` MUST be represented as a machine-readable [multicodec](https://github.com/multiformats/multicodec). The format is specified as follows: ``` <protoCode uvarint><value []byte> ``` protoCodes and their meanings are specified in the [multiformats/multicodec](https://github.com/multiformats/multicodec) repository. The encoding of the value depends on the content type specified by the protoCode. Values with protocodes of 0xe3 and 0xe4 represent IPFS and Swarm content; these values are encoded as v1 [CIDs](https://github.com/multiformats/cid) without a base prefix, meaning their value is formatted as follows: ``` <protoCode uvarint><cid-version><multicodec-content-type><multihash-content-address> ``` When resolving a `contenthash`, applications MUST use the protocol code to determine what type of address is encoded, and resolve the address appropriately for that protocol, if supported. ### Example #### IPFS Input data: ``` storage system: IPFS (0xe3) CID version: 1 (0x01) content type: dag-pb (0x70) hash function: sha2-256 (0x12) hash length: 32 bytes (0x20) hash: 29f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f ``` Binary format: ``` 0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f ``` Text format: ``` ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4 ``` ### Swarm Input data: ``` storage system: Swarm (0xe4) CID version: 1 (0x01) content type: swarm-manifest (0xfa) hash function: keccak256 (0x1b) hash length: 32 bytes (0x20) hash: d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 ``` Binary format: ``` 0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 ``` Text format: ``` bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 ``` Example usage with swarm hash: ``` $ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 > e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 ``` ### Fallback In order to support names that have an IPFS or Swarm hash in their `content` field, a grace period MUST be implemented offering those name holders time to update their names. If a resolver does not support the `multihash` interface, it MUST be checked whether they support the `content` interface. If they do, the value of that field SHOULD be treated in a context dependent fashion and resolved. This condition MUST be enforced until at least March 31st, 2019. ### Implementation To support `contenthash`, a new resolver has been developed and can be found [here](https://github.com/ensdomains/resolvers/blob/master/contracts/PublicResolver.sol), you can also find this smart contract deployed on: * Mainnet : [0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3](https://etherscan.io/address/0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3) * Ropsten : [0xde469c7106a9fbc3fb98912bb00be983a89bddca](https://ropsten.etherscan.io/address/0xde469c7106a9fbc3fb98912bb00be983a89bddca) There are also implementations in multiple languages to encode and decode `contenthash`: * [JavaScript](https://github.com/pldespaigne/content-hash) * [Python](https://github.com/filips123/ContentHashPy) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 13 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1577 https://eips.ethereum.org/EIPS/eip-1577 Non-wallet usage of keys derived from BIP-32 trees Standards Track/ERC https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817 ## Abstract BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets. ## Motivation Applications interacting with the blockchain often make use of additional, non-blockchain technologies to perform the task they are designed for. For privacy and security sensitive mechanisms, sets of keys are needed. Reusing keys used for wallets can prove to be insecure, while keeping completely independent keys make backup and migration of the full set of credentials more complex. Defining a separate (from BIP44 compliant wallets) derivation branch allows combining the security of independent keys with the convenience of having a single piece of information which needs to be backup or migrated. ## Specification ### Path levels We define the following levels in BIP32 path: ```m / purpose' / coin_type' / subpurpose' / key_type' / key_index``` Apostrophe in the path indicates that BIP32 hardened derivation is used. This structure follows the [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) recommendations and its [amendments for non-Bitcoin usage](https://github.com/bitcoin/bips/pull/523/files). Each level has a special meaning, described in the chapters below. ### Purpose/Coin Type/Subpurpose This part is constant and set to ```m / 43' / 60' / 1581'```, meaning BIP 43 -> Ethereum -> This EIP. All subtrees under this prefix are the scope of this EIP. ### Key type Describes the purpose for which the key is being used. Key types should be generic. "Instant messaging" is a good example whereas "Whisper" is not. The reason is that you want to be able to use the same identity across different services. Key types are defined at: TBD Hardened derivation is used at this level. ### Key index The key index is a field of variable length identifying a specific key. In its simplest case, it is a number from 0 to 2^31-1. If a larger identifier is desired (for example representing a hash or a GUID), the value must be split across several BIP32 nesting levels, most significant bit first and left aligned, bit-padded with 0s if needed. All levels, except the last one must used hardened key derivation. The last level must use public derivation. This means that every level can carry 31-bit of the identifier to represent. As an example, let's assume we have a key with key type 4' and a key_index representing a 62-bit ID represented as hexadecimal 0x2BCDEFFEDCBAABCD the complete keypath would be ```m / 43' / 60' / 1581' / 4' / ‭1469833213‬' / ‭1555737549‬ ```. If you are using random identifiers, it might be convenient to generate a conventional GUID, for example 128-bit just fix the value of the most significant bit of each 32-bit word to 1 for all of them, except the last one which will be 0. ## Rationale The structure proposed above follows the BIP43 generic structure and is similar to the widely adopted BIP44 specification. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 13 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1581 https://eips.ethereum.org/EIPS/eip-1581 Hardfork Meta: Ethereum ProgPoW Meta/ ## Abstract This meta-EIP specifies the changes included in the alternative Ethereum hardfork named Ethereum ProgPoW. ## Specification - Codename: Ethereum ProgPoW - Aliases: N/A - Activation: - `Block >= 7280000` on the Ethereum mainnet - Included EIPs: - [EIP-1057](/EIPS/eip-1057): ProgPoW, a Programmatic Proof-of-Work ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 16 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1588 https://eips.ethereum.org/EIPS/eip-1588 Address and ERC20-compliant transfer rules Standards Track/ERC https://github.com/ethereum/EIPs/issues/1597 ## Simple Summary We propose a standard and an interface to define transfer rules, in the context of ERC20 tokens and possibly beyond. A rule can act based on sender, destination and amount, and is triggered (and rejects the transfer) according to any required business logic. To ease rule reusability and composition, we also propose an interface and base implementation for a rule engine. ## Abstract This standard proposal should answer the following challenges: - Enable integration of rules with interacting platforms such as exchanges, decentralized wallets and DApps. - Externale code and storage, improve altogether reusability, gas costs and contracts' memory footprint. - Highlight contract behavior and its evolution, in order to ease user interaction with such contract. If these challenges are answered, this proposal will provide a unified basis for transfer rules and hopefully address the transfer restriction needs of other EIPs as well, e.g. [EIP-902](/EIPS/eip-902), [EIP-1066](/EIPS/eip-1066) and [EIP-1175](/EIPS/eip-1175). This document proposes specifications for a standard of **transfer rules** and interfaces to both the rules and the rule engine, which was made to be inherited by a token, but may have a much broader scope in the authors' opinion. The last section of this document illustrates the proposal with a rule template and links to rule implementations. ## Motivation ERC20 was designed as a standard interface allowing any token on Ethereum to be handled by other applications: from wallets to decentralized exchanges. This has been extremely powerful, but future developments in the industry of tokenization are bringing new challenges. For example it is already hard to know exactly why an ERC20 transfer failed, and it will become even harder when many tokens add their own transfer rules to the mix; we propose that it should be trivial to determine before a tx is sent, whether the transfer should turn out valid or invalid, and why (unless conditions change in the meantime obviously). On the other hand, if the rules were changed, it should also be easily detected, so that the interacting party knows it must adjust its expectations or model. ## Specification We define below an interface for a rule. Rules are meant to be as simple as possible, to limit gas expenditure, since that logic will be executed on every transfer. Another reason for keeping rules simple and short, and strive for atomicity, is to facilitate both composition and interpretation of rejected transfers. By knowing which rule was triggered, we obtain a clear picture of the reason for rejection. The engine we propose executes all the rules defined by its owner, on every transfer and it is easy to add and remove rules individually, although we have chosen to use quite a raw rule update method, to save on deployment costs, which are often tight when it comes to token smart contracts. Rules are deployed on the blockchain as individual smart contracts, and called upon by the rule engine they were attached to. But any third party, for example an exchange preparing a cashout for a customer, can very cheaply query the rule engine of the token, or a single rule directly, to verify the validity of a transfer before execution, so as to never get a rejected transaction. ## Rule interface `IRule` interface should provide a way to validate if an address or a transfer is valid. If one of these two methods is not applicable, it can simply be made to return true systematically. If any parameter of `isTransferValid` is not needed, its name should be commented out with `/* */`. ```js pragma solidity ^0.4.25; interface IRule { function isAddressValid(address _address) external view returns (bool); function isTransferValid(address _from, address _to, uint256 _amount) external view returns (bool); } ``` ## WithRules interface `WithRules` interface describes the integration of rules to a rule engine. Developers may choose to not implement this interface if their code will only deal with one rule, or if it is not desirable to update the rules. The rules ordering must be thought through carefully. Rules which are cheaper to validate or have a higher chance to break should be put first to reduce global gas expenditure, then business logic should guide the ordering of rules. That is why rules for a given context should be defined as a whole and not individually. ```js pragma solidity ^0.4.25; import "./IRule.sol"; interface IWithRules { function ruleLength() public view returns (uint256); function rule(uint256 _ruleId) public view returns (IRule); function validateAddress(address _address) public view returns (bool); function validateTransfer(address _from, address _to, uint256 _amount) public view returns (bool); function defineRules(IRule[] _rules) public; event RulesDefined(uint256 count); } ``` ## WithRules implementation We also propose a simple implementation of the rule engine, available [here](https://github.com/MtPelerin/MtPelerin-protocol/blob/master/contracts/rule/WithRules.sol). It has been kept minimal both to save on gas costs on each transfer, and to reduce the deployment cost overhead for the derived smart contract. On top of implementing the interface above, this engine also defines two modifiers (`whenAddressRulesAreValid`and `whenTransferRulesAreValid`), which can be used throughout the token contract to restrict `transfer()`, `transferFrom` and any other function that needs to respect either a simple whitelist or complex transfer rules. ## Integration To use rules within a token is as easy as having the token inherit from WithRules, then writing rules according to the IRule interface and deploying each rule individually. The token owner can then use `defineRules()` to attach all rules in the chosen order, within a single transaction. Below is a template for a rule. ```solidity import "../interface/IRule.sol"; contract TemplateRule is IRule { // state vars for business logic constructor(/* arguments for init */) public { // initializations } function isAddressValid(address _from) public view returns (bool) { boolean isValid; // business logic return isValid; } function isTransferValid( address _from, address _to, uint256 _amount) public view returns (bool) { boolean isValid; // business logic return isValid; } } ``` *** Notes *** The MPS (Mt Pelerin's Share) token is the current live implementation of this standard. Other implementations may be written with different trade-offs: from gas savings to improved security. #### Example of rules implementations - [YesNo rule](https://github.com/MtPelerin/MtPelerin-protocol/tree/master/contracts/rule/YesNoRule.sol): Trivial rule used to demonstrate both a rule and the rule engine. - [Freeze rule](https://github.com/MtPelerin/MtPelerin-protocol/tree/master/contracts/rule/FreezeRule.sol): This rule allows to prevent any transfer of tokens to or from chosen addresses. A smart blacklist. - [Lock rule](https://github.com/MtPelerin/MtPelerin-protocol/tree/master/contracts/rule/LockRule.sol): Define a global transfer policy preventing either sending or receiving tokens within a period of time. Exceptions may be granted to some addresses by the token admin. A smart whitelist. - [User Kyc Rule](https://github.com/MtPelerin/MtPelerin-protocol/tree/master/contracts/rule/UserKycRule.sol): Rule example relying on an existing whitelist to assert transfer and addresses validity. It is a good example of a rule that completely externalizes it's tasks. #### Example implementations are available at - [Mt Pelerin Bridge protocol rules implementation](https://github.com/MtPelerin/MtPelerin-protocol/tree/master/contracts/rule) - [Mt Pelerin Token with rules](https://github.com/MtPelerin/MtPelerin-protocol/blob/master/contracts/token/component/TokenWithRules.sol) ## History Historical links related to this standard: - The first regulated tokenized share issued by Mt Pelerin (MPS token) is using an early version of this proposal: https://www.mtpelerin.com/blog/world-first-tokenized-shares The rule engine was updated several times, after the token issuance and during the tokensale, to match changing business and legal requirements, showcasing the solidity and flexibility of the rule engine. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). External references outside this repository will have their own specific copyrights. Fri, 09 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1592 https://eips.ethereum.org/EIPS/eip-1592 Gas stations network Standards Track/ERC https://github.com/yoav-tabookey/EIPs/issues/1 ## Simple Summary Make smart contracts (e.g. dapps) accessible to non-ether users by allowing contracts to accept "[collect-calls](https://en.wikipedia.org/wiki/Collect_call)", paying for incoming calls. Let contracts "listen" on publicly accessible channels (e.g. web URL or a whisper address). Incentivize nodes to run "gas stations" to facilitate this. Require no network changes, and minimal contract changes. ## Abstract Communicating with dapps currently requires paying ETH for gas, which limits dapp adoption to ether users. Therefore, contract owners may wish to pay for the gas to increase user acquisition, or let their users pay for gas with fiat money. Alternatively, a 3rd party may wish to subsidize the gas costs of certain contracts. Solutions such as described in [EIP-1077](/EIPS/eip-1077) could allow transactions from addresses that hold no ETH. The gas stations network is an [EIP-1077](/EIPS/eip-1077) compliant effort to solve the problem by creating an incentive for nodes to run gas stations, where gasless transactions can be "fueled up". It abstracts the implementation details from both the dapp maintainer and the user, making it easy to convert existing dapps to accept "collect-calls". The network consists of a single public contract trusted by all participating dapp contracts, and a decentralized network of relay nodes (gas stations) incentivized to listen on non-ether interfaces such as web or whisper, pay for transactions and get compensated by that contract. The trusted contract can be verified by anyone, and the system is otherwise trustless. Gas stations cannot censor transactions as long as there's at least one honest gas station. Attempts to undermine the system can be proven on-chain and offenders can be penalized. ## Motivation * Increase user adoption of smart contracts by: * Removing the user hassle of acquiring ETH. Transactions are still paid by ETH but costs can be borne by the dapp or paid by the user through other means. * Removing the need to interact directly with the blockchain, while maintaining decentralization and censorship-resistance. Contracts can "listen" on multiple public channels, and users can interact with the contracts through common protocols that are generally permitted even in restrictive environments. * Ethereum nodes get a revenue source without requiring mining equipment. The entire network benefits from having more nodes. * No protocol changes required. The gas station network is self-organized via a smart contract, and dapps interact with the network by implementing an interface. ## Specification The system consists of a `RelayHub` singleton contract, participating contracts inheriting the `RelayRecipient` contract, a decentralized network of `Relay` nodes, a.k.a. Gas Stations, and user applications (e.g. mobile or web) interacting with contracts via relays. Roles of the `RelayHub`: * Maintain a list of active relays. Senders select a `Relay` from this list for each transaction. The selection process is discussed below. * Mediate all communication between relays and contracts. * Provide contracts with trusted versions of the real msg.sender and msg.data. * Hold ETH stakes placed by relays. A minimum stake size is enforced. Stake can be withdrawn after a relay unregisters and waits for a cooldown period. * Hold ETH prepayments made by contracts and use them to compensate relays. * Penalize provably-offensive relays by giving their stakes to an address providing the proof, thus keeping relays honest. * Provide a free way for relays to know whether they'll be compensated for a future transaction. Roles of a `Relay` node: * Maintain a hot wallet with a small amount of ETH, to pay for gas. * Provide a public interface for user apps to send gasless transactions via channels such as https or whisper. * Publish it's public interfaces and its price (as a multiplier of the actual transaction gas cost) in `RelayHub`. * Optionally monitor reverted transactions of other relays through RelayHub, catching offending relays and claiming their stakes. This can be done by anyone, not just a relay. Implementing a `RelayRecipient` contract: * Know the address of `RelayHub` and trust it to provide information about the transaction. * Maintain a small balance of ETH gas prepayment deposit in `RelayHub`. Can be paid directly by the `RelayRecipient` contract, or by the dapp's owner on behalf of the `RelayRecipient` address. The dapp owner is responsible for ensuring sufficient balance for the next transactions, and can stop depositing if something goes wrong, thus limiting the potential for abuse of system bugs. In DAO usecases it will be up to the DAO logic to maintain a sufficient deposit. * Use `getSender()` and `getMessageData()` instead of `msg.sender` and `msg.data`, everywhere. `RelayRecipient` provides these functions and gets the information from `RelayHub`. * Implement a `acceptRelayedCall(address relay, address from, bytes memory encodedFunction, uint gasPrice, uint transactionFee, bytes memory approval)` view function that returns **zero** if and only if it is willing to accept a transaction and pay for it. `acceptRelayedCall` is called by `RelayHub` as a view function when a `Relay` inquires it, and also during the actual transaction. Transactions are reverted if **non-zero**, and `Relay` only gets compensated for transactions (whether successful or reverted) if `acceptRelayedCall` returns **zero**. Some examples of `acceptRelayedCall()` implementations: * Whitelist of trusted dapp members. * Balance sheet of registered users, maintained by the dapp owner. Users pay the dapp with a credit card or other non-ETH means, and are credited in the `RelayRecipient` balance sheet. Users can never cost the dapp more than they were credited for. * A dapp can provide off-chain a signed message called `approval` to a transaction sender and validate it. * Whitelist of known transactions used for onboarding new users. This allows certain anonymous calls and is subject to Sybil attacks. Therefore it should be combined with a restricted gasPrice, and a whitelist of trusted relays, to reduce the incentive for relays to create bogus transactions and rob the dapp's prepaid gas deposit. Dapps allowing anonymous onboarding transactions might benefit from registering their own `Relay` and accepting anonymous transactions only from that `Relay`, whereas other transactions can be accepted from any relay. Alternatively, dapps may use the balance sheet method for onboarding as well, by applying the methods suggested in the attacks/mitigations section below. * Implement `preRelayedCall(address relay, address from, bytes memory encodedFunction, uint transactionFee) returns (bytes32)`. This method is called before a transaction is relayed. By default, it does nothing. * Implement `postRelayedCall(ddress relay, address from, bytes memory encodedFunction, bool success, uint usedGas, uint transactionFee, bytes32 preRetVal)`. This method is called after a transaction is relayed. By default, it does nothing. These two methods can be used to charge the user in dapp-specific manner. Glossary of terms used in the processes below: * `RelayHub` - the RelayHub singleton contract, used by everyone. * `Recipient` - a contract implementing `RelayRecipient`, accepting relayed transactions from the RelayHub contract and paying for the incoming transactions. * `Sender` - an external address with a valid key pair but no ETH to pay for gas. * `Relay` - a node holding ETH in an external address, listed in RelayHub and relaying transactions from Senders to RelayHub for a fee. ![Sequence Diagram](/assets/eip-1613/sequence.png) The process of registering/refreshing a `Relay`: * Relay starts listening as a web app (or on some other communication channel). * If starting for the first time (no key yet), generate a key pair for Relay's address. * If Relay's address doesn't hold sufficient funds for gas (e.g. because it was just generated), Relay stays inactive until its owner funds it. * Relay's owner funds it. * Relay's owner sends the required stake to `RelayHub` by calling `RelayHub.stake(address relay, uint unstakeDelay)`. * `RelayHub` puts the `owner` and `unstake delay` in the relays map, indexed by `relay` address. * Relay calls `RelayHub.registerRelay(uint transactionFee, string memory url)` with the relay's `transaction fee` (as a multiplier on transaction gas cost), and a URL for incoming transactions. * `RelayHub` ensures that Relay has a sufficient stake. * `RelayHub` puts the `transaction fee` in the relays map. * `RelayHub` emits an event, `RelayAdded(Relay, owner, transactionFee, relayStake, unstakeDelay, url)`. * Relay starts a timer to perform a `keepalive` transaction every 6000 blocks. * `Relay` goes to sleep and waits for signing requests. The process of sending a relayed transaction: * `Sender` selects a live `Relay` from RelayHub's list by looking at `RelayAdded` events from `RelayHub`, and sorting based on its own criteria. Selection may be based on a mix of: * Relay published transaction fees. * Relay stake size and lock-up time. * Recent relay transactions (visible through `TransactionRelayed` events from `RelayHub`). * Optionally, reputation/blacklist/whitelist held by the sender app itself, or its backend, on per-app basis (not part of the gas stations network). * Sender prepares the transaction with Sender's address, the recipient address, the actual transaction data, Relay's transaction fee, gas price, gas limit, its current nonce from `RelayHub.nonces`, RelayHub's address, and Relay's address, and then signs it. * Sender verifies that `RelayHub.balances[recipient]` holds enough ETH to pay Relay's fee. * Sender verifies that `Relay.balance` has enough eth to send the transaction * Sender reads the Relay's current `nonce` value and decides on the `max_nonce` parameter. * Sender sends the signed transaction amd metadata to Relay's web interface. * `Relay` wraps the transaction with a transaction to `RelayHub`, with zero ETH value. * `Relay` signs the wrapper transaction with its key in order to pay for gas. * `Relay` verifies that: * The transaction's recipient contract will accept this transaction when submitted, by calling `RelayHub.canRelay()`, a view function, which checks the recipient's `acceptRelayedCall`, also a view function, stating whether it's willing to accept the charges). * The transaction nonce matches `RelayHub.nonces[sender]`. * The relay address in the transaction matches Relay's address. * The transaction's recipient has enough ETH deposited in `RelayHub` to pay the transaction fee. * Relay has enough ETH to pay for the gas required by the transaction. * Value of `max_nonce` is higher than current Relay's `nonce` * If any of Relay's checks fail, it returns an error to sender, and doesn't proceed. * Relay submits the signed wrapped transaction to the blockchain. * Relay immediately returns the signed wrapped transaction to the sender. This step is discussed below, in attacks/mitigations. * `Sender` receives the wrapped transaction and verifies that: * It's a valid relay call to `RelayHub`. from Relay's address. * The transaction's ethereum nonce matches Relay's current nonce. * The transaction's ethereum nonce is lower than or equal to `max_nonce`. * `Relay` is sufficiently funded to pay for it. * The wrapped transaction is valid and signed by `sender`. * Recipient contract has sufficient funds in `RelayHub.balances` to pay for Relay's fee as stated in the transaction. * If any of sender's checks fails, it goes back to selecting a new Relay. Sender may also file a report on the unresponsive relay to its backend or save it locally, to down-sort this relay in future transactions. * `Sender` may also submit the raw wrapped transaction to the blockchain without paying for gas, through any Ethereum node. This submission is likely ignored because an identical transaction is already in the network's pending transactions, but no harm in putting it twice, to ensure that it happens. This step is not strictly necessary, for reasons discussed below in attacks/mitigations, but may speed things up. * `Sender` monitors the blockchain, waiting for the transaction to be mined. The transaction was verified, with Relay's current nonce, so mining must be successful unless Relay submitted another (different) transaction with the same nonce. If mining fails due to such attack, sender may call `RelayHub.penalizeRepeatedNonce` through another relay, to collect his reward and burn the remainder of the offending relay's stake, and then go back to selecting a new Relay for the transaction. See discussion in the attacks/mitigations section below. * `RelayHub` receives the transaction: * Records `gasleft()` as `initialGas` for later payment. * Verifies the transaction is sent from a registered relay. * Verifies that the signature of the internal transaction matches its stated origin (sender's key). * Verifies that the relay address written in the transaction matches msg.sender. * Verifies that the transaction's `nonce` matches the stated origin's nonce in `RelayHub.nonces`. * Calls recipient's `acceptRelayedCall` function, asking whether it's going to accept the transaction. If not, the `TransactionRelayed` will be emitted with status `CanRelayFailed`, and `chargeOrCanRelayStatus` will contain the return value of `acceptRelayedCall`. In this case, Relay doesn't get paid, as it was its responsibility to check `RelayHub.canRelay` before releasing the transaction. * Calls recipient's `preRelayedCall` function. If this call reverts the `TransactionRelayed` will be emitted with status `PreRelayedFailed`. * Sends the transaction to the recipient. If this call reverts the `TransactionRelayed` will be emitted with status `RelayedCallFailed`. When passing gas to `call()`, enough gas is preserved by `RelayHub`, for post-call handling. Recipient may run out of gas, but `RelayHub` never does. `RelayHub` also sends sender's address at the end of `msg.data`, so `RelayRecipient.getSender()` will be able to extract the real sender, and trust it because the transaction came from the known `RelayHub` address. * Recipient contract handles the transaction. * `RelayHub` calls recipient's `postRelayedCall`. * `RelayHub` checks call's return value of call, and emits `TransactionRelayed(address relay, address from, address to, bytes4 selector, uint256 status, uint256 chargeOrCanRelayStatus)`. * `RelayHub` increases `RelayHub.nonces[sender]`. * `RelayHub` transfers ETH balance from recipient to `Relay.owner`, to pay the transaction fee, based on the measured transaction cost. Note on relay payment: The relay gets paid for actual gas used, regardless of whether the recipient reverted. The only case where the relay sustains a loss, is if `canRelay` returns non-zero, since the relay was responsible to verify this view function prior to submitting. Any other revert is caught and paid for. See attacks/mitigations below. * `Relay` keeps track of transactions it sent, and waits for `TransactionRelayed` events to see the charge. If a transaction reverts and goes unpaid, which means the recipient's `acceptRelayedCall()` function was inconsistent, `Relay` refuses service to that recipient for a while (or blacklists it indefinitely, if it happens often). See attacks/mitigations below. The process of winding a `Relay` down: * Relay's owner (the address that initially funded it) calls `RelayHub.removeRelayByOwner(Relay)`. * `RelayHub` ensures that the sender is indeed Relay's owner, then removes `Relay`, and emits `RelayRemoved(Relay)`. * `RelayHub` starts the countdown towards releasing the owner's stake. * `Relay` receives its `RelayRemoved` event. * `Relay` sends all its remaining ETH to its owner. * `Relay` shuts down. * Once the owner's unstake delay is over, owner calls `RelayHub.unstake()`, and withdraws the stake. ## Rationale The rationale for the gas stations network design is a combination of two sets of requirements: Easy adoption, and robustness. For easy adoption, the design goals are: * No network changes. * Minimal changes to contracts, apps and frameworks. The robustness requirement translates to decentralization and attack resistance. The gas stations network is decentralized, and we have to assume that any entity may attack other entities in the system. Specifically we've considered the following types of attacks: * Denial-of-service attacks against individual senders, i.e. transactions censorship. * Denial-of-service and financial attacks against individual relays. * Denial-of-service and financial attacks against individual contracts. * Denial-of-service attacks against the entire network, either by attacking existing entities, or by introducing any number of malicious entities. #### Attacks and mitigations ##### Attack: Relay attempts to censor a transaction by not signing it, or otherwise ignoring a user request. Relay is expected to return the signed transaction to the sender, immediately. Sender doesn't need to wait for the transaction to be mined, and knows immediately whether it's request has been served. If a relay doesn't return a signed transaction within a couple of seconds, sender cancels the operation, drops the connection, and switches to another relay. It also marks Relay as unresponsive in its private storage to avoid using it in the near future. Therefore, the maximal damage a relay can cause with such attack, is a one-time delay of a couple of seconds. After a while, senders will avoid it altogether. ##### Attack: Relay attempts to censor a transaction by signing it, returning it to the sender, but never putting it on the blockchain. This attack will backfire and not censor the transaction. The sender can submit the transaction signed by Relay to the blockchain as a raw transaction through any node, so the transaction does happen, but Relay may be unaware and therefore be stuck with a bad nonce which will break its next transaction. ##### Attack: Relay attempts to censor a transaction by signing it, but publishing a different transaction with the same nonce. Reusing the nonce is the only DoS performed by a Relay, that cannot be detected within a couple of seconds during the http request. It will only be detected when the malicious transaction with the same nonce gets mined and triggers the `RelayHub.TransactionRelayed` event. However, the attack will backfire and cost Relay its entire stake. Sender has a signed transaction from Relay with nonce N, and also gets a mined transaction from the blockchain with nonce N, also signed by Relay. This proves that Relay performed a DoS attack against the sender. The sender calls `RelayHub.penalizeRepeatedNonce(bytes transaction1, bytes transaction2)`, which verifies the attack, confiscates Relay's stake, and sends half of it to the sender who delivered the `penalizeRepeatedNonce` call. The other half of the stake is burned by sending it to `address(0)`. Burning is done to prevent cheating relays from effectively penalizing themselves and getting away without any loss. The sender then proceeds to select a new relay and send the original transaction. The result of such attack is a delay of a few blocks in sending the transaction (until the attack is detected) but the relay gets removed and loses its entire stake. Scaling such attack would be prohibitively expensive, and actually quite profitable for senders and honest relays. ##### Attack: Relay attempts to censor a transaction by signing it, but using a nonce higher than it's current nonce. In this attack, the Relay did create and return a perfectly valid transaction, but it will not be mined until this Relay fills the gap in the nonce with 'missing' transactions. This may delay the relaying of some transactions indefinitely. In order to mitigate that, the sender includes a `max_nonce` parameter with it's signing request. It is suggested to be higher by 2-3 from current nonce, to allow the relay process several transactions. When the sender receives a transaction signed by a Relay he validates that the nonce used is valid, and if it is not, the client will ignore the given relay and use other relays to relay given transaction. Therefore, there will be no actual delay introduced by such attack. ##### Attack: Dapp attempts to burn relays funds by implementing an inconsistent acceptRelayedCall() and using multiple sender addresses to generate expensive transactions, thus performing a DoS attack on relays and reducing their profitability. In this attack, a contract sets an inconsistent acceptRelayedCall (e.g. return zero for even blocks, nonzero for odd blocks), and uses it to exhaust relay resources through unpaid transactions. Relays can easily detect it after the fact. If a transaction goes unpaid, the relay knows that the recipient contract's acceptRelayedCall has acted inconsistently, because the relay has verified its view function before sending the transaction. It might be the result of a rare race condition where the contract's state has changed between the view call and the transaction, but if it happens too frequently, relays will blacklist this contract and refuse to serve transactions to it. Each offending contract can only cause a small damage (e.g. the cost of 2-3 transactions) to a relay, before getting blacklisted. Relays may also look at recipients' history on the blockchain, looking for past unpaid transactions (reverted by RelayHub without pay), and denying service to contracts with a high failure rate. If a contract caused this minor loss to a few relays, all relays will stop serving it, so it can't cause further damage. This attack doesn't scale because the cost of creating a malicious contract is in the same order of magnitude as the damage it can cause to the network. Causing enough damage to exhaust the resources of all relays, would be prohibitively expensive. The attack can be made even more impractical by setting RelayHub to require a stake from dapps before they can be served, and enforcing an unstaking delay, so that attackers will have to raise a vast amount of ETH in order to simultaneously create enough malicious contracts and attack relays. This protection is probably an overkill, since the attack doesn't scale regardless. ##### Attack: User attempts to rob dapps by registering its own relay and sending expensive transactions to dapps. If a malicious sender repeatedly abuses a recipient by sending meaningless/reverted transactions and causing the recipient to pay a relay for nothing, it is the recipient's responsibility to blacklist that sender and have its acceptRelayedCall function return nonzero for that sender. Collect calls are generally not meant for anonymous senders unknown to the recipient. Dapps that utilize the gas station networks should have a way to blacklist malicious users in their system and prevent Sybil attacks. A simple method that mitigates such Sybil attack, is that the dapp lets users buy credit with a credit card, and credit their account in the dapp contract, so acceptRelayedCall() only returns zero for users that have enough credit, and deduct the amount paid to the relay from the user's balance, whenever a transaction is relayed for the user. With this method, the attacker can only burn its own resources, not the dapp's. A variation of this method, for free dapps (that don't charge the user, and prefer to pay for their users transactions) is to require a captcha during user creation in their web interface, or to login with a Google/Facebook account, which limits the rate of the attack to the attacker's ability to open many Google/Facebook accounts. Only a user that passed that process is given credit in RelayRecipient. The rate of such Sybil attack would be too low to cause any real damage. ##### Attack: Attacker attempts to reduce network availability by registering many unreliable relays. Registering a relay requires placing a stake in RelayHub, and the stake can only be withdrawn after the relay is unregistered and a long cooldown period has passed, e.g. a month. Each unreliable relay can only cause a couple of seconds delay to senders, once, and then it gets blacklisted by them, as described in the first attack above. After it caused this minor delay and got blacklisted, the attacker must wait a month before reusing the funds to launch another unreliable relay. Simultaneously bringing up a number of unreliable relays, large enough to cause a noticeable network delay, would be prohibitively expensive due to the required stake, and even then, all those relays will get blacklisted within a short time. ##### Attack: Attacker attempts to replay a relayed transaction. Transactions include a nonce. RelayHub maintains a nonce (counter) for each sender. Transactions with bad nonces get reverted by RelayHub. Each transaction can only be relayed once. ##### Attack: User does not execute the raw transaction received from the Relayer, therefore blocking the execution of all further transactions signed by this relayer The user doesn't really have to execute the raw transaction. It's enough that the user can. The relationship between relay and sender is mutual distrust. The process described above incentivizes the relay to execute the transaction, so the user doesn't need to wait for actual mining to know that the transaction has been executed. Once relay returns the signed transaction, which should happen immediately, the relay is incentivized to also execute it on chain, so that it can advance its nonce and serve the next transaction. The user can (but doesn't have to) also execute the transaction. To understand why the attack isn't viable, consider the four possible scenarios after the signed transaction was returned to the sender: 1. Relay executes the transaction, and the user doesn't. In this scenario the transaction is executed, so no problem. This is the case described in this attack. 2. Relay doesn't execute the transaction, but the user does. Similarly to 1, the transaction is executed, so no problem. 3. Both of them execute the transaction. The transactions are identical in the pending transactions pool, so the transaction gets executed once. No problem. 4. None of them execute the transaction. In this case the transaction doesn't get executed, but the relay is stuck. It can't serve the next transaction with the next nonce, because its nonce hasn't been advanced on-chain. It also can't serve the next transaction with the current nonce, as this can be proven by the user, having two different transactions signed by the same relay, with the same nonce. The user could use this to take the relay's nonce. So the relay is stuck unless it executes the transaction. As this matrix shows, the relay is __always__ incentivized to execute the transaction, once it returned it to the user, in order to end up in #1 or #3, and avoid the risk of #4. It's just a way to commit the relay to do its work, without requiring the user to wait for on-chain confirmation. ## Backwards Compatibility The gas stations network is implemented as smart contracts and external entities, and does not require any network changes. Dapps adding gas station network support remain backwards compatible with their existing apps/users. The added methods apply on top of the existing ones, so no changes are required for existing apps. ## Implementation A working implementation of the [**gas stations network**](https://github.com/tabookey-dev/tabookey-gasless) is being developed by **TabooKey**. It consists of `RelayHub`, `RelayRecipient`, `web3 hooks`, an implementation of a gas station inside `geth`, and sample dapps using the gas stations network. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 18 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1613 https://eips.ethereum.org/EIPS/eip-1613 Attribute Registry Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1616 ## Simple Summary EIP-1616 provides a basic interface for querying a registry for attribute metadata assigned to Ethereum accounts. ## Abstract This EIP contains the following core ideas: 1. Instead of relying directly on the reputation of a claims issuer to assess the veracity of a given claim, trust can be brought up to the level of a registry curator. This registry which we call an "**Attribute Registry**" allows for reduced complexity in implementation since a party needing to verify an attribute can now work with a trusted claims aggregator instead of relying on individual claim providers. 2. Claims are abstracted as standard "attributes" which represent metadata assigned to an account, with claims decoupled from the issuing party. Attributes are registered as a flat `uint256 -> uint256` key-value pair on each account, with the important property that **each attribute type has one canonical value per address**. This property allows for composability of attribute registries and advanced attribute formation. 3. There is a generic method for determining the set of attribute keys or IDs made available by the registry. The standard does not specify requirements or recommendations for how attributes and their values are managed, or what additional metadata may be associated with attributes. It is likely that a standard set of attribute names and metadata schema could be proposed in a separate EIP. Potential advanced uses of attribute registries include: * Encoding complex boolean expressions which combine multiple attributes into a single uint256 key, which is then parsed and evaluated by the registry logic. * Using values associated with an attribute to query additional on-chain or off-chain metadata. * Resolving attribute values by calling into separate attribute registries or other contracts, delegating authority without changing the interface of the registry. ## Motivation This EIP is motivated by the need for contracts and external accounts to be able to verify information about a given address from a single trusted source **without concerning themselves with the particular details of how the information was obtained**, and to do so in as simple a manner as possible. It is also motivated by the desire to promote broad **cross-compatibility and composability** between attribute registries, a property which is amplified by both the simplicity of the interface as well as by the guarantees on uniqueness provided by the proposed standard. Existing EIPs for assigning metadata to an account include EIP-735 and EIP-780, which both allow for multiple claims to be issued on the same address for any given claim topic. This forces verifiers of said metadata to assess the veracity of each claim, taking into account the relative reputation of each claim issuer. It also prescribes a methodology for adding and removing claims, which may not be appropriate for all use cases. This EIP proposes a light-weight abstraction layer for a standard account metadata registry interface. This abstraction layer can sit on top of claims registries like EIP-735 and EIP-780 or others as the attribute registry curator selects trusted data sources. ## Specification The Attribute Registry interface contains four functions, outlined as follows: ```solidity /** * @title EIP-1616 Attribute Registry Standard interface. EIP-165 ID: 0x5f46473f */ interface AttributeRegistryInterface { function hasAttribute(address account, uint256 attributeTypeID) external view returns (bool); function getAttributeValue(address account, uint256 attributeTypeID) external view returns (uint256); function countAttributeTypes() external view returns (uint256); function getAttributeTypeID(uint256 index) external view returns (uint256); } ``` Contracts that comply with the Attribute Registry EIP MUST implement the above interface. As an additional requirement, the ERC-165 interface MUST be included: ```solidity /** * @title EIP-165 interface. EIP-165 ID: 0x01ffc9a7 */ interface EIP-165 { /** * @notice EIP-165 support. Attribute Registry interface ID is 0x5f46473f. * @param _interfaceID The interface identifier, as specified in EIP-165 * @return True for 0x01ffc9a7 & 0x5f46473f, false for unsupported interfaces. */ function supportsInterface(bytes4 _interfaceID) external view returns (bool); } ``` The implementation MUST follow the specifications described below. ### View Functions The view functions detailed below MUST be implemented. #### `hasAttribute` function ```solidity function hasAttribute(address account, uint256 attributeTypeID) external view returns (bool) ``` Check if an attribute has been assigned to a given account on the registry and is currently valid. _**NOTE**_: This function MUST return either true or false - i.e. calling this function MUST NOT cause the caller to revert. Implementations that wish to call into another contract during execution of this function MUST catch any `revert` and instead return `false`. _**NOTE**_: This function MUST return two equal values when performing two directly consecutive function calls with identical `account` and `attributeTypeID` parameters, regardless of differences in the caller's address, the transaction origin, or other out-of-band information. #### `getAttributeValue` function ```solidity function getAttributeValue(address account, uint256 attributeTypeID) external view returns (uint256) ``` Retrieve the `uint256` value of an attribute on a given account on the registry, assuming the attribute is currently valid. _**NOTE**_: This function MUST revert if a directly preceding or subsequent function call to `hasAttribute` with identical `account` and `attributeTypeID` parameters would return false. _**NOTE**_: This function MUST return two equal values when performing two directly consecutive function calls with identical `account` and `attributeTypeID` parameters, regardless of differences in the caller's address, the transaction origin, or other out-of-band information. #### `countAttributeTypes` function ```solidity function countAttributeTypes() external view returns (uint256) ``` Retrieve the total number of valid attribute types defined on the registry. Used alongside `getAttributeTypeID` to determine all of the attribute types that are available on the registry. _**NOTE**_: This function MUST return a positive integer value - i.e. calling this function MUST NOT cause the caller to revert. _**NOTE**_: This function MUST return a value that encompasses all indexes of attribute type IDs whereby a call to `hasAttribute` on some address with an attribute type ID at the given index would return `true`. #### `getAttributeTypeID` function ```solidity function getAttributeTypeID(uint256 index) external view returns (uint256) ``` Retrieve an ID of an attribute type defined on the registry by index. Used alongside `countAttributeTypes` to determine all of the attribute types that are available on the registry. _**NOTE**_: This function MUST revert if the provided `index` value falls outside of the range of the value returned from a directly preceding or subsequent function call to `countAttributeTypes`. It MUST NOT revert if the provided `index` value falls inside said range. _**NOTE**_: This function MUST return an `attributeTypeID` value on *some* index if the same `attributeTypeID` value would cause a given call to `hasAttribute` to return `true` when passed as a parameter. ## Rationale This standard extends the applicability of metadata assignment to those use cases that are not adequately represented by EIP-735, EIP-780, or similar proposals. Namely, it enforces the constraint of one attribute value per attribute ID per address, as opposed to one value per ID per address *per issuer*. Aside from the prescribed attribute value, attribute properties are deliberately omitted from the standard. While many attribute registries will require additional metadata on attributes at both the instance and the class level, reliable and flexible interoperability between highly variable registry extensions is facilitated more effectively by enforcing a widely-applicable base layer for attributes. ## Backwards Compatibility There are no backwards compatibility concerns. ## Test Cases Targeted test cases with 100% code coverage can be found at [this repository](https://github.com/0age/AttributeRegistry). See [here](https://github.com/TPL-protocol/tpl-contracts) for tests on a more complex contract that implements the application registry interface. ## Implementation The basic implementation that follows can be found at [this repository](https://github.com/0age/AttributeRegistry) (see [here](https://github.com/TPL-protocol/tpl-contracts/blob/master/contracts/BasicJurisdiction.sol#L399) for an example of a more complex implementing contract): ```solidity pragma solidity ^0.4.25; /** * @title Attribute Registry interface. EIP-165 ID: 0x5f46473f */ interface AttributeRegistryInterface { /** * @notice Check if an attribute of the type with ID `attributeTypeID` has * been assigned to the account at `account` and is currently valid. * @param account address The account to check for a valid attribute. * @param attributeTypeID uint256 The ID of the attribute type to check for. * @return True if the attribute is assigned and valid, false otherwise. * @dev This function MUST return either true or false - i.e. calling this * function MUST NOT cause the caller to revert. */ function hasAttribute( address account, uint256 attributeTypeID ) external view returns (bool); /** * @notice Retrieve the value of the attribute of the type with ID * `attributeTypeID` on the account at `account`, assuming it is valid. * @param account address The account to check for the given attribute value. * @param attributeTypeID uint256 The ID of the attribute type to check for. * @return The attribute value if the attribute is valid, reverts otherwise. * @dev This function MUST revert if a directly preceding or subsequent * function call to `hasAttribute` with identical `account` and * `attributeTypeID` parameters would return false. */ function getAttributeValue( address account, uint256 attributeTypeID ) external view returns (uint256); /** * @notice Count the number of attribute types defined by the registry. * @return The number of available attribute types. * @dev This function MUST return a positive integer value - i.e. calling * this function MUST NOT cause the caller to revert. */ function countAttributeTypes() external view returns (uint256); /** * @notice Get the ID of the attribute type at index `index`. * @param index uint256 The index of the attribute type in question. * @return The ID of the attribute type. * @dev This function MUST revert if the provided `index` value falls outside * of the range of the value returned from a directly preceding or subsequent * function call to `countAttributeTypes`. It MUST NOT revert if the provided * `index` value falls inside said range. */ function getAttributeTypeID(uint256 index) external view returns (uint256); } /** * @title A simple example of an Attribute Registry implementation. */ contract AttributeRegistry is AttributeRegistryInterface { // This particular implementation just defines two attribute types. enum Affiliation { Whitehat, Blackhat } // Top-level information about attribute types held in a static array. uint256[2] private _attributeTypeIDs; // The number of attributes currently issued tracked in a static array. uint256[2] private _issuedAttributeCounters; // Issued attributes held in a nested mapping by account & attribute type. mapping(address => mapping(uint256 => bool)) private _issuedAttributes; // Issued attribute values held in a nested mapping by account & type. mapping(address => mapping(uint256 => uint256)) private _issuedAttributeValues; /** * @notice The constructor function, defines the two attribute types available * on this particular registry. */ constructor() public { // Set the attribute type IDs for whitehats (8008) and blackhats (1337). _attributeTypeIDs = [8008, 1337]; } /** * @notice Assign a "whitehat" attribute type to `msg.sender`. * @dev The function may not be called by accounts with a "blackhat" attribute * type already assigned. This function is arbitrary and not part of the * Attribute Registry specification. */ function joinWhitehats() external { // Get the index of the blackhat attribute type on the attribute registry. uint256 blackhatIndex = uint256(Affiliation.Blackhat); // Get the attribute type ID of the blackhat attribute type. uint256 blackhatAttributeTypeID = _attributeTypeIDs[blackhatIndex]; // Do not allow the whitehat attribute to be set if blackhat is already set. require( !_issuedAttributes[msg.sender][blackhatAttributeTypeID], "no blackhats allowed!" ); // Get the index of the whitehat attribute type on the attribute registry. uint256 whitehatIndex = uint256(Affiliation.Whitehat); // Get the attribute type ID of the whitehat attribute type. uint256 whitehatAttributeTypeID = _attributeTypeIDs[whitehatIndex]; // Mark the attribute as issued on the given address. _issuedAttributes[msg.sender][whitehatAttributeTypeID] = true; // Calculate the new number of total whitehat attributes. uint256 incrementCounter = _issuedAttributeCounters[whitehatIndex] + 1; // Set the attribute value to the new total assigned whitehat attributes. _issuedAttributeValues[msg.sender][whitehatAttributeTypeID] = incrementCounter; // Update the value of the counter for total whitehat attributes. _issuedAttributeCounters[whitehatIndex] = incrementCounter; } /** * @notice Assign a "blackhat" attribute type to `msg.sender`. * @dev The function may be called by any account, but assigned "whitehat" * attributes will be removed. This function is arbitrary and not part of the * Attribute Registry specification. */ function joinBlackhats() external { // Get the index of the blackhat attribute type on the attribute registry. uint256 blackhatIndex = uint256(Affiliation.Blackhat); // Get the attribute type ID of the blackhat attribute type. uint256 blackhatAttributeTypeID = _attributeTypeIDs[blackhatIndex]; // Mark the attribute as issued on the given address. _issuedAttributes[msg.sender][blackhatAttributeTypeID] = true; // Calculate the new number of total blackhat attributes. uint256 incrementCounter = _issuedAttributeCounters[blackhatIndex] + 1; // Set the attribute value to the new total assigned blackhat attributes. _issuedAttributeValues[msg.sender][blackhatAttributeTypeID] = incrementCounter; // Update the value of the counter for total blackhat attributes. _issuedAttributeCounters[blackhatIndex] = incrementCounter; // Get the index of the whitehat attribute type on the attribute registry. uint256 whitehatIndex = uint256(Affiliation.Whitehat); // Get the attribute type ID of the whitehat attribute type. uint256 whitehatAttributeTypeID = _attributeTypeIDs[whitehatIndex]; // Determine if a whitehat attribute type has been assigned. if (_issuedAttributes[msg.sender][whitehatAttributeTypeID]) { // If so, delete the attribute. delete _issuedAttributes[msg.sender][whitehatAttributeTypeID]; // Delete the attribute value as well. delete _issuedAttributeValues[msg.sender][whitehatAttributeTypeID]; // Set the attribute value to the new total assigned whitehat attributes. uint256 decrementCounter = _issuedAttributeCounters[whitehatIndex] - 1; // Update the value of the counter for total whitehat attributes. _issuedAttributeCounters[whitehatIndex] = decrementCounter; } } /** * @notice Get the total number of assigned whitehat and blackhat attributes. * @return Array with counts of assigned whitehat and blackhat attributes. * @dev This function is arbitrary and not part of the Attribute Registry * specification. */ function totalHats() external view returns (uint256[2]) { // Return the array containing counter values. return _issuedAttributeCounters; } /** * @notice Check if an attribute of the type with ID `attributeTypeID` has * been assigned to the account at `account` and is currently valid. * @param account address The account to check for a valid attribute. * @param attributeTypeID uint256 The ID of the attribute type to check for. * @return True if the attribute is assigned and valid, false otherwise. * @dev This function MUST return either true or false - i.e. calling this * function MUST NOT cause the caller to revert. */ function hasAttribute( address account, uint256 attributeTypeID ) external view returns (bool) { // Return assignment status of attribute by account and attribute type ID return _issuedAttributes[account][attributeTypeID]; } /** * @notice Retrieve the value of the attribute of the type with ID * `attributeTypeID` on the account at `account`, assuming it is valid. * @param account address The account to check for the given attribute value. * @param attributeTypeID uint256 The ID of the attribute type to check for. * @return The attribute value if the attribute is valid, reverts otherwise. * @dev This function MUST revert if a directly preceding or subsequent * function call to `hasAttribute` with identical `account` and * `attributeTypeID` parameters would return false. */ function getAttributeValue( address account, uint256 attributeTypeID ) external view returns (uint256 value) { // Revert if attribute with given account & attribute type ID is unassigned require( _issuedAttributes[account][attributeTypeID], "could not find a value with the provided account and attribute type ID" ); // Return the attribute value. return _issuedAttributeValues[account][attributeTypeID]; } /** * @notice Count the number of attribute types defined by the registry. * @return The number of available attribute types. * @dev This function MUST return a positive integer value - i.e. calling * this function MUST NOT cause the caller to revert. */ function countAttributeTypes() external view returns (uint256) { // Return the length of the attribute type IDs array. return _attributeTypeIDs.length; } /** * @notice Get the ID of the attribute type at index `index`. * @param index uint256 The index of the attribute type in question. * @return The ID of the attribute type. * @dev This function MUST revert if the provided `index` value falls outside * of the range of the value returned from a directly preceding or subsequent * function call to `countAttributeTypes`. It MUST NOT revert if the provided * `index` value falls inside said range. */ function getAttributeTypeID(uint256 index) external view returns (uint256) { // Revert if the provided index is out of range. require( index < _attributeTypeIDs.length, "provided index is outside of the range of defined attribute type IDs" ); // Return the attribute type ID at the given index in the array. return _attributeTypeIDs[index]; } } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 23 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1616 https://eips.ethereum.org/EIPS/eip-1616 Money Streaming Standards Track/ERC https://github.com/ethereum/EIPs/issues/1620 ## Simple Summary Money streaming represents the idea of continuous payments over a finite period of time. Block numbers are used as a proxy of time to continuously update balances. ## Abstract The following describes a standard whereby time is measured using block numbers and streams are mappings in a master contract. 1. A provider sets up a money streaming contract. 2. A prospective payer can interact with the contract and start the stream right away by depositing the funds required for the chosen period. 3. The payee is able to withdraw money from the contract based on its ongoing solvency. That is: `payment rate * (current block height - starting block height)` 4. The stream terms (payment rate, length, metadata) can be updated at any time if both parties pledge their signatures. 5. The stream can be stopped at any point in time by any party without on-chain consensus. 6. If the stream period ended and it was not previously stopped by any party, the payee is entitled to withdraw all the deposited funds. ## Motivation This standardised interface aims to change the way we think about long-term financial commitments. Thanks to blockchains, payments need not be sent in chunks (e.g. monthly salaries), as there is much less overhead in paying-as-you-go. Money as a function of time would better align incentives in a host of scenarios. ### Use Cases This is just a preliminary list of use cases. There are other spooky ideas interesting to explore, such as time-dependent disincetivisation, but, for brevity, we have not included them here. - Salaries - Subscriptions - Consultancies - CDPs - Rent - Parking ### Crowdsales [RICOs](https://github.com/lukso-network/rico), or Reversible ICOs, were introduced at Devcon4 by @frozeman. The idea is to endow investors with more power and safety guarantees by allowing them to "reverse" the investment based on the evolution of the project. We previously discussed a similar concept called SICOs, or Streamable ICOs, in this research [thread](https://ethresear.ch/t/chronos-a-quirky-application-proposal-for-plasma/2928/14?u=paulrberg). Instead of investing a lump sum and giving the money away to the project developers, funds are held in a smart contract which allocates money based on the passage of time. Project developers can withdraw funds as the stream stays active, while investors have the power to get back a significant percentage of their initial commitment if the project halts. ## Specification ### Structs The structure of a `stream` should be as follows: - `stream` - `sender`: the `address` of the entity funding the stream - `recipient`: the `address` where the money is being delivered to - `tokenAddress`: the `address` of the ERC20 token used as payment asset - `balance`: the total funds left in the stream - `timeframe`: as defined below - `rate`: as defined below ```solidity struct Stream { address sender; address recipient; address tokenAddress; uint256 balance; Timeframe timeframe; Rate rate; } ``` - `timeframe` - `start`: the starting block number of the stream - `stop`: the stopping block number of the stream ```solidity struct Timeframe { uint256 start; uint256 stop; } ``` - `rate` - `payment`: how much money moves from `sender` to `recipient` - `interval`: how often `payment` moves from `sender` to `recipient` ```solidity struct Rate { uint256 payment; uint256 interval; } ``` --- ### Methods #### balanceOf Returns available funds for the given stream id and address. ```solidity function balanceOf(uint256 _streamId, address _addr) ``` #### getStream Returns the full stream data, if the id points to a valid stream. ```solidity function getStream(uint256 _streamId) returns (address sender, address recipient, address tokenAddress, uint256 balance, uint256 startBlock, uint256 stopBlock, uint256 payment, uint256 interval) ``` #### create Creates a new stream between `msg.sender` and `_recipient`. MUST allow senders to create multiple streams in parallel. SHOULD not accept Ether and only use ERC20-compatible tokens. **Triggers Event**: [LogCreate](#logcreate) ```solidity function create(address _recipient, address _tokenAddress, uint256 _startBlock, uint256 _stopBlock, uint256 _payment, uint256 _interval) ``` #### withdraw Withdraws all or a fraction of the available funds. MUST allow only the recipient to perform this action. **Triggers Event**: [LogWithdraw](#logwithdraw) ```solidity function withdraw(uint256 _streamId, uint256 _funds) ``` #### redeem Redeems the stream by distributing the funds to the sender and the recipient. SHOULD allow any party to redeem the stream. **Triggers Event**: [LogRedeem](#logredeem) ```solidity function redeem(uint256 _streamId) ``` #### confirmUpdate Signals one party's willingness to update the stream SHOULD allow any party to do this but MUST NOT be executed without consent from all involved parties. **Triggers Event**: [LogConfirmUpdate](#logconfirmupdate) **Triggers Event**: [LogExecuteUpdate](#logexecuteupdate) when the last involved party calls this function ```solidity function update(uint256 _streamId, address _tokenAddress, uint256 _stopBlock, uint256 _payment, uint256 _interval) ``` #### revokeUpdate Revokes an update proposed by one of the involved parties. MUST allow any party to do this. **Triggers Event**: [LogRevokeUpdate](#logrevokeupdate) ```solidity function confirmUpdate(uint256 _streamId, address _tokenAddress, uint256 _stopBlock, uint256 _payment, uint256 _interval) ``` --- ### Events #### LogCreate MUST be triggered when `create` is successfully called. ```solidity event LogCreate(uint256 indexed _streamId, address indexed _sender, address indexed _recipient, address _tokenAddress, uint256 _startBlock, uint256 _stopBlock, uint256 _payment, uint256 _interval) ``` #### LogWithdraw MUST be triggered when `withdraw` is successfully called. ```solidity event LogWithdraw(uint256 indexed _streamId, address indexed _recipient, uint256 _funds) ``` #### LogRedeem MUST be triggered when `redeem` is successfully called. ```solidity event LogRedeem(uint256 indexed _streamId, address indexed _sender, address indexed _recipient, uint256 _senderBalance, uint256 _recipientBalance) ``` #### LogConfirmUpdate MUST be triggered when `confirmUpdate` is successfully called. ```solidity event LogConfirmUpdate(uint256 indexed _streamId, address indexed _confirmer, address _newTokenAddress, uint256 _newStopBlock, uint256 _newPayment, uint256 _newInterval); ``` #### LogRevokeUpdate MUST be triggered when `revokeUpdate` is successfully called. ```solidity event LogRevokeUpdate(uint256 indexed _streamId, address indexed revoker, address _newTokenAddress, uint256 _newStopBlock, uint256 _newPayment, uint256 _newInterval) ``` #### LogExecuteUpdate MUST be triggered when an update is approved by all involved parties. ```solidity event LogExecuteUpdate(uint256 indexed _newStreamId, address indexed _sender, address indexed _recipient, address _newTokenAddress, uint256 _newStopBlock, uint256 _newPayment, uint256 _newInterval) ``` ## Rationale This specification was designed to serve as an entry point to the quirky concept of money as a function of time and it is definitely not set in stone. Several other designs, including payment channels and Plasma chains were also considered, but they were eventually deemed dense in assumptions unnecessary for an initial version. <!-- - Block times and oracles for time calculation - GCD - Miners - Sidechain-compatible (and preferable) - The `update` function - Multi-hop streams --> Block times are a reasonable, trustless proxy for time on the blockchain. Between 2016 and 2018, the Ethereum block time average value [hovered](https://etherscan.io/chart/blocktime) around 14 seconds, excluding the last two quarters of 2017. Mathematically speaking, it would be ideal to have a standard deviation as close to 0 as possible, but that is not how things work in the real world. This has huge implications on the feasibility of this ERC which we shall investigate below. ### GCD When setting up a stream, a payer and a payee may want to make the total streaming duration a multiple of the "greatest common denominator" (GCD) of the chain they operate on; that is, the average block time. This is not imperative in the smart contracts per se, but there needs to be an off-chain process to map streams to real world time units in order to create a sound and fair payment mechanism. ### Block Times Because there is uncertainty regarding block times, streams may not be settled on the blockchain as initially planned. Let `$d` be the total streaming duration measured in seconds, `$t` the average block time before the stream started and `$t'` the actual average block time over `$d` after the stream started. We distinguish two undesirable scenarios: 1. `$t` < `$t'`: the payee will get their funds *later* than expected 2. `$t` > `$t'`: the payee will get their funds *sooner* than expected If the combined error delta is smaller than the payment rate (fifth parameter of the `create` method, measured in wei), there is no problem at all. Conversely, we stumble upon trust issues because real-world time frames do not correspond to the stream terms. For instance, if an employee is normally entitled to withdraw all the funds from the stream at the end of the month, but block times cause case 1 from above to occur, the employee is in a financial disadvantage because their continuous effort is not compensated as promised. Limiting the problem scope only to Ethereum, we propose two remedies: 1. Consensus on calling the `update` function to correct the stream terms. This might sound preposterous, but in most cases the stakes are low and stream participants are involved in long-term financial commitments. There is a high disincentive to refuse to cooperate. 2. Autonomously fix significant error deltas. In theory, we could achieve this using previous blocks' timestamps, "checkpointing" the stream once in a predefined number of blocks. This is still an area of active research because of potentially high overheads in gas costs. Nonetheless, it is important to note that this is still a major improvement on the traditional model where absolute trust is required. ### Sidechains It could be more efficient to implement this standard on independent sidechains like [POA Network](https://poa.network) or [xDai](https://medium.com/poa-network/poa-network-partners-with-makerdao-on-xdai-chain-the-first-ever-usd-stable-blockchain-65a078c41e6a) - thanks to their rather predictable nature. Admittedly, security is traded for scalability, but proper cryptoeconomic stakes could alleviate potential problems. Furthermore, it is intriguing to explore the prospect of stream-specific sidechains. ### Oracles The proposed specification uses block numbers to proxy time, but this need not be the only method. Albeit it would imply different trust assumptions, oracles could be used to provide a feed of timestamps. Coupled with the aforementioned idea of stream-specific sidechains, oracles could efficiently solve the problems outlined in [Block Times](#block-times). ### Multi-Hop Streams Future or upgraded versions of this standard may describe "multi-hop" streams. If: 1. There is a stream between A and B 2. There is another stream between B and C There could be a way to avoid running two different streams in parallel. That is, a fraction or all of the funds being streamed from A to B could be automatically wired to C. An interesting use case for this is taxes. Instead of manually moving money around, proactively calculating how much you owe and then transfer it, a stream could atomically perform those operations for you. ## Implementation - [ChronosProtocol WIP implementation](https://github.com/ChronosProtocol/monorepo) ## Additional References - [Chronos Protocol Ethresear.ch Plasma Proposal](https://ethresear.ch/t/chronos-a-quirky-application-proposal-for-plasma/2928?u=paulrberg) - [Chronos Protocol White Paper](http://chronosprotocol.org/chronos-white-paper.pdf) - [Flipper: Streaming Salaries @ CryptoLife Hackathon](https://devpost.com/software/flipper-3gvl4b) - [SICOs or Streamed ICOs](https://ethresear.ch/t/chronos-a-quirky-application-proposal-for-plasma/2928/14?u=paulrberg) - [RICOs or Reversible ICOs](https://twitter.com/feindura/status/1058057076306518017) - [Andreas Antonopoulos' Keynote on Bitcoin, Lightning and Money Streaming](https://www.youtube.com/watch?v=gF_ZQ_eijPs) ## Final Notes Many thanks to @mmilton41 for countless brainstorming sessions. We have been doing research on the topic of money streaming for quite a while within the context of @ChronosProtocol. In August this year, we published the first version of our white paper describing a Plasma approach. However, in the meantime, we realised that it would be much more [fun](https://twitter.com/PaulRBerg/status/1056595919116910592) and easier to start small on Ethereum itself and sidechains like [xDai](https://blockscout.com/poa/dai). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 24 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1620 https://eips.ethereum.org/EIPS/eip-1620 Re-Fungible Token Standard (RFT) Standards Track/ERC https://github.com/ethereum/EIPs/issues/1634 ## Simple Summary [ERC-20](/EIPS/eip-20) extension for proportional ownership of an [ERC-721](/EIPS/eip-721) token. ## Abstract The intention of this proposal, the Re-Fungible Token Standard, is to extend the ERC-20 Token Standard and utilize ERC-165 Standard Interface Detection in order to represent the shared ownership of an ERC-721 Non-Fungible Token. The ERC-20 Token Standard was modified as little as possible in order to allow this new class of token to operate in all of the ways and locations which are familiar to assets that follow the original ERC-20 specification. While there are many possible variations of this specification that would enable many different capabilities and scenarios for shared ownership, this proposal is focused on the minimal commonalities to enable as much flexibility as possible for various further extensions. This proposal makes it possible to verify, from the contract level or from an external query, whether a fungible token represents a form of shared ownership of a non-fungible token. The inclusion of ERC-165 makes it possible to verify, from the contract level or from an external query, whether a non-fungible token is owned by ERC-20 token representing shared ownership. ## Motivation Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ARTBLX Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token is collectively owned. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. ## Specification At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine when a non-fungible token is collectively owned. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. #### Initial Contact with the Re-Fungible Token In order for a third party to confirm which non-fungible token is owned by the re-fungible token there needs to be a pointer from the RFT contract to the NFT contract and the relevant token id. This is possible with two public getters named `parentToken()` and `parentTokenId()`. The first getter returns a variable of type `address` and designates the contract address of the Non-Fungible Token contract. The second getter returns a variable of type `uint256` and designates the token ID of the Non-Fungible Token. With these getters, the identity of the Non-Fungible Token can be determined. Below is an example of the Re-Fungible Token Standard interface that includes these getter functions: ```solidity pragma solidity ^0.4.20; /// @dev Note: the ERC-165 identifier for this interface is 0x5755c3f2. interface RFT /* is ERC20, ERC165 */ { function parentToken() external view returns(address _parentToken); function parentTokenId() external view returns(uint256 _parentTokenId); } ``` The validity of this claim can be confirmed from another contract (on-chain) or from interacting with an RPC endpoint (off-chain). Below is an example of the on-chain scenario: ```solidity pragma solidity ^0.4.20; import './RFT.sol'; import './ERC721.sol'; contract ConfirmRFT { function confirmRFT(address _RFT) external view returns(bool) { address _NFT = RFT(_RFT).parentToken(); // returns address of NFT contract uint256 _tokenId = RFT(_RFT).parentTokenId(); // returns id of ID of NFT return NFT(_NFT).supportsInterface(0x80ac58cd) && // confirm it is ERC-721 NFT(_NFT).ownerOf(_tokenId) == _RFT; // confirm the owner of the NFT is the RFT contract address } } ``` Below is an off-chain example using an instance of web3.js in javascript: ```javascript async function confirmRFT(web3) { const ERC721ABI = [...] // abi for ERC721 const RFTABI = [...] // abi for RFT const RFTAddress = '0x0123456789abcdef0123456789abcdef' // address for the deployed RFT const RFTContract = new web3.eth.Contract(RFTABI, RFTAddress) // deployed RFT contract instance const ERC721Address = await RFTcontract.methods.parentToken().call() // returns address of NFT contract const ERC721TokenId = await RFTcontract.methods.parentTokenId().call() // returns id of ID of NFT const ERC721Contract = new web3.eth.Contract(ERC721ABI, ERC721Address) // deployed ERC721 (as reported by RFT) const isERC721 = await ERC721Contract.methods.supportsInterface('0x80ac58cd').call() // confirm it is ERC-721 const ownerOfAddress = await ERC721Contract.methods.ownerOf(ERC721TokenId).call() // get the owner of the NFT return ERC721Response.toLowerCase() === RFTAddress.toLowerCase() // confirm the owner of the NFT is the RFT contract } ``` #### Initial Contact with the Non-Fungible Token When checking the owner of a specific non-fungible token it's important to be able to determine whether owner is in fact a re-fungible token contract. This is possible by utilizing ERC-165 Standard Interface Detection. In order to comply with that standard a contract must include the following getter function which returns `true` when passed the `bytes4` parameter `0x01ffc9a7`: ``` function supportsInterface(bytes4 interfaceID) external view returns (bool); ``` After establishing support for this interface it becomes useful in determining whether the contract adheres to the Re-Fungible Token Standard. To do so the `supportsInterface(bytes4 interfaceID)` getter function must return `true` when passed the `bytes4` parameter `0x5755c3f2` which is the result of `bytes4(keccak256('parentToken()')) ^ bytes4(keccak256('parentTokenId()'))` or `parentToken.selector ^ parentTokenId.selector`. This could be achieved with the following code: ```solidity pragma solidity ^0.4.20; import "./ERC20.sol"; /// @dev Note: the ERC-165 identifier for this interface is 0x5755c3f2. interface RFT is ERC20 /*, ERC165 */ { function supportsInterface(bytes4 interfaceID) external view returns(bool) { return interfaceID == this.supportsInterface.selector || // ERC165 interfaceID == this.parentToken.selector || // parentToken() interfaceID == this.parentTokenId.selector || // parentTokenId() interfaceID == this.parentToken.selector ^ this.parentTokenId.selector; // RFT } function parentToken() external view returns(address _parentToken); function parentTokenId() external view returns(uint256 _parentTokenId); } ``` The flow of actually checking the status of a non-fungible token owner as a re-fungible token contract can be done from another contract (on-chain) as well as with an RPC endpoint (off-chain). Below is an example of the on-chain scenario: ```solidity pragma solidity ^0.4.20; import './RFT.sol'; import './ERC721.sol'; contract ConfirmRFT { function confirmRFT(address _NFT, uint256 _tokenId) external view returns(bool) { address _RFT = ERC721(_NFT).ownerOf(_tokenId); // get the owner of the NFT return RFT(_RFT).supportsInterface(0x01ffc9a7) && // confirm it supports ERC-165 RFT(_RFT).supportsInterface(0x5755c3f2) // confirm it is RFT } } ``` Below is an off-chain example using web3.js in javascript: ```javascript async function confirmRFT(web3) { const ERC721ABI = [...] // abi for ERC721 const RFTABI = [...] // abi for RFT const ERC721Address = '0x0123456789abcdef0123456789abcdef' // address for the deployed NFT const ERC721TokenId = '7' // token Id of the NFT const ERC721Contract = new web3.eth.Contract(ERC721ABI, ERC721Address) // deployed ERC721 const RFTAddress = await ERC721Contract.methods.ownerOf(ERC721TokenId).call() // owner address of the NFT const RFTContract = new web3.eth.Contract(RFTABI, RFTAddress) // deployed RFT contract instance const isERC165 = await RFTContract.methods.supportsInterface('0x01ffc9a7').call() // confirm it is ERC-165 return isERC165 && await RFTContract.methods.supportsInterface('0x5755c3f2').call() // confirm it is RFT } ``` ## Rationale Most of the decisions made around the design of this standard were done in the hopes of keeping it as flexible as possible for as many use cases as possible. This includes making the standard 100% backwards compatible with ERC-20 Token Standard and able to interact with any previously deployed or future ERC-721 non-fungible token. This allows for each project to determine their own system for minting, burning and governing their re-fungible tokens depending on their specific use case. ## Backwards Compatibility The Re-Fungible Token Standard is 100% backwards compatible with ERC-20 Token Standard. It is a small extension to the original specification and meant to be further extended for more specific use cases. Keeping the standard compatible with ERC-20 is important to allow for this token to benefit from the ecosystem that has grown around supporting the ubiquitous ERC-20 Token Standard. The Re-Fungible Token Standard is intended to interact with the ERC-721 Non-Fungible Token Standard. It is kept purposefully agnostic to extensions beyond the standard in order to allow specific projects to design their own token relationships such as governance over, rights to or permissions on each non-fungible token relative to the respective re-fungible token owners. ## Implementation ```solidity pragma solidity ^0.4.20; /// @dev Note: the ERC-165 identifier for this interface is 0x5755c3f2. interface RFT /* is ERC20, ERC165 */ { function parentToken() external view returns(address _parentToken); function parentTokenId() external view returns(uint256 _parentTokenId); } ``` ## Security Considerations TBD ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 18 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1633 https://eips.ethereum.org/EIPS/eip-1633 Hardfork Meta: Istanbul Meta/ https://ethereum-magicians.org/t/hardfork-meta-istanbul-discussion/3207 ## Abstract This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul. ## Specification - Codename: Istanbul ### Activation - `Block >= 9,069,000` on the Ethereum Mainnet - `Block >= 6,485,846` on the Ropsten testnet - `Block >= 14,111,141` on the Kovan testnet - `Block >= 5,435,345` on the Rinkeby testnet - `Block >= 1,561,651` on the Görli testnet ### Included EIPs - [EIP-152](/EIPS/eip-152): Add Blake2 compression function `F` precompile - [EIP-1108](/EIPS/eip-1108): Reduce alt_bn128 precompile gas costs - [EIP-1344](/EIPS/eip-1344): Add ChainID opcode - [EIP-1884](/EIPS/eip-1884): Repricing for trie-size-dependent opcodes - [EIP-2028](/EIPS/eip-2028): Calldata gas cost reduction - [EIP-2200](/EIPS/eip-2200): Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change ## References 1. Included EIPs were finalized in [All Core Devs Call #68](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2068.md) 2. https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 04 Jan 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1679 https://eips.ethereum.org/EIPS/eip-1679 Temporal Replay Protection Standards Track/Core https://ethereum-magicians.org/t/temporal-replay-protection/2355 ## Simple Summary This EIP proposes adding a 'temporal' replay protection to transactions, in the form of a `valid-until` timestamp. This EIP is very similar to https://github.com/ethereum/EIPs/pull/599 by Nick Johnson and Konrad Feldmeier, the main difference being that this EIP is based on clock-time / walltime instead of block numbers. ## Motivation There are a couple of different motivators for introducing a timebased transaction validity. - If any form of dust-account clearing is introduced, e.g. (https://github.com/ethereum/EIPs/issues/168), it will be necessary to introduce a replay protection, such as https://github.com/ethereum/EIPs/issues/169 . Having temporal replay protection removes the need to change nonce-behaviour in the state, since transactions would not be replayable at a later date than explicitly set by the user. - In many cases, such as during ICOs, a lot of people want their transactions to either become included soon (within a couple of hours) or not at all. Currently, transactions are queued and may not execute for several days, at a cost for both the user (who ends up paying gas for a failing purchase) and the network, dealing with the large transaction queues. - Node implementations have no commonly agreed metric for which transactions to keep, discard or propagate. Having a TTL on transactions would make it easier to remove stale transactions from the system. ## Specification The roll-out would be performed in two phases, `X` (hardfork), and `Y` (softfork). At block `X`, - Add an optional field `valid-until` to the RLP-encoded transaction, defined as a `uint64` (same as `nonce`). - If the field is present in transaction `t`, then - `t` is only eligible for inclusion in a block if `block.timestamp` < `t.valid-until`. At block `Y`, - Make `valid-until` mandatory, and consider any transaction without `valid-until` to be invalid. ## Rationale ### Rationale for this EIP For the dust-account clearing usecase, - This change is much less invasive in the consensus engine. - No need to maintain a consensus-field of 'highest-known-nonce' or cap the number of transactions from a sender in a block. - Only touches the transaction validation part of the consensus engine - Other schemas which uses the `nonce` can have unintended side-effects, - such as inability to create contracts at certain addresses. - more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine. - More intricate schemes like `highest-nonce` are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requiring one more journalled field. ### Rationale for walltime Why use walltime instead of block numbers, as proposed in https://github.com/ethereum/EIPs/pull/599 ? - The UTC time is generally available in most settings, even on a computer which is offline. This means that even a setup where blockchain information is unavailable, the party signing a transaction can generate a transaction with the desired properties. - The correlation between time and block number is not fixed; even though a 14s blocktime is 'desired', this varies due to both network hashrate and difficulty bomb progression. - The block number is even more unreliable as a timestamp for testnets and private networks. - UTC time is more user-friendly, a user can more easily decide on reasonable end-date for a transaction, rather than a suitalbe number of valid blocks. ## Backwards Compatibility This EIP means that all software/hardware that creates transactions need to add timestamps to the transactions, or will otherwise be incapable of signing transactions after block `Y`. Note: this EIP does not introduce any maximum `valid-until` date, so it would still be possible to create transactions with near infinite validity. ## Test Cases todo ## Implementation None yet ## Security considerations The most notable security impact is that pre-signed transactions stored on paper backups, will become invalid as of block `Y`. There are a couple of cases where this might be used - Pregenerated onetime 'bootstrap' transactions, e.g. to onboard a user into Ethereum. Instead of giving a user a giftcard with actual ether on it, someone may instead give the person a one-time pregenerated transaction that will only send those ether to the card once the user actively wants to start using it. - If a user has an offline paper-wallet, he may have pregenerated transactions to send value to e.g. an exchange. This is sometimes done to be able to send ether to an exchange without having to go through all the hoops of bringing the paper wallet back to 'life'. Secondary security impacts are that the addition of a timestamp would make the transactions a little bit larger. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 08 Jan 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1681 https://eips.ethereum.org/EIPS/eip-1681 Storage Rent Standards Track/Core https://ethereum-magicians.org/t/storage-rent-eip/2357 ## Abstract This EIP describes a scheme to charge for data in state, and 'archive' data which is no longer being paid for. It also describes how resurrection of 'archived' data happens. ## Motivation The Ethereum blockchain in its current form is not sustainable because it grows indefinitely. This is true of any blockchain, but Ethereum grows faster than most chains. Many implementation strategies to slow down growth exist. A common strategy is 'state pruning' which discards historical state, keeping only the active copy of contract data and a few recent versions to deal with short-range chain reorganizations. Several implementations also employ compression techniques to keep the active copy of the state as small as possible. A full node participating in consensus today requires storing large amounts of data even with advanced storage optimizations applied. Future storage requirements are unbounded because any data stored in a contract must be retained forever as dictated by the protocol. This EIP attempts to correct this by adding new consensus rules that put an upper bound on the size of the Ethereum state. Adding these new rules changes fundamental guarantees of the system and requires a hard fork. Users of Ethereum already pay for the creation and modification of accounts and their storage entries. Under the rules introduced in this EIP, users must also pay to keep accounts accessible. A similar rent scheme was proposed in [EIP-103] but rejected even back then because the proposal would've upset peoples expectations. As implementers of Ethereum, we still feel that state rent is the right path to long-term sustainability of the Ethereum blockchain and that its undesirable implications can be overcome with off-protocol tooling and careful design. [EIP-103]: https://github.com/ethereum/EIPs/issues/35 ## Specification The cost of storing an account over time is called `rent`. The amount of `rent` due depends on the size of the account. The `ether` that is paid for `rent` is destroyed. The `rent` is deducted whenever an account is touched. `rent` can be paid from the account's regular `balance` or from its 'rent balance'. Accounts can be endowed with `rent balance` through a new EVM opcode. When `rent` is charged, it is first taken from the `rent balance`. When `rent balance` is zero, it is instead charged from the account's regular `balance` instead. The reason to separate `balance` and `rent balance` is that certain contracts do not accept `ether` sends, or always send the entire balance off to some other destination. For these cases, a separate`rent balance` is required. When an account's `balance` is insufficient to pay rent, the account becomes `inactive`. Its storage and contract code are removed. Inactive accounts cannot be interacted with, i.e. it behaves as if it has no contract code. Inactive accounts can be restored by re-uploading their storage. To restore an inactive account `A`, a new account `B` is created with arbitrary code and its storage modified with `SSTORE` operations until it matches the storage root of `A`. Account `B` can restore `A` through the `RESTORETO` opcode. This means the cost of restoring an account is equivalent to recreating it via successive `SSTORE` operations. ### Changes To State At the top level, a new key `size` is added to the accounts trie. This key tracks the total number of trie nodes across all accounts, including storage trie nodes. To track rent, the structure of account entries is changed as well. Before processing the block in which this EIP becomes active, clients iterate the whole state once to count the number of trie nodes and to change the representation of all accounts to the new format. #### Account Representation ```text account = [nonce, balance, storageroot, codehash, rentbalance, rentblock, storagesize] ``` Each account gets three additional properties: `rentbalance`, `rentblock` and `storagesize`. The `rentbalace` field tracks the amount of `rent balance` available to the account. Upon self-destruction any remaining `rent balance` is transferred to the beneficiary. Any modification of the account recomputes its current `rent balance`. The `rentblock` field tracks the block number in which the `rent balance` was last recomputed. Upon creation, this field is initialized with the current block number. `rentblock` is also updated with the current block number whenever the account is modified. The `storagesize` field tracks the amount of storage related to the account. It is a number containing the number of storage slots currently set. The `storagesize` of an inactive account is zero. ### Charging Rent There is a new protocol constant `MAX_STORAGE_SIZE` that specifies the upper bound on the number of state tree nodes: ```python MAX_STORAGE_SIZE = 2**32 # ~160GB of state ``` A 'storage fee factor' for each block is derived from this constant such that fees increase as the limit is approached. ```python def storagefee_factor(block): ramp = MAX_STORAGE_SIZE / (MAX_STORAGE_SIZE - total_storage_size(block)) return 2**22 * ramp ``` When a block is processed, `rent` is deducted from all accounts modified by transactions in the block after the transactions have been processed. The amount due for each account is based on the account's storage size. ```python def rent(prestate, poststate, addr, currentblock): fee = 0 for b in range(prestate[addr].rentblock+1, currentblock-1): fee += storagefee_factor(b) * prestate[addr].storagesize return fee + storagefee_factor(currentblock) * poststate[addr].storagesize def charge_rent(prestate, poststate, addr, currentblock): fee = rent(prestate, poststate, addr, currentblock) if fee <= poststate[addr].rentbalance: poststate[addr].rentbalance -= fee else: fee -= poststate[addr].rentbalance poststate[addr].rentbalance = 0 poststate[addr].balance -= min(poststate[addr].balance, fee) poststate[addr].rentblock = currentblock ``` ### New EVM Opcodes #### `PAYRENT <amount> <addr>` At any time, the `rent balance` of an account may be topped up by the `PAYRENT` opcode. `PAYRENT` deducts the given amount of `ether` from the account executing the opcode and adds it to the `rent balance` of the address specified as beneficiary. Any participant can pay the rent for any other participant. Gas cost: TBD #### `RENTBALANCE <addr>` The `rent balance` of an account may be queried through the `RENTBALANCE` opcode. It pushes the `rentbalance` field of the given address to the stack. Gas cost: like `EXTCODEHASH`. #### `SSIZE <addr>` This opcode pushes the `storagesize` field of the given account to the stack. Gas cost: like `EXTCODEHASH`. #### `RESTORETO <addr> <codeaddr>` This opcode restores the inactive account at the given address. This is a bit like `SELFDESTRUCT` but has more specific semantics. The account at `addr` must be `inactive` (i.e. have `storagesize` zero) and its `storageroot` must match the `storageroot` of the contract executing `RESTORETO`. The `codeaddr` specifies the address of a contract from which code is taken. The code of the `codeaddr` account must match the `codehash` of `addr`. If all these preconditions are met, `RESTORETO` transfers the storage of the account executing the opcode to `addr` and resets its `storagesize` to the full size of the storage. The code of `addr` is restored as well. `RESTORETO` also transfers any remaining balance and rent balance to `addr`. The contract executing `RESTORETO` is deleted. Gas cost: TBD ## Rationale ### Why do we need a separate rent balance? Accounts need a separate rent balance because some contracts are non-payable, i.e. they reject regular value transfers. Such contracts might not be able to keep themselves alive, but users of those contracts can keep them alive by paying rent for them. Having the additional balance also makes things easier for contracts that hold balance on behalf of a user. Consider the canonical crowdfunding example, a contract which changes behavior once a certain balance is reached and which tracks individual user's balances. Deducting rent from the main balance of the contract would mess up the contract's accounting, leaving it unable to pay back users accurately if the threshold balance isn't reached. ### Why restoration? One of the fundamental guarantees provided by Ethereum is that changes to contract storage can only be made by the contract itself and storage will persist forever. If you hold a token balance in a contract, you'll have those tokens forever. By adding restoration, we can maintain this guarantee to a certain extent. ### Implementation Impact The proposed changes tries to fit within the existing state transition model. Note that there is no mechanism for deactivating accounts the moment they can't pay rent. Users must touch accounts to ensure their storage is removed because we'd need to track all accounts and their rent requirements in an auxlilary data structure otherwise. ## Backwards Compatibility TBA ## Test Cases TBA ## Implementation TBA ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 10 Nov 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1682 https://eips.ethereum.org/EIPS/eip-1682 Generalized Account Versioning Scheme Standards Track/Core https://github.com/sorpaas/EIPs/issues/2 ## Simple Summary Introduce account versioning for smart contracts so upgrading the VM or introducing new VMs can be easier. ## Abstract This defines a method of hard forking while maintaining the exact functionality of existing account by allowing multiple versions of the virtual machines to execute in the same block. This is also useful to define future account state structures when we introduce the on-chain WebAssembly virtual machine. ## Motivation By allowing account versioning, we can execute different virtual machine for contracts created at different times. This allows breaking features to be implemented while making sure existing contracts work as expected. Note that this specification might not apply to all hard forks. We have emergency hard forks in the past due to network attacks. Whether they should maintain existing account compatibility should be evaluated in individual basis. If the attack can only be executed once against some particular contracts, then the scheme defined here might still be applicable. Otherwise, having a plain emergency hard fork might still be a good idea. ## Specification ### Account State Re-define account state stored in the world state trie to have 5 items: `nonce`, `balance`, `storageRoot`, `codeHash`, and `version`. The newly added field `version` is a 256-bit **scalar**. We use the definition of "scalar" from Yellow Paper. Note that this is the same type as `nonce` and `balance`, and it is equivalent to a RLP variable-sized byte array with no leading zero, of maximum length 32. When `version` is zero, the account is RLP-encoded with the first 4 items. When `version` is not zero, the account is RLP-encoded with 5 items. Account versions can also optionally define additional account state RLP fields, whose meaning are specified through its `version` field. In those cases, the parsing strategy is defined in "Additional Fields in Account State RLP" section. ### Contract Execution When fetching an account code from state, we always fetch the associated version field together. We refer to this as the *code's version* below. The code of the account is always executed in the *code's version*. In particular, this means that for `DELEGATECALL` and `CALLCODE`, the version of the execution call frame is the same as delegating/receiving contract's version. ### Contract Deployment In Ethereum, a contract has a deployment method, either by a contract creation transaction, or by another contract. If we regard this deployment method a contract's *parent*, then we find them forming a family of contracts, with the *root* being a contract creation transaction. We let a family of contracts to always have the same `version`. That is, `CREATE` and `CREATE2` will always deploy contract that has the same `version` as the *code's version*. In other words, `CREATE` and `CREATE2` will execute the init code using the current *code's version*, and deploy the contract of the current *code's version*. This holds even if the to-be-deployed code is empty. ### Validation A new phrase, *validation* is added to contract deployment (by `CREATE` / `CREATE2` opcodes, or by contract creation transaction). When `version` is `0`, the phrase does nothing and always succeeds. Future VM versions can define additional validation that has to be passed. If the validation phrase fails, deployment does not proceed and return out-of-gas. ### Contract Creation Transaction Define `LATEST_VERSION` in a hard fork to be the latest supported VM version. A contract creation transaction is always executed in `LATEST_VERSION` (which means the *code's version* is `LATEST_VERSION`), and deploys contracts of `LATEST_VERSION`. Before a contract creation transaction is executed, run *validation* on the contract creation code. If it does not pass, return out-of-gas. ### Precompiled Contract and Externally-owned Address Precompiled contracts and externally-owned addresses do not have `version`. If a message-call transaction or `CALL` / `CALLCODE` / `STATICCALL` / `DELEGATECALL` touches a new externally-owned address or a non-existing precompiled contract address, it is always created with `version` field being `0`. ### Additional Fields in Account State RLP In the future we may need to associate more information into an account, and we already have some EIPs that define new additional fields in the account state RLP. In this section, we define the parsing strategy when additional fields are added. * Check the RLP list length, if it is 4, then set account version to `0`, and do not parse any additional fields. * If the RLP list length more than 4, set the account version to the scalar at position `4` (counting from `0`). * Check version specification for the number of additional fields defined `N`, if the RLP list length is not equal to `5 + N`, return parse error. * Parse RLP position `5` to `4 + N` as the meaning specified in additional fields. ## Extensions In relation to the above "Specification" section, we have defined the base account versioning layer. The base account versioning layer is already useful by itself and can handle most EVM improvements. Below we define two specifications that can be deployed separately, which improves functionality of base layer account versioning. Note that this section is provided only for documentation purpose. When "enabling EIP-1702", those extensions should not be enabled unless the extension specification is also included. * [44-VERTXN: Account Versioning Extension for Contract Creation Transaction](https://corepaper.org/ethereum/compatibility/versioning/#extensions-for-state-based-account-versioning) * [45-VEROP: Account Versioning Extension for CREATE and CREATE2](https://corepaper.org/ethereum/compatibility/versioning/#create-and-create2-extension) ## Usage Template This section defines how other EIPs might use this account versioning specification. Note that currently we only define the usage template for base layer. Account versioning is usually applied directly to a hard fork meta. EIPs in the hard fork are grouped by the virtual machine type, for example, EVM and eWASM. For each of them, we define: * **Version**: a non-zero scalar less than `2^256` that uniquely identifies this version. Note that it does not need to be sequential. * **Parent version**: the base that all new features derived from. With parent version of `0` we define the base to be legacy VM. Note that once a version other than `0` is defined, the legacy VM's feature set must be frozen. When defining an entirely new VM (such as eWASM), parent version does not apply. * **Features**: all additional features that are enabled upon this version. If a meta EIP includes EIPs that provide additional account state RLP fields, we also define: * **Account fields**: all account fields up to the end of this meta EIP, excluding the basic 5 fields (`nonce`, `balance`, `storageRoot`, `codeHash` and `version`). If EIPs included that are specific to modifying account fields do not modify VM execution logic, it is recommended that we specify an additional version whose execution logic is the same as previous version, but only the account fields are changed. ## Rationale This introduces account versioning via a new RLP item in account state. The design above gets account versioning by making the contract *family* always have the same version. In this way, versions are only needed to be provided by contract creation transaction, and there is no restrictions on formats of code for any version. If we want to support multiple newest VMs (for example, EVM and WebAssembly running together), then this will requires extensions such as 44-VERTXN and 45-VEROP. Alternatively, account versioning can also be done through: * **[26-VER](https://corepaper.org/ethereum/compatibility/versioning/#prefix-based-account-versioning)** and **[40-UNUSED](https://corepaper.org/ethereum/compatibility/forward/)**: This makes an account's versioning solely dependent on its code header prefix. If with only 26-VER, it is not possible to certify any code is valid, because current VM allows treating code as data. This can be fixed by 40-UNUSED, but the drawback is that it's potentially backward incompatible. * **EIP-1891**: Instead of writing version field into account RLP state, we write it in a separate contract. This can accomplish the same thing as this EIP and potentially reduces code complexity, but the drawback is that every code execution will require an additional trie traversal, which impacts performance. ## Backwards Compatibility Account versioning is fully backwards compatible, and it does not change how current contracts are executed. ## Discussions ### Performance Currently nearly all full node implementations uses config parameters to decide which virtual machine version to use. Switching virtual machine version is simply an operation that changes a pointer using a different set of config parameters. As a result, this scheme has nearly zero impact to performance. ### WebAssembly This scheme can also be helpful when we deploy on-chain WebAssembly virtual machine. In that case, WASM contracts and EVM contracts can co-exist and the execution boundary and interaction model are clearly defined as above. ## Test Cases and Implementations To be added. ## References The source of this specification can be found at [43-VER](https://corepaper.org/ethereum/compatibility/versioning/#state-based-account-versioning). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 30 Dec 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1702 https://eips.ethereum.org/EIPS/eip-1702 Disable SSTORE with gasleft lower than call stipend Standards Track/Core https://github.com/alex-forshtat-tbk/EIPs/issues/1 ## Simple Summary The proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. This proposal will make the old assumptions hold even after a network upgrade. ## Abstract [EIP-1283](/EIPS/eip-1283) significantly lowers the gas costs of writing to contract's storage. This created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a 'stipend' of 2300 gas to simple transfer calls. This danger is easily mitigated if SSTORE is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of this EIP. ## Motivation An attack that is described in [this article](https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9). Explicitly specifying the call stipend as an invariant will have a positive effect on Ethereum protocol security: https://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_constantinople/ee5uvjt ## Specification Add the following condition to the SSTORE opcode gas cost calculation: * If *gasleft* is less than or equal to 2300, fail the current call frame with 'out of gas' exception. ## Rationale In order to keep in place the implicit reentrancy protection of existing contracts, transactions should not be allowed to modify state if the remaining gas is lower then the 2300 stipend given to 'transfer'/'send' in Solidity. These are other proposed remediations and objections to implementing them: * Drop EIP-1283 and abstain from modifying SSTORE cost * EIP-1283 is an important update * It was accepted and implemented on test networks and in clients. * Add a new call context that permits LOG opcodes but not changes to state. * Adds another call type beyond existing regular/staticcall * Raise the cost of SSTORE to dirty slots to >=2300 gas * Makes net gas metering much less useful. * Reduce the gas stipend * Makes the stipend almost useless. * Increase the cost of writes to dirty slots back to 5000 gas, but add 4800 gas to the refund counter * Still doesn’t make the invariant explicit. * Requires callers to supply more gas, just to have it refunded * Add contract metadata specifying per-contract EVM version, and only apply SSTORE changes to contracts deployed with the new version. ## Backwards Compatibility Performing SSTORE has never been possible with less than 5000 gas, so it does not introduce incompatibility to the Ethereum mainnet. Gas estimation should account for this requirement. ## Test Cases Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. TODO ## Implementation TODO ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Tue, 15 Jan 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1706 https://eips.ethereum.org/EIPS/eip-1706 URL Format for Web3 Browsers Standards Track/ERC https://ethereum-magicians.org/t/standarize-url-format-for-web3-browsers/2422 ## Simple Summary A standard way of representing web3 browser URLs for decentralized applications. ## Abstract Since most normal web browsers (specifically on mobile devices) can not run decentralized applications correctly because of the lack of web3 support, it is necessary to differentiate them from normal urls, so they can be opened in web3 browsers if available. ## Motivation Lots of dApps that are trying to improve their mobile experience are currently (deep)linking to specific mobile web3 browsers which are currently using their own url scheme. In order to make the experience more seamless, dApps should still be able to recommend a specific mobile web3 browser via [deferred deeplinking](https://en.wikipedia.org/wiki/Deferred_deep_linking) but by having a standard url format, if the user already has a web3 browser installed that implements this standard, it will be automatically linked to it. There is also a compatibility problem with the current `ethereum:` url scheme described in [EIP-831](/EIPS/eip-831) where any ethereum related app (wallets, identity management, etc) already registered it and because of iOS unpredictable behavior for multiple apps handling a single url scheme, users can end up opening an `ethereum:` link in an app that doesn not include a web3 browser and will not be able to handle the deeplink correctly. ## Specification ### Syntax Web3 browser URLs contain "dapp" in their schema (protocol) part and are constructed as follows: request = "dapp" ":" [chain_id "@"] dapp_url chain_id = 1*DIGIT dapp_url = URI ### Semantics `chain_id` is optional and it is a parameter for the browser to automatically select the corresponding chain ID as specified in [EIP-155](/EIPS/eip-155) before opening the dApp. `dapp_url` is a valid [RFC3986](https://www.ietf.org/rfc/rfc3986.txt) URI This a complete example url: `dapp:1@peepeth.com/brunobar79?utm_source=github` which will open the web3 browser, select `mainnet` (chain_id = 1) and then navigate to: `https://peepeth.com/brunobar79?utm_source=github` ## Rationale The proposed format attempts to solve the problem of vendor specific protocols for web3 browsers, avoiding conflicts with the existing 'ethereum:' URL scheme while also adding an extra feature: `chain_id` which will help dApps to be accessed with the right network preselected, optionally extracting away that complexity from end users. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 13 Jan 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1710 https://eips.ethereum.org/EIPS/eip-1710 Hardfork Meta: Petersburg Meta/ ## Abstract This meta-EIP specifies the changes included in the Ethereum hardfork that removes [EIP-1283](/EIPS/eip-1283) from [Constantinople](/EIPS/eip-1013). ## Specification - Codename: Petersburg - Aliases: St. Petersfork, Peter's Fork, Constantinople Fix - Activation: - `Block >= 7_280_000` on the Ethereum Mainnet - `Block >= 4_939_394` on the Ropsten testnet - `Block >= 10_255_201` on the Kovan testnet - `Block >= 4_321_234` on the Rinkeby testnet - `Block >= 0` on the Görli testnet - Removed EIPs: - [EIP-1283](/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps If `Petersburg` and `Constantinople` are applied at the same block, `Petersburg` takes precedence: with the net effect of EIP-1283 being _disabled_. If `Petersburg` is defined with an earlier block number than `Constantinople`, then there is _no immediate effect_ from the `Petersburg` fork. However, when `Constantinople` is later activated, EIP-1283 should be _disabled_. ## References 1. The list above includes the EIPs that had to be removed from Constantinople due to a [potential reentrancy attack vector](https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9). Removing this was agreed upon at the [All-Core-Devs call #53 in January 2019](https://github.com/ethereum/pm/issues/70). 2. https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/ ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 21 Jan 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1716 https://eips.ethereum.org/EIPS/eip-1716 Smart Contract Interface for Licences Standards Track/ERC ## Abstract This Ethereum Improvement Proposal (EIP) proposes an Ethereum standard for the issuance of licences, permits and grants (Licences). A Licence is a limited and temporary authority, granted to a natural (e.g. you) or legal person (e.g. a corporation), to do something that would otherwise be unlawful pursuant to a legal framework. A public Licence is granted by the government, directly (e.g. by the New South Wales Department of Primary Industries, Australia) or indirectly (e.g. by an agent operating under the government’s authority), and derives its authority from legislation, though this is often practically achieved via delegated legislation such as regulations. This can be contrasted to a private licence – for example, the licence you grant to a visitor who comes onto your property. A Licence has the following properties: * granted personally to the licencee (Licencee), though it may be transferrable to another person or company; * conferring a temporary right to the Licencee to own, use or do something that would otherwise be prohibited, without conferring any property interest in the underlying thing. For example, you may be granted a licence to visit a national park without acquiring any ownership in or over the park itself; * allowing the government authority responsible for the Licence to amend, revoke, renew, suspend or deny the issuance of the Licence, or to impose conditions or penalties for non-compliance; and * usually issued only after the payment of a fee or the meeting of some criteria. Additionally, a Licence may be granted in respect of certain information. For example, a Licence may be issued in respect of a vehicle registration number and attaching to that specific registered vehicle. ## Motivation Governments are responsible for the issuance and management of Licences. However, maintaining and sharing this data can be complicated and inefficient. The granting of Licences usually requires the filing of paper-based application forms, manual oversight of applicable legislation and data entry into registries, as well as the issuance of paper based Licences. If individuals wish to sight information on Licence registries, they often need to be present at the government office and complete further paper-based enquiry forms in order to access that data (if available publicly). This EIP seeks to define a standard that will allow for the granting and/or management of Licences via Ethereum smart contracts. The motivation is, in essence, to address the inefficiencies inherent in current licencing systems. ## Specification ### Methods **NOTES**: - The following specifications use syntax from Solidity `0.4.17` (or above) - Callers MUST handle `false` from `returns (bool success)`. Callers MUST NOT assume that `false` is never returned! #### name Returns the name of the permit - e.g. `"MyPermit"`. ``` js function name() public view returns (string); ``` #### totalSupply Returns the total permit supply. ``` js function totalSupply() public view returns (uint256); ``` #### grantAuthority Adds an ethereum address to a white list of addresses that have authority to modify a permit. ``` js function grantAuthority(address who) public; ``` #### revokeAuthority Removes an ethereum address from a white list of addresses that have authority to modify a permit. ``` js function revokeAuthority(address who) public; ``` #### hasAuthority Checks to see if the address has authority to grant or revoke permits. ``` js function hasAuthority(address who) public view; ``` #### issue Issues an ethereum address a permit between the specified date range. ``` js function issue(address who, uint256 validFrom, uint256 validTo) public; ``` #### revoke Revokes a permit from an ethereum address. ``` js function revoke(address who) public; ``` #### hasValid Checks to see if an ethereum address has a valid permit. ``` js function hasValid(address who) external view returns (bool); ``` #### purchase Allows a user to self procure a licence. ``` js function purchase(uint256 validFrom, uint256 validTo) external payable; ``` ## Rationale The use of smart contracts to apply for, renew, suspend and revoke Licences will free up much needed government resources and allow for the more efficient management of Licences. The EIP also seeks to improve the end user experience of the Licence system. In an era of open government, there is also an increased expectation that individuals will be able to easily access Licence registries, and that the process will be transparent and fair. By creating an EIP, we hope to increase the use of Ethereum based and issued Licences, which will address these issues. The Ethereum blockchain is adaptable to various Licences and government authorities. It will also be easily translatable into other languages and can be used by other governmental authorities across the world. Moreover, a blockchain will more effectively protect the privacy of Licence-holders’ data, particularly at a time of an ever-increasing volume of government data breaches. The EIP has been developed following the review of a number of licensing regulations at the national and state level in Australia. The review allowed the identification of the common licence requirements and criteria for incorporation into the EIP. We have included these in the proposed standard but seek feedback on whether these criteria are sufficient and universal. ## Test Cases A real world example of a Licence is a permit required to camp in a national park in Australia (e.g. Kakadu national park in the Northern Territory of Australia) under the Environment Protection and Biodiversity Conservation Regulations 2000 (Cth) (EPBC Act) and the Environment Protection and Biodiversity Conservation Regulations 2000 (the Regulations). Pursuant to the EPBC Act and the Regulations, the Director of National Parks oversees a camping permit system, which is intended to help regulate certain activities in National Parks. Permits allowing access to National Parks can be issued to legal or natural persons if the applicant has met certain conditions. The current digital portal and application form to camp at Kakadu National Park (the Application) can be accessed at: https://www.environment.gov.au/system/files/resources/b3481ed3-164b-4e72-a9f8-91fc987d90e7/files/kakadu-camping-permit-form-19jan2015-pdf.pdf The user must provide the following details when making an Application: * The full name and contact details of each person to whom the permit is to be issued; * If the applicant is a company or other incorporated body: o the name, business address and postal address of the company or incorporated body; o if the applicant is a company— * the full name of each of the directors of the company; * the full name and contact details of the person completing the application form; * the ACN or ABN of the company or other incorporated body (if applicable); * Details of the proposed camping purpose (e.g. private camping, school group, etc.); * A start date and duration for the camping (up to the maximum duration allowed by law); * Number of campers (up to the maximum allowed by law); * All other required information not essential to the issuance of the Licence (e.g. any particular medical needs of the campers); and * Fees payable depending on the site, duration and number of campers. The Regulations also set out a number of conditions that must be met by licensees when the permit has been issued. The Regulations allow the Director of National Parks to cancel, renew or transfer the licence. The above workflow could be better performed by way of a smart contract. The key criteria required as part of this process form part of the proposed Ethereum standard. We have checked this approach by also considering the issuance of a Commercial Fishing Licence under Part 8 “Licensing and other commercial fisheries management” of the Fisheries Management (General) Regulation 2010 (NSW) (Fisheries Regulations) made pursuant to the Fisheries Management Act 1994 (NSW) (Fisheries Act). ## Implementation The issuance and ownership of a Licence can be digitally represented on the Ethereum blockchain. Smart contracts can be used to embed regulatory requirements with respect to the relevant Licence in the blockchain. The Licence would be available electronically in the form of a token. This might be practically represented by a QR code, for example, displaying the current Licence information. The digital representation of the Licence would be stored in a digital wallet, typically an application on a smartphone or tablet computer. The proposed standard allows issuing authorities or regulators to amend, revoke or deny Licences from time to time, with the result of their determinations reflected in the Licence token in near real-time. Licence holders will therefore be notified almost instantly of any amendments, revocations or issues involving their Licence. ## Interface ### Solidity Example ```solidity interface EIP1753 { function grantAuthority(address who) external; function revokeAuthority(address who) external; function hasAuthority(address who) external view returns (bool); function issue(address who, uint256 from, uint256 to) external; function revoke(address who) external; function hasValid(address who) external view returns (bool); function purchase(uint256 validFrom, uint256 validTo) external payable; } pragma solidity ^0.5.3; contract EIP is EIP1753 { string public name = "Kakadu National Park Camping Permit"; uint256 public totalSupply; address private _owner; mapping(address => bool) private _authorities; mapping(address => Permit) private _holders; struct Permit { address issuer; uint256 validFrom; uint256 validTo; } constructor() public { _owner = msg.sender; } function grantAuthority(address who) public onlyOwner() { _authorities[who] = true; } function revokeAuthority(address who) public onlyOwner() { delete _authorities[who]; } function hasAuthority(address who) public view returns (bool) { return _authorities[who] == true; } function issue(address who, uint256 start, uint256 end) public onlyAuthority() { _holders[who] = Permit(_owner, start, end); totalSupply += 1; } function revoke(address who) public onlyAuthority() { delete _holders[who]; } function hasValid(address who) external view returns (bool) { return _holders[who].validFrom > now && _holders[who].validTo < now; } function purchase(uint256 validFrom, uint256 validTo) external payable { require(msg.value == 1 ether, "Incorrect fee"); issue(msg.sender, validFrom, validTo); } modifier onlyOwner() { require(msg.sender == _owner, "Only owner can perform this function"); _; } modifier onlyAuthority() { require(hasAuthority(msg.sender), "Only an authority can perform this function"); _; } } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 06 Feb 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1753 https://eips.ethereum.org/EIPS/eip-1753 Scoped Approval Interface Standards Track/ERC https://github.com/ethereum/EIPs/issues/1761 ## Simple Summary A standard interface to permit restricted approval in token contracts by defining "scopes" of one or more Token IDs. ## Abstract This interface is designed for use with token contracts that have an "ID" domain, such as ERC-1155 or ERC-721. This enables restricted approval of one or more Token IDs to a specific "scope". When considering a smart contract managing tokens from multiple different domains, it makes sense to limit approvals to those domains. Scoped approval is a generalization of this idea. Implementors can define scopes as needed. Sample use cases for scopes: * A company may represent its fleet of vehicles on the blockchain and it could create a scope for each regional office. * Game developers could share an [ERC-1155](/EIPS/eip-1155) contract where each developer manages tokens under a specified scope. * Tokens of different value could be split into separate scopes. High-value tokens could be kept in smaller separate scopes while low-value tokens might be kept in a shared scope. Users would approve the entire low-value token scope to a third-party smart contract, exchange, or other application without concern about losing their high-value tokens in the event of a problem. ## Motivation It may be desired to restrict approval in some applications. Restricted approval can prevent losses in cases where users do not audit the contracts they're approving. No standard API is supplied to manage scopes as this is implementation specific. Some implementations may opt to offer a fixed number of scopes, or assign a specific set of scopes to certain types. Other implementations may open up scope configuration to its users and offer methods to create scopes and assign IDs to them. # Specification ```solidity pragma solidity ^0.5.2; /** Note: The ERC-165 identifier for this interface is 0x30168307. */ interface ScopedApproval { /** @dev MUST emit when approval changes for scope. */ event ApprovalForScope(address indexed _owner, address indexed _operator, bytes32 indexed _scope, bool _approved); /** @dev MUST emit when the token IDs are added to the scope. By default, IDs are in no scope. The range is inclusive: _idStart, _idEnd, and all IDs in between have been added to the scope. _idStart must be lower than or equal to _idEnd. */ event IdsAddedToScope(uint256 indexed _idStart, uint256 indexed _idEnd, bytes32 indexed _scope); /** @dev MUST emit when the token IDs are removed from the scope. The range is inclusive: _idStart, _idEnd, and all IDs in between have been removed from the scope. _idStart must be lower than or equal to _idEnd. */ event IdsRemovedFromScope(uint256 indexed _idStart, uint256 indexed _idEnd, bytes32 indexed _scope); /** @dev MUST emit when a scope URI is set or changes. URIs are defined in RFC 3986. The URI MUST point a JSON file that conforms to the "Scope Metadata JSON Schema". */ event ScopeURI(string _value, bytes32 indexed _scope); /** @notice Returns the number of scopes that contain _id. @param _id The token ID @return The number of scopes containing the ID */ function scopeCountForId(uint256 _id) public view returns (uint32); /** @notice Returns a scope that contains _id. @param _id The token ID @param _scopeIndex The scope index to query (valid values are 0 to scopeCountForId(_id)-1) @return The Nth scope containing the ID */ function scopeForId(uint256 _id, uint32 _scopeIndex) public view returns (bytes32); /** @notice Returns a URI that can be queried to get scope metadata. This URI should return a JSON document containing, at least the scope name and description. Although supplying a URI for every scope is recommended, returning an empty string "" is accepted for scopes without a URI. @param _scope The queried scope @return The URI describing this scope. */ function scopeUri(bytes32 _scope) public view returns (string memory); /** @notice Enable or disable approval for a third party ("operator") to manage the caller's tokens in the specified scope. @dev MUST emit the ApprovalForScope event on success. @param _operator Address to add to the set of authorized operators @param _scope Approval scope (can be identified by calling scopeForId) @param _approved True if the operator is approved, false to revoke approval */ function setApprovalForScope(address _operator, bytes32 _scope, bool _approved) external; /** @notice Queries the approval status of an operator for a given owner, within the specified scope. @param _owner The owner of the Tokens @param _operator Address of authorized operator @param _scope Scope to test for approval (can be identified by calling scopeForId) @return True if the operator is approved, false otherwise */ function isApprovedForScope(address _owner, address _operator, bytes32 _scope) public view returns (bool); } ``` ## Scope Metadata JSON Schema This schema allows for localization. `{id}` and `{locale}` should be replaced with the appropriate values by clients. ```json { "title": "Scope Metadata", "type": "object", "required": ["name"], "properties": { "name": { "type": "string", "description": "Identifies the scope in a human-readable way.", }, "description": { "type": "string", "description": "Describes the scope to allow users to make informed approval decisions.", }, "localization": { "type": "object", "required": ["uri", "default", "locales"], "properties": { "uri": { "type": "string", "description": "The URI pattern to fetch localized data from. This URI should contain the substring `{locale}` which will be replaced with the appropriate locale value before sending the request." }, "default": { "type": "string", "description": "The locale of the default data within the base JSON" }, "locales": { "type": "array", "description": "The list of locales for which data is available. These locales should conform to those defined in the Unicode Common Locale Data Repository (http://cldr.unicode.org/)." } } } } } ``` ### Localization Metadata localization should be standardized to increase presentation uniformity across all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a `localization` attribute, its content may be used to provide localized values for fields that need it. The `localization` attribute should be a sub-object with three attributes: `uri`, `default` and `locales`. If the string `{locale}` exists in any URI, it MUST be replaced with the chosen locale by all client software. ## Rationale The initial design was proposed as an extension to ERC-1155: [Discussion Thread - Comment 1](https://github.com/ethereum/EIPs/issues/1155#issuecomment-459505728). After some discussion: [Comment 2](https://github.com/ethereum/EIPs/issues/1155#issuecomment-460603439) and suggestions by the community to implement this approval mechanism in an external contract [Comment 3](https://github.com/ethereum/EIPs/issues/1155#issuecomment-461758755), it was decided that as an interface standard, this design would allow many different token standards such as ERC-721 and ERC-1155 to implement scoped approvals without forcing the system into all implementations of the tokens. ### Metadata JSON The Scope Metadata JSON Schema was added in order to support human-readable scope names and descriptions in more than one language. ## References **Standards** - [ERC-1155 Multi Token Standard](/EIPS/eip-1155) - [ERC-165 Standard Interface Detection](/EIPS/eip-165) - [JSON Schema](https://json-schema.org/) **Implementations** - [Enjin Coin](https://enjincoin.io) ([github](https://github.com/enjin)) **Articles & Discussions** - [GitHub - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1761) - [GitHub - ERC-1155 Discussion Thread](https://github.com/ethereum/EIPs/issues/1155) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 18 Feb 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1761 https://eips.ethereum.org/EIPS/eip-1761 GraphQL interface to Ethereum node data Standards Track/Interface https://ethereum-magicians.org/t/graphql-interface-to-ethereum-node-data/2710 ## Abstract This EIP specifies a GraphQL schema for accessing data stored on an Ethereum node. It aims to provide a complete replacement to the read-only information exposed via the present JSON-RPC interface, while improving on usability, consistency, efficiency, and future-proofing. ## Motivation The current JSON-RPC interface for Ethereum nodes has a number of shortcomings. It's informally and incompletely specified in areas, which has led to incompatibilities around issues such as representation of empty byte strings ("" vs "0x" vs "0x0"), and it has to make educated guesses about the data a user will request, which often leads to unnecessary work. For example, the `totalDifficulty` field is stored separately from the block header in common Ethereum node implementations, and many callers do not require this field. However, every call to `eth_getBlock` still retrieves this field, requiring a separate disk read, because the RPC server has no way of knowing if the user requires this field or not. Similarly, transaction receipts in go-ethereum are stored on disk as a single binary blob for each block. Fetching a receipt for a single transaction requires fetching and deserializing this blob, then finding the relevant entry and returning it; this is accomplished by the `eth_getTransactionReceipt` API call. A common task for API consumers is to fetch all the receipts in a block; as a result, node implementations end up fetching and deserializing the same data repeatedly, leading to `O(n^2)` effort to fetch all transaction receipts from a block instead of `O(n)`. Some of these issues could be fixed with changes to the existing JSON-RPC interface, at the cost of complicating the interface somewhat. Instead, we propose adopting a standard query language, GraphQL, which facilitates more efficient API implementations, while also increasing flexibility. ## Prior Art Nick Johnson and [EthQL](https://github.com/ConsenSys/ethql) independently developed a GraphQL schema for node data. Once the parties were made aware of the shared effort, they made efforts to bring their schemas into alignment. The current schema proposed in this EIP is derived primarily from the EthQL schema. ## Specification ### Node API Compatible nodes MUST provide a GraphQL endpoint available over HTTP. This SHOULD be offered on port 8547 by default. The path to the GraphQL endpoint SHOULD be '/graphql'. Compatible nodes MAY offer a GraphiQL interactive query explorer on the root path ('/'). ### Schema The GraphQL schema for this service is defined as follows: ``` # Bytes32 is a 32 byte binary string, represented as 0x-prefixed hexadecimal. scalar Bytes32 # Address is a 20 byte Ethereum address, represented as 0x-prefixed hexadecimal. scalar Address # Bytes is an arbitrary length binary string, represented as 0x-prefixed hexadecimal. # An empty byte string is represented as '0x'. Byte strings must have an even number of hexadecimal nybbles. scalar Bytes # BigInt is a large integer. Input is accepted as either a JSON number or as a string. # Strings may be either decimal or 0x-prefixed hexadecimal. Output values are all # 0x-prefixed hexadecimal. scalar BigInt # Long is a 64 bit unsigned integer. scalar Long schema { query: Query mutation: Mutation } # Account is an Ethereum account at a particular block. type Account { # Address is the address owning the account. address: Address! # Balance is the balance of the account, in wei. balance: BigInt! # TransactionCount is the number of transactions sent from this account, # or in the case of a contract, the number of contracts created. Otherwise # known as the nonce. transactionCount: Long! # Code contains the smart contract code for this account, if the account # is a (non-self-destructed) contract. code: Bytes! # Storage provides access to the storage of a contract account, indexed # by its 32 byte slot identifier. storage(slot: Bytes32!): Bytes32! } # Log is an Ethereum event log. type Log { # Index is the index of this log in the block. index: Int! # Account is the account which generated this log - this will always # be a contract account. account(block: Long): Account! # Topics is a list of 0-4 indexed topics for the log. topics: [Bytes32!]! # Data is unindexed data for this log. data: Bytes! # Transaction is the transaction that generated this log entry. transaction: Transaction! } # Transaction is an Ethereum transaction. type Transaction { # Hash is the hash of this transaction. hash: Bytes32! # Nonce is the nonce of the account this transaction was generated with. nonce: Long! # Index is the index of this transaction in the parent block. This will # be null if the transaction has not yet been mined. index: Int # From is the account that sent this transaction - this will always be # an externally owned account. from(block: Long): Account! # To is the account the transaction was sent to. This is null for # contract-creating transactions. to(block: Long): Account # Value is the value, in wei, sent along with this transaction. value: BigInt! # GasPrice is the price offered to miners for gas, in wei per unit. gasPrice: BigInt! # Gas is the maximum amount of gas this transaction can consume. gas: Long! # InputData is the data supplied to the target of the transaction. inputData: Bytes! # Block is the block this transaction was mined in. This will be null if # the transaction has not yet been mined. block: Block # Status is the return status of the transaction. This will be 1 if the # transaction succeeded, or 0 if it failed (due to a revert, or due to # running out of gas). If the transaction has not yet been mined, this # field will be null. status: Long # GasUsed is the amount of gas that was used processing this transaction. # If the transaction has not yet been mined, this field will be null. gasUsed: Long # CumulativeGasUsed is the total gas used in the block up to and including # this transaction. If the transaction has not yet been mined, this field # will be null. cumulativeGasUsed: Long # CreatedContract is the account that was created by a contract creation # transaction. If the transaction was not a contract creation transaction, # or it has not yet been mined, this field will be null. createdContract(block: Long): Account # Logs is a list of log entries emitted by this transaction. If the # transaction has not yet been mined, this field will be null. logs: [Log!] } # BlockFilterCriteria encapsulates log filter criteria for a filter applied # to a single block. input BlockFilterCriteria { # Addresses is list of addresses that are of interest. If this list is # empty, results will not be filtered by address. addresses: [Address!] # Topics list restricts matches to particular event topics. Each event has a list # of topics. Topics matches a prefix of that list. An empty element array matches any # topic. Non-empty elements represent an alternative that matches any of the # contained topics. # # Examples: # - [] or nil matches any topic list # - [[A]] matches topic A in first position # - [[], [B]] matches any topic in first position, B in second position # - [[A], [B]] matches topic A in first position, B in second position # - [[A, B]], [C, D]] matches topic (A OR B) in first position, (C OR D) in second position topics: [[Bytes32!]!] } # Block is an Ethereum block. type Block { # Number is the number of this block, starting at 0 for the genesis block. number: Long! # Hash is the block hash of this block. hash: Bytes32! # Parent is the parent block of this block. parent: Block # Nonce is the block nonce, an 8 byte sequence determined by the miner. nonce: Bytes! # TransactionsRoot is the keccak256 hash of the root of the trie of transactions in this block. transactionsRoot: Bytes32! # TransactionCount is the number of transactions in this block. if # transactions are not available for this block, this field will be null. transactionCount: Int # StateRoot is the keccak256 hash of the state trie after this block was processed. stateRoot: Bytes32! # ReceiptsRoot is the keccak256 hash of the trie of transaction receipts in this block. receiptsRoot: Bytes32! # Miner is the account that mined this block. miner(block: Long): Account! # ExtraData is an arbitrary data field supplied by the miner. extraData: Bytes! # GasLimit is the maximum amount of gas that was available to transactions in this block. gasLimit: Long! # GasUsed is the amount of gas that was used executing transactions in this block. gasUsed: Long! # Timestamp is the unix timestamp at which this block was mined. timestamp: BigInt! # LogsBloom is a bloom filter that can be used to check if a block may # contain log entries matching a filter. logsBloom: Bytes! # MixHash is the hash that was used as an input to the PoW process. mixHash: Bytes32! # Difficulty is a measure of the difficulty of mining this block. difficulty: BigInt! # TotalDifficulty is the sum of all difficulty values up to and including # this block. totalDifficulty: BigInt! # OmmerCount is the number of ommers (AKA uncles) associated with this # block. If ommers are unavailable, this field will be null. ommerCount: Int # Ommers is a list of ommer (AKA uncle) blocks associated with this block. # If ommers are unavailable, this field will be null. Depending on your # node, the transactions, transactionAt, transactionCount, ommers, # ommerCount and ommerAt fields may not be available on any ommer blocks. ommers: [Block] # OmmerAt returns the ommer (AKA uncle) at the specified index. If ommers # are unavailable, or the index is out of bounds, this field will be null. ommerAt(index: Int!): Block # OmmerHash is the keccak256 hash of all the ommers (AKA uncles) # associated with this block. ommerHash: Bytes32! # Transactions is a list of transactions associated with this block. If # transactions are unavailable for this block, this field will be null. transactions: [Transaction!] # TransactionAt returns the transaction at the specified index. If # transactions are unavailable for this block, or if the index is out of # bounds, this field will be null. transactionAt(index: Int!): Transaction # Logs returns a filtered set of logs from this block. logs(filter: BlockFilterCriteria!): [Log!]! # Account fetches an Ethereum account at the current block's state. account(address: Address!): Account # Call executes a local call operation at the current block's state. call(data: CallData!): CallResult # EstimateGas estimates the amount of gas that will be required for # successful execution of a transaction at the current block's state. estimateGas(data: CallData!): Long! } # CallData represents the data associated with a local contract call. # All fields are optional. input CallData { # From is the address making the call. from: Address # To is the address the call is sent to. to: Address # Gas is the amount of gas sent with the call. gas: Long # GasPrice is the price, in wei, offered for each unit of gas. gasPrice: BigInt # Value is the value, in wei, sent along with the call. value: BigInt # Data is the data sent to the callee. data: Bytes } # CallResult is the result of a local call operation. type CallResult { # Data is the return data of the called contract. data: Bytes! # GasUsed is the amount of gas used by the call, after any refunds. gasUsed: Long! # Status is the result of the call - 1 for success or 0 for failure. status: Long! } # FilterCriteria encapsulates log filter criteria for searching log entries. input FilterCriteria { # FromBlock is the block at which to start searching, inclusive. Defaults # to the latest block if not supplied. fromBlock: Long # ToBlock is the block at which to stop searching, inclusive. Defaults # to the latest block if not supplied. toBlock: Long # Addresses is a list of addresses that are of interest. If this list is # empty, results will not be filtered by address. addresses: [Address!] # Topics list restricts matches to particular event topics. Each event has a list # of topics. Topics matches a prefix of that list. An empty element array matches any # topic. Non-empty elements represent an alternative that matches any of the # contained topics. # # Examples: # - [] or nil matches any topic list # - [[A]] matches topic A in first position # - [[], [B]] matches any topic in first position, B in second position # - [[A], [B]] matches topic A in first position, B in second position # - [[A, B]], [C, D]] matches topic (A OR B) in first position, (C OR D) in second position topics: [[Bytes32!]!] } # SyncState contains the current synchronisation state of the client. type SyncState{ # StartingBlock is the block number at which synchronisation started. startingBlock: Long! # CurrentBlock is the point at which synchronisation has presently reached. currentBlock: Long! # HighestBlock is the latest known block number. highestBlock: Long! # PulledStates is the number of state entries fetched so far, or null # if this is not known or not relevant. pulledStates: Long # KnownStates is the number of states the node knows of so far, or null # if this is not known or not relevant. knownStates: Long } # Pending represents the current pending state. type Pending { # TransactionCount is the number of transactions in the pending state. transactionCount: Int! # Transactions is a list of transactions in the current pending state. transactions: [Transaction!] # Account fetches an Ethereum account for the pending state. account(address: Address!): Account # Call executes a local call operation for the pending state. call(data: CallData!): CallResult # EstimateGas estimates the amount of gas that will be required for # successful execution of a transaction for the pending state. estimateGas(data: CallData!): Long! } type Query { # Block fetches an Ethereum block by number or by hash. If neither is # supplied, the most recent known block is returned. block(number: Long, hash: Bytes32): Block # Blocks returns all the blocks between two numbers, inclusive. If # to is not supplied, it defaults to the most recent known block. blocks(from: Long!, to: Long): [Block!]! # Pending returns the current pending state. pending: Pending! # Transaction returns a transaction specified by its hash. transaction(hash: Bytes32!): Transaction # Logs returns log entries matching the provided filter. logs(filter: FilterCriteria!): [Log!]! # GasPrice returns the node's estimate of a gas price sufficient to # ensure a transaction is mined in a timely fashion. gasPrice: BigInt! # ProtocolVersion returns the current wire protocol version number. protocolVersion: Int! # Syncing returns information on the current synchronisation state. syncing: SyncState } type Mutation { # SendRawTransaction sends an RLP-encoded transaction to the network. sendRawTransaction(data: Bytes!): Bytes32! } ``` Nodes MAY offer a superset of this schema, by adding new fields or types. Experimental or client-specific fields MUST be prefixed with '_client_' (eg, '_geth_' or '_parity_'). Unprefixed fields MUST be specified in a new EIP that extends this one. ## Rationale Ethereum nodes have been moving away from providing read-write functionality such as transaction and message signing, and from other services such as code compilation, in favor of a more 'unix-like' approach where each task is performed by a dedicated process. We have thus specified a core set of types and fields that reflects this trend, leaving out functionality that is presently, or intended to be, deprecated: - `eth_compile*` calls are deprecated, and hence not provided here. - `eth_accounts`, `eth_sign`, and `eth_sendTransaction` are considered by many to be deprecated, and are not provided here; callers should use local accounts or a separate signing daemon instead. Further, two areas of the current API interface have been omitted for simplicity in this initial standard, with the intention that they will be defined in a later EIP: - Filters will require use of GraphQL subscriptions, and require careful consideration around the desire for nodes without local per-caller state. - Mining functionality is less-used and benefits less from reimplementation in GraphQL, and should be specified in a separate EIP. ## Backwards Compatibility This schema implements the bulk of the current read-only functionality provided by the JSON-RPC node interface. Existing RPC calls can be mapped to GraphQL queries as follows: | RPC | Status | Description | | --- | ------ | ----------- | | eth_blockNumber | IMPLEMENTED | `{ block { number } }` | | eth_call | IMPLEMENTED | `{ call(data: { to: "0x...", data: "0x..." }) { data status gasUsed } }` | | eth_estimateGas | IMPLEMENTED | `{ estimateGas(data: { to: "0x...", data: "0x..." }) }` | | eth_gasPrice | IMPLEMENTED | `{ gasPrice }` | | eth_getBalance | IMPLEMENTED | `{ account(address: "0x...") { balance } }` | | eth_getBlockByHash | IMPLEMENTED | `{ block(hash: "0x...") { ... } }` | | eth_getBlockByNumber | IMPLEMENTED | `{ block(number: 123) { ... } }` | | eth_getBlockTransactionCountByHash | IMPLEMENTED | `{ block(hash: "0x...") { transactionCount } }` | | eth_getBlockTransactionCountByNumber | IMPLEMENTED | `{ block(number: x) { transactionCounnt } }` | | eth_getCode | IMPLEMENTED | `{ account(address: "0x...") { code } }` | | eth_getLogs | IMPLEMENTED | `{ logs(filter: { ... }) { ... } }` or `{ block(...) { logs(filter: { ... }) { ... } } }` | | eth_getStorageAt | IMPLEMENTED | `{ account(address: "0x...") { storage(slot: "0x...") } }` | | eth_getTransactionByBlockHashAndIndex | IMPLEMENTED | `{ block(hash: "0x...") { transactionAt(index: x) { ... } } }` | | eth_getTransactionByBlockNumberAndIndex | IMPLEMENTED | `{ block(number: n) { transactionAt(index: x) { ... } } }` | | eth_getTransactionByHash | IMPLEMENTED | `{ transaction(hash: "0x...") { ... } }` | | eth_getTransactionCount | IMPLEMENTED | `{ account(address: "0x...") { transactionCount } }` | | eth_getTransactionReceipt | IMPLEMENTED | `{ transaction(hash: "0x...") { ... } }` | | eth_getUncleByBlockHashAndIndex | IMPLEMENTED | `{ block(hash: "0x...") { ommerAt(index: x) { ... } } }` | | eth_getUncleByBlockNumberAndIndex | IMPLEMENTED | `{ block(number: n) { ommerAt(index: x) { ... } } }` | | eth_getUncleCountByBlockHash | IMPLEMENTED | `{ block(hash: "0x...") { ommerCount } }` | | eth_getUncleCountByBlockNumber | IMPLEMENTED | `{ block(number: x) { ommerCount } }` | | eth_protocolVersion | IMPLEMENTED | `{ protocolVersion }` | | eth_sendRawTransaction | IMPLEMENTED | `mutation { sendRawTransaction(data: data) }` | | eth_syncing | IMPLEMENTED | `{ syncing { ... } }` | | eth_getCompilers | NOT IMPLEMENTED | Compiler functionality is deprecated in JSON-RPC. | | eth_compileLLL | NOT IMPLEMENTED | Compiler functionality is deprecated in JSON-RPC. | | eth_compileSolidity | NOT IMPLEMENTED | Compiler functionality is deprecated in JSON-RPC. | | eth_compileSerpent | NOT IMPLEMENTED | Compiler functionality is deprecated in JSON-RPC. | | eth_newFilter | NOT IMPLEMENTED | Filter functionality may be specified in a future EIP. | | eth_newBlockFilter | NOT IMPLEMENTED | Filter functionality may be specified in a future EIP. | | eth_newPendingTransactionFilter | NOT IMPLEMENTED | Filter functionality may be specified in a future EIP. | | eth_uninstallFilter | NOT IMPLEMENTED | Filter functionality may be specified in a future EIP. | | eth_getFilterChanges | NOT IMPLEMENTED | Filter functionality may be specified in a future EIP. | | eth_getFilterLogs | NOT IMPLEMENTED | Filter functionality may be specified in a future EIP. | | eth_accounts | NOT IMPLEMENTED | Accounts functionality is not part of the core node API. | | eth_sign | NOT IMPLEMENTED | Accounts functionality is not part of the core node API. | | eth_sendTransaction | NOT IMPLEMENTED | Accounts functionality is not part of the core node API. | | eth_coinbase | NOT IMPLEMENTED | Mining functionality to be defined separately. | | eth_getWork | NOT IMPLEMENTED | Mining functionality to be defined separately. | | eth_hashRate | NOT IMPLEMENTED | Mining functionality to be defined separately. | | eth_mining | NOT IMPLEMENTED | Mining functionality to be defined separately. | | eth_submitHashrate | NOT IMPLEMENTED | Mining functionality to be defined separately. | | eth_submitWork | NOT IMPLEMENTED | Mining functionality to be defined separately. | For specific reasoning behind omitted functionality, see the Rationale section. ## Test Cases TBD. ## Implementation - Implemented and released in [Go-ethereum 1.9.0](https://github.com/ethereum/go-ethereum/releases/tag/v1.9.0) - Implemented and released in [Pantheon 1.1.1](https://github.com/PegaSysEng/pantheon/blob/master/CHANGELOG.md#111) - Work in progress in [Trinity](https://github.com/ethereum/trinity/issues/302) - Work in progress in [Parity](https://github.com/paritytech/parity-ethereum/issues/10933) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 14 Feb 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1767 https://eips.ethereum.org/EIPS/eip-1767 App Keys, application specific wallet accounts Standards Track/ERC https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 ## Simple Summary Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus potentially increasing privacy. They also allow to give more control to the applications developers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. This new accounts type can allow to significantly improve UX and permit new designs for applications of the crypto permissionned web. ## Abstract In a wallet, an user often holds most of her funds in her main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of cryptographic applications if a user has to manually confirm every action. Also often an user uses the same accounts across apps, which is a privacy and potentially also a security issue. We introduce here a new account type, app keys, which permits signing delegation and accounts isolation across applications for privacy and security. In this EIP, we provide a proposal on how to uniquely identify and authenticate each application, how to derive a master account (or app key) unique for the domain from an user private key (her root private key or any other private key of an account derived or not from her root one). This EIP aims at becoming a standard on how to derive keys specific to each application that can be regenerated from scratch without further input from the user if she restores her wallet and uses again the application for which this key was derived. These app keys can then be endowed a different set of permissions (through the requestPermission model introduced in [EIP-2255](/EIPS/eip-2255)). This will potentially allow an user to partly trust some apps to perform some crypto operations on their behalf without compromising any security with respect to her main accounts. ## Motivation Wallets developers have agreed on an HD derivation path for ethereum accounts using BIP32, BIP44, SLIP44, [(see the discussion here)](https://github.com/ethereum/EIPs/issues/84). Web3 wallets have implemented in a roughly similar way the rpc eth api. [EIP-1102](/EIPS/eip-1102) introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. However several limitations remain in order to allow for proper design and UX for crypto permissioned apps. Most of GUI based current wallets don't allow to: * being able to automatically and effortlessly use different keys / accounts for each apps, * being able to sign some app's action without prompting the user with the same level of security as sending funds from their main accounts, * being able to use throwable keys to improve anonymity, * effortlessly signing transactions for an app without broadcasting these while still being able to perform other transaction signing as usual from their main accounts, * All this while being fully restorable using the user's mnemonic or hardware wallet and the HD Path determined uniquely by the app's ens name. We try to overcome these limitations by introducing a new account's type, app keys, made to be used along side the existing main accounts. These new app keys can permit to give more power and flexibility to the crypto apps developers. This can allow to improve a lot the UX of crypto dapps and to create new designs that were not possible before leveraging the ability to create and handle many accounts, to presign messages and broadcast them later. These features were not compatible with the level of security we were requesting for main accounts that hold most of an user's funds. ## Specification ### Applications An app is a website (or other) that would like to request from a wallet to access a cryptographic key specifically derived for this usage. It can be any form of cryptography/identity relying application, Ethereum based but not only. Once connected to a wallet, an application can request to access an account derived exclusively for that application using the following algorithm. ### Private App Key generation algorithm We now propose an algorithm to generate application keys that: - are uniquely defined, with respect to the account that the user selected to generate these keys, - and thus can be isolated when changing the user account, allowing persona management (see next section), - are specific to each application, - can be fully restored from the user master seed mnemonic and the applications' names. #### Using different accounts as personas We allow the user to span a different set of application keys by changing the account selected to generate each key. Thus from the same master seed mnemonic, an user can use each of her account index to generate an alternative set of application keys. One can describe this as using different personas. This would allow potentially an user to fully isolate her interaction with a given app across personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different accounts to generate these. The app or domain, will not be aware that it is the same person and mnemonic behind both. If an application interacts with several main accounts of an user, one of these accounts, a master account can be used as persona and the others as auxiliary accounts. This EIP is agnostic about the way one generates the private keys used to span different app keys spaces. However for compatibility purposes and for clean disambiguation between personas and cryptocurrency accounts, a new EIP, distinct from this one but to be used alongside, will be proposed soon introducing clean persona generation and management. #### Applications' Unique Identifiers Each application is uniquely defined and authenticated by its origin, a domain string. It can be a Domain Name Service (DNS) name or, in the future, an Ethereum Name Service (ENS) name or IPFS hash. For Ipfs or swam origins, but we could probably use the ipfs or swarm addresses as origin or we could require those to be pointed at through an ENS entry and use the ENS address as origin, although this would mean that the content it refers to could change. It would thus allow for different security and updatibility models. We will probably require for protocol prefixes when using an ENS domain to point to an IPFS address: `ens://ipfs.snap.eth` #### Private App Key generation algorithm Using the domain name of an application, we generate a private key for each application (and per main account) : `const appKeyPrivKey = keccak256(privKey + originString)` where `+` is concatenation, `privKey` is the private key of the user's account selected to span the application key and `originString` represents the origin url from which the permission call to access the application key is originated from. This is exposed as an RPC method to allow any domain to request its own app key associated with the current requested account (if available): ``` const appKey = await provider.send({ method: 'wallet_getAppKeyForAccount', params: [address1] }); ``` See here for an implementation: https://github.com/MetaMask/eth-simple-keyring/blob/master/index.js#L169 #### App keys and Hierarchical Deterministic keys The app keys generated using the algorithm described in the previous section will not be BIP32 compliant. Therefore apps will not be able to create several app keys or use non-hardening and extended public keys techniques directly. They get a single private key (per origin, per persona). Yet they can use this as initial entropy to span a new HD tree and generate addresses that can be either hardened or not. Thus we should not be losing use cases. ## Rationale ### Sharing application keys across domains: While this does not explicit cover cases of sharing these app keys between pages on its own, this need can be met by composition: Since a domain would get a unique key per persona, and because domains can intercommunicate, one domain (app) could request another domain (signer) to perform its cryptographic operation on some data, with its appKey as a seed, potentially allowing new signing strategies to be added as easily as new websites. This could also pass it to domains that are loading specific signing strategies. This may sound dangerous at first, but if a domain represents a static hash of a trusted cryptographic function implementation, it could be as safe as calling any audited internal dependency. ### Privacy and the funding trail If all an application needs to do with its keys is to sign messages and it does not require funding, then this EIP allows for privacy through the use of distinct keys for each application with a simple deterministic standard compatible across wallets. However if these application keys require funding, there can be trail and the use of app keys would not fully solve the privacy problem there. Mixers or anonymous ways of funding an ethereum address (ring signatures) along with this proposal would guarantee privacy. Even if privacy is not solved fully without this anonymous funding method, we still need a way to easily create and restore different accounts/addresses for each application ## Backwards Compatibility From a wallet point of view, there does not seem to be compatibility issues since these are separate accounts from those that were used previously by wallets and they are supposed to be used along-side in synergy. However, for applications that associated in some way their users to their main accounts may want to reflect on if and how they would like to leverage the power offered by `app keys` to migrate to them and leverage on the new app designs they permit. ## Implementation Here is an early implementation of app keys for standard (non HW) MetaMask accounts. https://github.com/MetaMask/eth-simple-keyring/blob/6d12bd9d73adcccbe0b0c7e32a99d279085e2934/index.js#L139-L152 See here for a fork of MetaMask that implements app keys along side plugins: https://github.com/MetaMask/metamask-snaps-beta https://github.com/MetaMask/metamask-snaps-beta/wiki/Plugin-API ## Example use cases * signing transactions without broadcasting them https://github.com/MetaMask/metamask-extension/issues/3475 * token contract https://github.com/ethereum/EIPs/issues/85 * default account for dapps https://ethereum-magicians.org/t/default-accounts-for-dapps/904 * non wallet/crypto accounts [EIP1581: Non-wallet usage of keys derived from BIP32 trees](/EIPS/eip-1581) * state channel application * privacy solution * non custodian cross cryptocurrency exchange... ## Acknowledgements MetaMask team, Christian Lundkvist, Counterfactual team, Liam Horne, Erik Bryn, Richard Moore, Jeff Coleman. ## References ### HD and mnemonics #### BIPs * [BIP32: Hierarchical Deterministic Wallets:](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [BIP39: Mnemonic code for generating deterministic keys:](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) * [SLIP44: Registered coin types for BIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) #### Derivation path for eth * [Issue 84](https://github.com/ethereum/EIPs/issues/84) * [Issue 85](https://github.com/ethereum/EIPs/issues/85) * [EIP600 Ethereum purpose allocation for Deterministic Wallets](/EIPS/eip-600) * [EIP601 Ethereum hierarchy for deterministic wallets](/EIPS/eip-601) ### Previous proposals and discussions related to app keys * [Meta: we should value privacy more](https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475) * [EIP1102: Opt-in account exposure](/EIPS/eip-1102) * [EIP1581: Non-wallet usage of keys derived from BIP-32 trees](/EIPS/eip-1581) * [EIP1581: discussion](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) * [SLIP13: Authentication using deterministic hierarchy](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 20 Feb 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1775 https://eips.ethereum.org/EIPS/eip-1775 Rename opcodes for clarity Standards Track/Interface https://ethereum-magicians.org/t/eip-1803-rename-opcodes-for-clarity/3345 ## Abstract Rename the `BALANCE`, `SHA3`, `NUMBER`, `GASLIMIT`, `GAS` and `INVALID` opcodes to reflect their true meaning. ## Specification Rename the opcodes as follows: - `BALANCE` (`0x31`) to `EXTBALANCE` to be in line with `EXTCODESIZE`, `EXTCODECOPY` and `EXTCODEHASH` - `SHA3` (`0x20`) to `KECCAK256` - `NUMBER` (`0x43`) to `BLOCKNUMBER` - `GASLIMIT` (`0x45`) to `BLOCKGASLIMIT` to avoid confusion with the gas limit of the transaction - `GAS` (`0x5a`) to `GASLEFT` to be clear what it refers to - `INVALID` (`0xfe`) to `ABORT` to clearly articulate when someone refers this opcode as opposed to "any invalid opcode" ## Backwards Compatibility This has no effect on any code. It can influence what mnemonics assemblers will use. ## Implementation Not applicable. ## References [EIP-6](/EIPS/eip-6) previously renamed `SUICIDE` (`0xff`) to `SELFDESTRUCT`. Renaming `SHA3` was previously proposed by [EIP-59](https://github.com/ethereum/EIPs/issues/59). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 28 Jul 2017 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1803 https://eips.ethereum.org/EIPS/eip-1803 Ethereum Verifiable Claims Standards Track/ERC https://ethereum-magicians.org/t/erc-1812-ethereum-verifiable-claims/2814 # Ethereum Verifiable Claims ## Simple Summary Reusable Verifiable Claims using [EIP 712 Signed Typed Data](/EIPS/eip-712). ## Abstract A new method for Off-Chain Verifiable Claims built on [EIP-712](/EIPS/eip-712). These Claims can be issued by any user with a EIP 712 compatible web3 provider. Claims can be stored off chain and verified on-chain by Solidity Smart Contracts, State Channel Implementations or off-chain libraries. ## Motivation Reusable Off-Chain Verifiable Claims provide an important piece of integrating smart contracts with real world organizational requirements such as meeting regulatory requirements such as KYC, GDPR, Accredited Investor rules etc. [ERC-735](https://github.com/ethereum/EIPs/issues/735) and [ERC-780](https://github.com/ethereum/EIPs/issues/780) provide methods of making claims that live on chain. This is useful for some particular use cases, where some claim about an address must be verified on chain. In most cases though it is both dangerous and in some cases illegal (according to EU GDPR rules for example) to record Identity Claims containing Personal Identifying Information (PII) on an immutable public database such as the Ethereum blockchain. The W3C [Verifiable Claims Data Model and Representations](https://www.w3.org/TR/verifiable-claims-data-model/) as well as uPorts [Verification Message Spec](https://developer.uport.me/messages/verification) are proposed off-chain solutions. While built on industry standards such as [JSON-LD](https://json-ld.org) and [JWT](https://jwt.io) neither of them are easy to integrate with the Ethereum ecosystem. [EIP-712](/EIPS/eip-712) introduces a new method of signing off chain Identity data. This provides both a data format based on Solidity ABI encoding that can easily be parsed on-chain an a new JSON-RPC call that is easily supported by existing Ethereum wallets and Web3 clients. This format allows reusable off-chain Verifiable Claims to be cheaply issued to users, who can present them when needed. ## Prior Art Verified Identity Claims such as those proposed by [uPort](https://developer.uport.me/messages/verification) and [W3C Verifiable Claims Working Group](https://www.w3.org/2017/vc/WG/) form an important part of building up reusable identity claims. [ERC-735](https://github.com/ethereum/EIPs/issues/735) and [ERC-780](https://github.com/ethereum/EIPs/issues/780) provide on-chain storage and lookups of Verifiable Claims. ## Specification ### Claims Claims can be generalized like this: > Issuer makes the claim that Subject is something or has some attribute and value. Claims should be deterministic, in that the same claim signed multiple times by the same signer. ### Claims data structure Each claim should be typed based on its specific use case, which EIP 712 lets us do effortlessly. But there are 3 minimal attributes required of the claims structure. * `subject` the subject of the claim as an `address` (who the claim is about) * `validFrom` the time in seconds encoded as a `uint256` of start of validity of claim. In most cases this would be the time of issuance, but some claims may be valid in the future or past. * `validTo` the time in seconds encoded as a `uint256` of when the validity of the claim expires. If you intend for the claim not to expire use `0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff`. The basic minimal claim data structure as a Solidity struct: ```solidity struct [CLAIM TYPE] { address subject; uint256 validFrom; uint256 validTo; } ``` The CLAIM TYPE is the actual name of the claim. While not required, in most cases use the taxonomy developed by [schema.org](https://schema.org/docs/full.html) which is also commonly used in other Verifiable Claims formats. Example claim that issuer knows a subject: ```solidity struct Know { address subject; uint256 validFrom; uint256 validTo; } ``` ### Presenting a Verifiable Claim #### Verifying Contract When defining Verifiable Claims formats a Verifying Contract should be created with a public `verify()` view function. This makes it very easy for other smart contracts to verify a claim correctly. It also provides a convenient interface for web3 and state channel apps to verify claims securely. ```solidity function verifyIssuer(Know memory claim, uint8 v, bytes32 r, bytes32 s) public returns (address) { bytes32 digest = keccak256( abi.encodePacked( "\x19\x01", DOMAIN_SEPARATOR, hash(claim) ) ); require( (claim.validFrom >= block.timestamp) && (block.timestamp < claim.validTo) , "invalid issuance timestamps"); return ecrecover(digest, v, r, s); } ``` #### Calling a SmartContract function Verifiable Claims can be presented to a solidity function call as it’s struct together with the `v`, `r` and `s` signature components. ```solidity function vouch(Know memory claim, uint8 v, bytes32 r, bytes32 s) public returns (bool) { address issuer = verifier.verifyIssuer(claim, v, r, s); require(issuer !== '0x0'); knows[issuer][claim.subject] = block.number; return true; } ``` #### Embedding a Verifiable Claim in another Signed Typed Data structure The Claim struct should be embedded in another struct together with the `v`, `r` and `s` signature parameters. ```solidity struct Know { address subject; uint256 validFrom; uint256 validTo; } struct VerifiableReference { Know delegate; uint8 v; bytes32 r; bytes32 s; } struct Introduction { address recipient; VerifiableReference issuer; } ``` Each Verifiable Claim should be individually verified together with the parent Signed Typed Data structure. Verifiable Claims issued to different EIP 712 Domains can be embedded within each other. #### State Channels This proposal will not show how to use Eth Verifiable Claims as part of a specific State Channel method. Any State Channel based on EIP712 should be able to include the embeddable Verifiable Claims as part of its protocol. This could be useful for exchanging private Identity Claims between the parties for regulatory reasons, while ultimately not posting them to the blockchain on conclusion of a channel. ### Key Delegation In most simple cases the issuer of a Claim is the signer of the data. There are cases however where signing should be delegated to an intermediary key. KeyDelegation can be used to implement off chain signing for smart contract based addresses, server side key rotation as well as employee permissions in complex business use cases. #### ERC1056 Signing Delegation [ERC-1056](/EIPS/eip-1056) provides a method for addresses to assign delegate signers. One of the primary use cases for this is that a smart contract can allow a key pair to sign on its behalf for a certain period. It also allows server based issuance tools to institute key rotation. To support this an additional `issuer` attribute can be added to the Claim Type struct. In this case the verification code should lookup the EthereumDIDRegistry to see if the signer of the data is an allowed signing delegate for the `issuer` The following is the minimal struct for a Claim containing an issuer: ```solidity struct [CLAIM TYPE] { address subject; address issuer; uint256 validFrom; uint256 validTo; } ``` If the `issuer` is specified in the struct In addition to performing the standard ERC712 verification the verification code MUST also verify that the signing address is a valid `veriKey` delegate for the address specified in the issuer. ```solidity registry.validDelegate(issuer, 'veriKey', recoveredAddress) ``` #### Embedded Delegation Proof There may be applications, in particularly where organizations want to allow delegates to issue claims about specific domains and types. For this purpose instead of the `issuer` we allow a special claim to be embedded following this same format: ```solidity struct Delegate { address issuer; address subject; uint256 validFrom; uint256 validTo; } struct VerifiableDelegate { Delegate delegate; uint8 v; bytes32 r; bytes32 s; } struct [CLAIM TYPE] { address subject; VerifiedDelegate issuer; uint256 validFrom; uint256 validTo; } ``` Delegates should be created for specific EIP 712 Domains and not be reused across Domains. Implementers of new EIP 712 Domains can add further data to the `Delegate` struct to allow finer grained application specific rules to it. ### Claim Types #### Binary Claims A Binary claim is something that doesn’t have a particular value. It either is issued or not. Examples: * subject is a Person * subject is my owner (eg. Linking an ethereum account to an owner identity) Example: ```solidity struct Person { address issuer; address subject; uint256 validFrom; uint256 validTo; } ``` This is exactly the same as the minimal claim above with the CLAIM TYPE set to [Person](https://schema.org/Person). ### Value Claims Value claims can be used to make a claim about the subject containing a specific readable value. **WARNING**: Be very careful about using Value Claims as part of Smart Contract transactions. Identity Claims containing values could be a GDPR violation for the business or developer encouraging a user to post it to a public blockchain. Examples: * subject’s name is Alice * subjects average account balance is 1234555 Each value should use the `value` field to indicate the value. A Name Claim ```solidity struct Name { address issuer; address subject; string name; uint256 validFrom; uint256 validTo; } ``` Average Balance ```solidity struct AverageBalance { address issuer; address subject; uint256 value; uint256 validFrom; uint256 validTo; } ``` ### Hashed Claims Hashed claims can be used to make a claim about the subject containing the hash of a claim value. Hashes should use ethereum standard `keccak256` hashing function. **WARNING**: Be very careful about using Hashed Claims as part of Smart Contract transactions. Identity Claims containing hashes of known values could be a GDPR violation for the business or developer encouraging a user to post it to a public blockchain. Examples: - [ ] hash of subject’s name is `keccak256(“Alice Torres”)` - [ ] hash of subject’s email is `keccak256(“alice@example.com”)` Each value should use the `keccak256 ` field to indicate the hashed value. Question. The choice of using this name is that we can easily add support for future algorithms as well as maybe zkSnark proofs. A Name Claim ```solidity struct Name { address issuer; address subject; bytes32 keccak256; uint256 validFrom; uint256 validTo; } ``` Email Claim ```solidity struct Email { address issuer; address subject; bytes32 keccak256; uint256 validFrom; uint256 validTo; } ``` ### EIP 712 Domain The EIP 712 Domain specifies what kind of message that is to be signed and is used to differentiate between signed data types. The content MUST contain the following: ```solidity { name: "EIP1???Claim", version: 1, chainId: 1, // for mainnet verifyingContract: 0x // TBD salt: ... } ``` #### Full Combined format for EIP 712 signing: Following the EIP 712 standard we can combine the Claim Type with the EIP 712 Domain and the claim itself (in the `message`) attribute. Eg: ```solidity { "types": { "EIP712Domain": [ { "name": "name", "type": "string" }, { "name": "version", "type": "string" }, { "name": "chainId", "type": "uint256" }, { "name": "verifyingContract", "type": "address" } ], "Email": [ { "name": "subject", "type": "address" }, { "name": "keccak256", "type": "bytes32" }, { "name": "validFrom", "type": "uint256" }, { "name": "validTo", "type": "uint256" } ] }, "primaryType": "Email", "domain": { "name": "EIP1??? Claim", "version": "1", "chainId": 1, "verifyingContract": "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC" }, "message": { "subject": "0x5792e817336f41de1d8f54feab4bc200624a1d9d", "value": "9c8465d9ae0b0bc167dee7f62880034f59313100a638dcc86a901956ea52e280", "validFrom": "0x0000000000000000000000000000000000000000000000000001644b74c2a0", "validTo": "0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff" } } ``` ### Revocation Both Issuers and Subjects should be allowed to revoke Verifiable Claims. Revocations can be handled through a simple on-chain registry. The ultimate rules of who should be able to revoke a claim is determined by the Verifying contract. The `digest` used for revocation is the EIP712 Signed Typed Data digest. ```solidity contract RevocationRegistry { mapping (bytes32 => mapping (address => uint)) public revocations; function revoke(bytes32 digest) public returns (bool) { revocations[digest][msg.sender] = block.number; return true; } function revoked(address party, bytes32 digest) public view returns (bool) { return revocations[digest][party] > 0; } } ``` A verifying contract can query the Revocation Registry as such: ```solidity bytes32 digest = keccak256( abi.encodePacked( "\x19\x01", DOMAIN_SEPARATOR, hash(claim) ) ); require(valid(claim.validFrom, claim.validTo), "invalid issuance timestamps"); address issuer = ecrecover(digest, v, r, s); require(!revocations.revoked(issuer, digest), "claim was revoked by issuer"); require(!revocations.revoked(claim.subject, digest), "claim was revoked by subject"); ``` ### Creation of Verifiable Claims Domains Creating specific is Verifiable Claims Domains is out of the scope of this EIP. The Example Code has a few examples. EIP’s or another process could be used to standardize specific important Domains that are universally useful across the Ethereum world. ## Rationale Signed Typed Data provides a strong foundation for Verifiable Claims that can be used in many different kinds of applications built on both Layer 1 and Layer 2 of Ethereum. ### Rationale for using not using a single EIP 712 Domain EIP712 supports complex types and domains in itself, that we believe are perfect building blocks for building Verifiable Claims for specific purposes. The Type and Domain of a Claim is itself an important part of a claim and ensures that Verifiable Claims are used for the specific purposes required and not misused. EIP712 Domains also allow rapid experimentation, allowing taxonomies to be built up by the community. ## Test Cases There is a repo with a few example verifiers and consuming smart contracts written in Solidity: **Example Verifiers** * [Verifier for very simple IdVerification Verifiable Claims containing minimal Personal Data](https://github.com/uport-project/eip712-claims-experiments/blob/master/contracts/IdentityClaimsVerifier.sol) * [Verifier for OwnershipProofs signed by a users wallet](https://github.com/uport-project/eip712-claims-experiments/blob/master/contracts/OwnershipProofVerifier.sol) **Example Smart Contracts** * [KYCCoin.sol](https://github.com/uport-project/eip712-claims-experiments/blob/master/contracts/KYCCoin.sol) - Example Token allows reusable IdVerification claims issued by trusted verifiers and users to whitelist their own addresses using OwnershipProofs * [ConsortiumAgreement.sol](https://github.com/uport-project/eip712-claims-experiments/blob/master/contracts/ConsortiumAgreements.sol) - Example Consortium Agreement smart contract. Consortium Members can issue Delegated Claims to employees or servers to interact on their behalf. **Shared Registries** * [RevocationRegistry.sol](https://github.com/uport-project/eip712-claims-experiments/blob/master/contracts/RevocationRegistry.sol) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 03 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1812 https://eips.ethereum.org/EIPS/eip-1812 Pseudo-introspection Registry Contract Standards Track/ERC https://github.com/ethereum/EIPs/pull/1820 > :information_source: **[ERC-1820] has superseded [ERC-820].** :information_source: > [ERC-1820] fixes the incompatibility in the [ERC-165] logic which was introduced by the Solidity 0.5 update. > Have a look at the [official announcement][erc1820-annoucement], and the comments about the [bug][erc820-bug] and the [fix][erc820-fix]. > Apart from this fix, [ERC-1820] is functionally equivalent to [ERC-820]. > > :warning: [ERC-1820] MUST be used in lieu of [ERC-820]. :warning: ## Simple Summary This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation. This standard keeps backward compatibility with [ERC-165]. ## Abstract This standard defines a registry where smart contracts and regular accounts can publish which functionality they implement---either directly or through a proxy contract. Anyone can query this registry to ask if a specific address implements a given interface and which smart contract handles its implementation. This registry MAY be deployed on any chain and shares the same address on all chains. Interfaces with zeroes (`0`) as the last 28 bytes are considered [ERC-165] interfaces, and this registry SHALL forward the call to the contract to see if it implements the interface. This contract also acts as an [ERC-165] cache to reduce gas consumption. ## Motivation There have been different approaches to define pseudo-introspection in Ethereum. The first is [ERC-165] which has the limitation that it cannot be used by regular accounts. The second attempt is [ERC-672] which uses reverse [ENS]. Using reverse [ENS] has two issues. First, it is unnecessarily complicated, and second, [ENS] is still a centralized contract controlled by a multisig. This multisig theoretically would be able to modify the system. This standard is much simpler than [ERC-672], and it is *fully* decentralized. This standard also provides a *unique* address for all chains. Thus solving the problem of resolving the correct registry address for different chains. ## Specification ### [ERC-1820] Registry Smart Contract > This is an exact copy of the code of the [ERC1820 registry smart contract]. ``` solidity /* ERC1820 Pseudo-introspection Registry Contract * This standard defines a universal registry smart contract where any address (contract or regular account) can * register which interface it supports and which smart contract is responsible for its implementation. * * Written in 2019 by Jordi Baylina and Jacques Dafflon * * To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to * this software to the public domain worldwide. This software is distributed without any warranty. * * You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see * <http://creativecommons.org/publicdomain/zero/1.0/>. * * ███████╗██████╗ ██████╗ ██╗ █████╗ ██████╗ ██████╗ * ██╔════╝██╔══██╗██╔════╝███║██╔══██╗╚════██╗██╔═████╗ * █████╗ ██████╔╝██║ ╚██║╚█████╔╝ █████╔╝██║██╔██║ * ██╔══╝ ██╔══██╗██║ ██║██╔══██╗██╔═══╝ ████╔╝██║ * ███████╗██║ ██║╚██████╗ ██║╚█████╔╝███████╗╚██████╔╝ * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚════╝ ╚══════╝ ╚═════╝ * * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗ * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝ * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝ * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝ * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║ * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝ * */ pragma solidity 0.5.3; // IV is value needed to have a vanity address starting with '0x1820'. // IV: 53759 /// @dev The interface a contract MUST implement if it is the implementer of /// some (other) interface for any address other than itself. interface ERC1820ImplementerInterface { /// @notice Indicates whether the contract implements the interface 'interfaceHash' for the address 'addr' or not. /// @param interfaceHash keccak256 hash of the name of the interface /// @param addr Address for which the contract will implement the interface /// @return ERC1820_ACCEPT_MAGIC only if the contract implements 'interfaceHash' for the address 'addr'. function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32); } /// @title ERC1820 Pseudo-introspection Registry Contract /// @author Jordi Baylina and Jacques Dafflon /// @notice This contract is the official implementation of the ERC1820 Registry. /// @notice For more details, see https://eips.ethereum.org/EIPS/eip-1820 contract ERC1820Registry { /// @notice ERC165 Invalid ID. bytes4 constant internal INVALID_ID = 0xffffffff; /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`). bytes4 constant internal ERC165ID = 0x01ffc9a7; /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address. bytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked("ERC1820_ACCEPT_MAGIC")); /// @notice mapping from addresses and interface hashes to their implementers. mapping(address => mapping(bytes32 => address)) internal interfaces; /// @notice mapping from addresses to their manager. mapping(address => address) internal managers; /// @notice flag for each address and erc165 interface to indicate if it is cached. mapping(address => mapping(bytes4 => bool)) internal erc165Cached; /// @notice Indicates a contract is the 'implementer' of 'interfaceHash' for 'addr'. event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer); /// @notice Indicates 'newManager' is the address of the new manager for 'addr'. event ManagerChanged(address indexed addr, address indexed newManager); /// @notice Query if an address implements an interface and through which contract. /// @param _addr Address being queried for the implementer of an interface. /// (If '_addr' is the zero address then 'msg.sender' is assumed.) /// @param _interfaceHash Keccak256 hash of the name of the interface as a string. /// E.g., 'web3.utils.keccak256("ERC777TokensRecipient")' for the 'ERC777TokensRecipient' interface. /// @return The address of the contract which implements the interface '_interfaceHash' for '_addr' /// or '0' if '_addr' did not register an implementer for this interface. function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) { address addr = _addr == address(0) ? msg.sender : _addr; if (isERC165Interface(_interfaceHash)) { bytes4 erc165InterfaceHash = bytes4(_interfaceHash); return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : address(0); } return interfaces[addr][_interfaceHash]; } /// @notice Sets the contract which implements a specific interface for an address. /// Only the manager defined for that address can set it. /// (Each address is the manager for itself until it sets a new manager.) /// @param _addr Address for which to set the interface. /// (If '_addr' is the zero address then 'msg.sender' is assumed.) /// @param _interfaceHash Keccak256 hash of the name of the interface as a string. /// E.g., 'web3.utils.keccak256("ERC777TokensRecipient")' for the 'ERC777TokensRecipient' interface. /// @param _implementer Contract address implementing '_interfaceHash' for '_addr'. function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external { address addr = _addr == address(0) ? msg.sender : _addr; require(getManager(addr) == msg.sender, "Not the manager"); require(!isERC165Interface(_interfaceHash), "Must not be an ERC165 hash"); if (_implementer != address(0) && _implementer != msg.sender) { require( ERC1820ImplementerInterface(_implementer) .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC1820_ACCEPT_MAGIC, "Does not implement the interface" ); } interfaces[addr][_interfaceHash] = _implementer; emit InterfaceImplementerSet(addr, _interfaceHash, _implementer); } /// @notice Sets '_newManager' as manager for '_addr'. /// The new manager will be able to call 'setInterfaceImplementer' for '_addr'. /// @param _addr Address for which to set the new manager. /// @param _newManager Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.) function setManager(address _addr, address _newManager) external { require(getManager(_addr) == msg.sender, "Not the manager"); managers[_addr] = _newManager == _addr ? address(0) : _newManager; emit ManagerChanged(_addr, _newManager); } /// @notice Get the manager of an address. /// @param _addr Address for which to return the manager. /// @return Address of the manager for a given address. function getManager(address _addr) public view returns(address) { // By default the manager of an address is the same address if (managers[_addr] == address(0)) { return _addr; } else { return managers[_addr]; } } /// @notice Compute the keccak256 hash of an interface given its name. /// @param _interfaceName Name of the interface. /// @return The keccak256 hash of an interface name. function interfaceHash(string calldata _interfaceName) external pure returns(bytes32) { return keccak256(abi.encodePacked(_interfaceName)); } /* --- ERC165 Related Functions --- */ /* --- Developed in collaboration with William Entriken. --- */ /// @notice Updates the cache with whether the contract implements an ERC165 interface or not. /// @param _contract Address of the contract for which to update the cache. /// @param _interfaceId ERC165 interface for which to update the cache. function updateERC165Cache(address _contract, bytes4 _interfaceId) external { interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache( _contract, _interfaceId) ? _contract : address(0); erc165Cached[_contract][_interfaceId] = true; } /// @notice Checks whether a contract implements an ERC165 interface or not. // If the result is not cached a direct lookup on the contract address is performed. // If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling // 'updateERC165Cache' with the contract address. /// @param _contract Address of the contract to check. /// @param _interfaceId ERC165 interface to check. /// @return True if '_contract' implements '_interfaceId', false otherwise. function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) { if (!erc165Cached[_contract][_interfaceId]) { return implementsERC165InterfaceNoCache(_contract, _interfaceId); } return interfaces[_contract][_interfaceId] == _contract; } /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache. /// @param _contract Address of the contract to check. /// @param _interfaceId ERC165 interface to check. /// @return True if '_contract' implements '_interfaceId', false otherwise. function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) { uint256 success; uint256 result; (success, result) = noThrowCall(_contract, ERC165ID); if (success == 0 || result == 0) { return false; } (success, result) = noThrowCall(_contract, INVALID_ID); if (success == 0 || result != 0) { return false; } (success, result) = noThrowCall(_contract, _interfaceId); if (success == 1 && result == 1) { return true; } return false; } /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not. /// @param _interfaceHash The hash to check. /// @return True if '_interfaceHash' is an ERC165 interface (ending with 28 zeroes), false otherwise. function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) { return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0; } /// @dev Make a call on a contract without throwing if the function does not exist. function noThrowCall(address _contract, bytes4 _interfaceId) internal view returns (uint256 success, uint256 result) { bytes4 erc165ID = ERC165ID; assembly { let x := mload(0x40) // Find empty storage location using "free memory pointer" mstore(x, erc165ID) // Place signature at beginning of empty storage mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature success := staticcall( 30000, // 30k gas _contract, // To addr x, // Inputs are stored at location x 0x24, // Inputs are 36 (4 + 32) bytes long x, // Store output over input (saves space) 0x20 // Outputs are 32 bytes long ) result := mload(x) // Load the result } } } ``` ### Deployment Transaction Below is the raw transaction which MUST be used to deploy the smart contract on any chain. ``` 0xf90a388085174876e800830c35008080b909e5608060405234801561001057600080fd5b506109c5806100206000396000f3fe608060405234801561001057600080fd5b50600436106100a5576000357c010000000000000000000000000000000000000000000000000000000090048063a41e7d5111610078578063a41e7d51146101d4578063aabbb8ca1461020a578063b705676514610236578063f712f3e814610280576100a5565b806329965a1d146100aa5780633d584063146100e25780635df8122f1461012457806365ba36c114610152575b600080fd5b6100e0600480360360608110156100c057600080fd5b50600160a060020a038135811691602081013591604090910135166102b6565b005b610108600480360360208110156100f857600080fd5b5035600160a060020a0316610570565b60408051600160a060020a039092168252519081900360200190f35b6100e06004803603604081101561013a57600080fd5b50600160a060020a03813581169160200135166105bc565b6101c26004803603602081101561016857600080fd5b81019060208101813564010000000081111561018357600080fd5b82018360208201111561019557600080fd5b803590602001918460018302840111640100000000831117156101b757600080fd5b5090925090506106b3565b60408051918252519081900360200190f35b6100e0600480360360408110156101ea57600080fd5b508035600160a060020a03169060200135600160e060020a0319166106ee565b6101086004803603604081101561022057600080fd5b50600160a060020a038135169060200135610778565b61026c6004803603604081101561024c57600080fd5b508035600160a060020a03169060200135600160e060020a0319166107ef565b604080519115158252519081900360200190f35b61026c6004803603604081101561029657600080fd5b508035600160a060020a03169060200135600160e060020a0319166108aa565b6000600160a060020a038416156102cd57836102cf565b335b9050336102db82610570565b600160a060020a031614610339576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b6103428361092a565b15610397576040805160e560020a62461bcd02815260206004820152601a60248201527f4d757374206e6f7420626520616e204552433136352068617368000000000000604482015290519081900360640190fd5b600160a060020a038216158015906103b85750600160a060020a0382163314155b156104ff5760405160200180807f455243313832305f4143434550545f4d4147494300000000000000000000000081525060140190506040516020818303038152906040528051906020012082600160a060020a031663249cb3fa85846040518363ffffffff167c01000000000000000000000000000000000000000000000000000000000281526004018083815260200182600160a060020a0316600160a060020a031681526020019250505060206040518083038186803b15801561047e57600080fd5b505afa158015610492573d6000803e3d6000fd5b505050506040513d60208110156104a857600080fd5b5051146104ff576040805160e560020a62461bcd02815260206004820181905260248201527f446f6573206e6f7420696d706c656d656e742074686520696e74657266616365604482015290519081900360640190fd5b600160a060020a03818116600081815260208181526040808320888452909152808220805473ffffffffffffffffffffffffffffffffffffffff19169487169485179055518692917f93baa6efbd2244243bfee6ce4cfdd1d04fc4c0e9a786abd3a41313bd352db15391a450505050565b600160a060020a03818116600090815260016020526040812054909116151561059a5750806105b7565b50600160a060020a03808216600090815260016020526040902054165b919050565b336105c683610570565b600160a060020a031614610624576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b81600160a060020a031681600160a060020a0316146106435780610646565b60005b600160a060020a03838116600081815260016020526040808220805473ffffffffffffffffffffffffffffffffffffffff19169585169590951790945592519184169290917f605c2dbf762e5f7d60a546d42e7205dcb1b011ebc62a61736a57c9089d3a43509190a35050565b600082826040516020018083838082843780830192505050925050506040516020818303038152906040528051906020012090505b92915050565b6106f882826107ef565b610703576000610705565b815b600160a060020a03928316600081815260208181526040808320600160e060020a031996909616808452958252808320805473ffffffffffffffffffffffffffffffffffffffff19169590971694909417909555908152600284528181209281529190925220805460ff19166001179055565b600080600160a060020a038416156107905783610792565b335b905061079d8361092a565b156107c357826107ad82826108aa565b6107b85760006107ba565b815b925050506106e8565b600160a060020a0390811660009081526020818152604080832086845290915290205416905092915050565b6000808061081d857f01ffc9a70000000000000000000000000000000000000000000000000000000061094c565b909250905081158061082d575080155b1561083d576000925050506106e8565b61084f85600160e060020a031961094c565b909250905081158061086057508015155b15610870576000925050506106e8565b61087a858561094c565b909250905060018214801561088f5750806001145b1561089f576001925050506106e8565b506000949350505050565b600160a060020a0382166000908152600260209081526040808320600160e060020a03198516845290915281205460ff1615156108f2576108eb83836107ef565b90506106e8565b50600160a060020a03808316600081815260208181526040808320600160e060020a0319871684529091529020549091161492915050565b7bffffffffffffffffffffffffffffffffffffffffffffffffffffffff161590565b6040517f01ffc9a7000000000000000000000000000000000000000000000000000000008082526004820183905260009182919060208160248189617530fa90519096909550935050505056fea165627a7a72305820377f4a2d4301ede9949f163f319021a6e9c687c292a5e2b2c4734c126b524e6c00291ba01820182018201820182018201820182018201820182018201820182018201820a01820182018201820182018201820182018201820182018201820182018201820 ``` The strings of `1820`'s at the end of the transaction are the `r` and `s` of the signature. From this deterministic pattern (generated by a human), anyone can deduce that no one knows the private key for the deployment account. ### Deployment Method This contract is going to be deployed using the keyless deployment method---also known as [Nick]'s method---which relies on a single-use address. (See [Nick's article] for more details). This method works as follows: 1. Generate a transaction which deploys the contract from a new random account. - This transaction MUST NOT use [EIP-155] in order to work on any chain. - This transaction MUST have a relatively high gas price to be deployed on any chain. In this case, it is going to be 100 Gwei. 2. Set the `v`, `r`, `s` of the transaction signature to the following values: ``` v: 27, r: 0x1820182018201820182018201820182018201820182018201820182018201820' s: 0x1820182018201820182018201820182018201820182018201820182018201820' ``` Those `r` and `s` values---made of a repeating pattern of `1820`'s---are predictable "random numbers" generated deterministically by a human. 3. We recover the sender of this transaction, i.e., the single-use deployment account. > Thus we obtain an account that can broadcast that transaction, but we also have the warranty that nobody knows the private key of that account. 4. Send exactly 0.08 ether to this single-use deployment account. 5. Broadcast the deployment transaction. This operation can be done on any chain, guaranteeing that the contract address is always the same and nobody can use that address with a different contract. ### Single-use Registry Deployment Account ``` 0xa990077c3205cbDf861e17Fa532eeB069cE9fF96 ``` This account is generated by reverse engineering it from its signature for the transaction. This way no one knows the private key, but it is known that it is the valid signer of the deployment transaction. > To deploy the registry, 0.08 ether MUST be sent to this account *first*. ### Registry Contract Address ``` 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24 ``` The contract has the address above for every chain on which it is deployed. <details> <summary>Raw metadata of <code>./contracts/ERC1820Registry.sol</code></summary> ```json { "compiler": { "version": "0.5.3+commit.10d17f24" }, "language": "Solidity", "output": { "abi": [ { "constant": false, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_interfaceHash", "type": "bytes32" }, { "name": "_implementer", "type": "address" } ], "name": "setInterfaceImplementer", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_addr", "type": "address" } ], "name": "getManager", "outputs": [ { "name": "", "type": "address" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": false, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_newManager", "type": "address" } ], "name": "setManager", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_interfaceName", "type": "string" } ], "name": "interfaceHash", "outputs": [ { "name": "", "type": "bytes32" } ], "payable": false, "stateMutability": "pure", "type": "function" }, { "constant": false, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceId", "type": "bytes4" } ], "name": "updateERC165Cache", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_interfaceHash", "type": "bytes32" } ], "name": "getInterfaceImplementer", "outputs": [ { "name": "", "type": "address" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": true, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceId", "type": "bytes4" } ], "name": "implementsERC165InterfaceNoCache", "outputs": [ { "name": "", "type": "bool" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": true, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceId", "type": "bytes4" } ], "name": "implementsERC165Interface", "outputs": [ { "name": "", "type": "bool" } ], "payable": false, "stateMutability": "view", "type": "function" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "addr", "type": "address" }, { "indexed": true, "name": "interfaceHash", "type": "bytes32" }, { "indexed": true, "name": "implementer", "type": "address" } ], "name": "InterfaceImplementerSet", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "addr", "type": "address" }, { "indexed": true, "name": "newManager", "type": "address" } ], "name": "ManagerChanged", "type": "event" } ], "devdoc": { "author": "Jordi Baylina and Jacques Dafflon", "methods": { "getInterfaceImplementer(address,bytes32)": { "params": { "_addr": "Address being queried for the implementer of an interface. (If '_addr' is the zero address then 'msg.sender' is assumed.)", "_interfaceHash": "Keccak256 hash of the name of the interface as a string. E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface." }, "return": "The address of the contract which implements the interface '_interfaceHash' for '_addr' or '0' if '_addr' did not register an implementer for this interface." }, "getManager(address)": { "params": { "_addr": "Address for which to return the manager." }, "return": "Address of the manager for a given address." }, "implementsERC165Interface(address,bytes4)": { "params": { "_contract": "Address of the contract to check.", "_interfaceId": "ERC165 interface to check." }, "return": "True if '_contract' implements '_interfaceId', false otherwise." }, "implementsERC165InterfaceNoCache(address,bytes4)": { "params": { "_contract": "Address of the contract to check.", "_interfaceId": "ERC165 interface to check." }, "return": "True if '_contract' implements '_interfaceId', false otherwise." }, "interfaceHash(string)": { "params": { "_interfaceName": "Name of the interface." }, "return": "The keccak256 hash of an interface name." }, "setInterfaceImplementer(address,bytes32,address)": { "params": { "_addr": "Address for which to set the interface. (If '_addr' is the zero address then 'msg.sender' is assumed.)", "_implementer": "Contract address implementing '_interfaceHash' for '_addr'.", "_interfaceHash": "Keccak256 hash of the name of the interface as a string. E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface." } }, "setManager(address,address)": { "params": { "_addr": "Address for which to set the new manager.", "_newManager": "Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.)" } }, "updateERC165Cache(address,bytes4)": { "params": { "_contract": "Address of the contract for which to update the cache.", "_interfaceId": "ERC165 interface for which to update the cache." } } }, "title": "ERC1820 Pseudo-introspection Registry Contract" }, "userdoc": { "methods": { "getInterfaceImplementer(address,bytes32)": { "notice": "Query if an address implements an interface and through which contract." }, "getManager(address)": { "notice": "Get the manager of an address." }, "implementsERC165InterfaceNoCache(address,bytes4)": { "notice": "Checks whether a contract implements an ERC165 interface or not without using nor updating the cache." }, "interfaceHash(string)": { "notice": "Compute the keccak256 hash of an interface given its name." }, "setInterfaceImplementer(address,bytes32,address)": { "notice": "Sets the contract which implements a specific interface for an address. Only the manager defined for that address can set it. (Each address is the manager for itself until it sets a new manager.)" }, "setManager(address,address)": { "notice": "Sets '_newManager' as manager for '_addr'. The new manager will be able to call 'setInterfaceImplementer' for '_addr'." }, "updateERC165Cache(address,bytes4)": { "notice": "Updates the cache with whether the contract implements an ERC165 interface or not." } }, "notice": "This contract is the official implementation of the ERC1820 Registry.For more details, see https://eips.ethereum.org/EIPS/eip-1820" } }, "settings": { "compilationTarget": { "./contracts/ERC1820Registry.sol": "ERC1820Registry" }, "evmVersion": "byzantium", "libraries": {}, "optimizer": { "enabled": true, "runs": 200 }, "remappings": [] }, "sources": { "./contracts/ERC1820Registry.sol": { "content": "/* ERC1820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address (contract or regular account) can\n * register which interface it supports and which smart contract is responsible for its implementation.\n *\n * Written in 2019 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to\n * this software to the public domain worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see\n * <http://creativecommons.org/publicdomain/zero/1.0/>.\n *\n * ███████╗██████╗ ██████╗ ██╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝███║██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚██║╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██║██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗ ██║╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.5.3;\n// IV is value needed to have a vanity address starting with '0x1820'.\n// IV: 53759\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC1820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface 'interfaceHash' for the address 'addr' or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC1820_ACCEPT_MAGIC only if the contract implements 'interfaceHash' for the address 'addr'.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n\n/// @title ERC1820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC1820 Registry.\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-1820\ncontract ERC1820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant internal INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant internal ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC1820_ACCEPT_MAGIC\"));\n\n /// @notice mapping from addresses and interface hashes to their implementers.\n mapping(address => mapping(bytes32 => address)) internal interfaces;\n /// @notice mapping from addresses to their manager.\n mapping(address => address) internal managers;\n /// @notice flag for each address and erc165 interface to indicate if it is cached.\n mapping(address => mapping(bytes4 => bool)) internal erc165Cached;\n\n /// @notice Indicates a contract is the 'implementer' of 'interfaceHash' for 'addr'.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates 'newManager' is the address of the new manager for 'addr'.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @return The address of the contract which implements the interface '_interfaceHash' for '_addr'\n /// or '0' if '_addr' did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == address(0) ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : address(0);\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address for which to set the interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @param _implementer Contract address implementing '_interfaceHash' for '_addr'.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == address(0) ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be an ERC165 hash\");\n if (_implementer != address(0) && _implementer != msg.sender) {\n require(\n ERC1820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC1820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets '_newManager' as manager for '_addr'.\n /// The new manager will be able to call 'setInterfaceImplementer' for '_addr'.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.)\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? address(0) : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == address(0)) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string calldata _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(\n _contract, _interfaceId) ? _contract : address(0);\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n // If the result is not cached a direct lookup on the contract address is performed.\n // If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling\n // 'updateERC165Cache' with the contract address.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = noThrowCall(_contract, ERC165ID);\n if (success == 0 || result == 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, INVALID_ID);\n if (success == 0 || result != 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, _interfaceId);\n if (success == 1 && result == 1) {\n return true;\n }\n return false;\n }\n\n /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return True if '_interfaceHash' is an ERC165 interface (ending with 28 zeroes), false otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\n bytes4 erc165ID = ERC165ID;\n\n assembly {\n let x := mload(0x40) // Find empty storage location using \"free memory pointer\"\n mstore(x, erc165ID) // Place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // To addr\n x, // Inputs are stored at location x\n 0x24, // Inputs are 36 (4 + 32) bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n", "keccak256": "0x64025ecebddb6e126a5075c1fd6c01de2840492668e2909cef7157040a9d1945" } }, "version": 1 } ``` </details> ### Interface Name Any interface name is hashed using `keccak256` and sent to `getInterfaceImplementer()`. If the interface is part of a standard, it is best practice to explicitly state the interface name and link to this published [ERC-1820] such that other people don't have to come here to look up these rules. For convenience, the registry provides a function to compute the hash on-chain: ``` solidity function interfaceHash(string _interfaceName) public pure returns(bytes32) ``` Compute the keccak256 hash of an interface given its name. > <small>**identifier:** `65ba36c1`</small> > <small>**parameters**</small> > <small>`_interfaceName`: Name of the interface.</small> > <small>**returns:** The `keccak256` hash of an interface name.</small> #### **Approved ERCs** If the interface is part of an approved ERC, it MUST be named `ERC###XXXXX` where `###` is the number of the ERC and XXXXX should be the name of the interface in CamelCase. The meaning of this interface SHOULD be defined in the specified ERC. Examples: - `keccak256("ERC20Token")` - `keccak256("ERC777Token")` - `keccak256("ERC777TokensSender")` - `keccak256("ERC777TokensRecipient")` #### **[ERC-165] Compatible Interfaces** > The compatibility with [ERC-165], including the [ERC165 Cache], has been designed and developed with [William Entriken]. Any interface where the last 28 bytes are zeroes (`0`) SHALL be considered an [ERC-165] interface. **[ERC-165] Lookup** Anyone can explicitly check if a contract implements an [ERC-165] interface using the registry by calling one of the two functions below: ``` solidity function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) ``` Checks whether a contract implements an [ERC-165] interface or not. If the result is not cached a direct lookup on the contract address is performed. *NOTE*: If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling `updateERC165Cache` with the contract address. (See [ERC165 Cache] for more details.) > <small>**identifier:** `f712f3e8`</small> > <small>**parameters**</small> > <small>`_contract`: Address of the contract to check.</small> > <small>`_interfaceId`: [ERC-165] interface to check.</small> > <small>**returns:** `true` if `_contract` implements `_interfaceId`, `false` otherwise.</small> ``` solidity function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) ``` Checks whether a contract implements an [ERC-165] interface or not without using nor updating the cache. > <small>**identifier:** `b7056765`</small> > <small>**parameters**</small> > <small>`_contract`: Address of the contract to check.</small> > <small>`_interfaceId`: [ERC-165] interface to check.</small> > <small>**returns:** `true` if `_contract` implements `_interfaceId`, false otherwise.</small> **[ERC-165] Cache** <a id="erc165-cache"></a> Whether a contract implements an [ERC-165] interface or not can be cached manually to save gas. If a contract dynamically changes its interface and relies on the [ERC-165] cache of the [ERC-1820] registry, the cache MUST be updated manually---there is no automatic cache invalidation or cache update. Ideally the contract SHOULD automatically update the cache when changing its interface. However anyone MAY update the cache on the contract's behalf. The cache update MUST be done using the `updateERC165Cache` function: ``` solidity function updateERC165Cache(address _contract, bytes4 _interfaceId) external ``` > <small>**identifier:** `a41e7d51`</small> > <small>**parameters**</small> > <small>`_contract`: Address of the contract for which to update the cache.</small> > <small>`_interfaceId`: [ERC-165] interface for which to update the cache.</small> #### **Private User-defined Interfaces** This scheme is extensible. You MAY make up your own interface name and raise awareness to get other people to implement it and then check for those implementations. Have fun but please, you MUST not conflict with the reserved designations above. ### Set An Interface For An Address For any address to set a contract as the interface implementation, it must call the following function of the [ERC-1820] registry: ``` solidity function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external ``` Sets the contract which implements a specific interface for an address. Only the `manager` defined for that address can set it. (Each address is the manager for itself, see the [manager] section for more details.) *NOTE*: If `_addr` and `_implementer` are two different addresses, then: - The `_implementer` MUST implement the `ERC1820ImplementerInterface` (detailed below). - Calling `canImplementInterfaceForAddress` on `_implementer` with the given `_addr` and `_interfaceHash` MUST return the `ERC1820_ACCEPT_MAGIC` value. *NOTE*: The `_interfaceHash` MUST NOT be an [ERC-165] interface---it MUST NOT end with 28 zeroes (`0`). *NOTE*: The `_addr` MAY be `0`, then `msg.sender` is assumed. This default value simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance. > <small>**identifier:** `29965a1d`</small> > <small>**parameters**</small> > <small>`_addr`: Address for which to set the interface. (If `_addr` is the zero address then `msg.sender` is assumed.)</small> > <small>`_interfaceHash`: Keccak256 hash of the name of the interface as a string, for example `web3.utils.keccak256('ERC777TokensRecipient')` for the ERC777TokensRecipient interface.</small> > <small>`_implementer`: Contract implementing `_interfaceHash` for `_addr`.</small> ### Get An Implementation Of An Interface For An Address Anyone MAY query the [ERC-1820] Registry to obtain the address of a contract implementing an interface on behalf of some address using the `getInterfaceImplementer` function. ``` solidity function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) ``` Query if an address implements an interface and through which contract. *NOTE*: If the last 28 bytes of the `_interfaceHash` are zeroes (`0`), then the first 4 bytes are considered an [ERC-165] interface and the registry SHALL forward the call to the contract at `_addr` to see if it implements the [ERC-165] interface (the first 4 bytes of `_interfaceHash`). The registry SHALL also cache [ERC-165] queries to reduce gas consumption. Anyone MAY call the `erc165UpdateCache` function to update whether a contract implements an interface or not. *NOTE*: The `_addr` MAY be `0`, then `msg.sender` is assumed. This default value is consistent with the behavior of the `setInterfaceImplementer` function and simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance. > <small>**identifier:** `aabbb8ca`</small> > <small>**parameters**</small> > <small>`_addr`: Address being queried for the implementer of an interface. (If `_addr` is the zero address then `msg.sender` is assumed.)</small> > <small>`_interfaceHash`: keccak256 hash of the name of the interface as a string. E.g. `web3.utils.keccak256('ERC777Token')`</small> > <small>**returns:** The address of the contract which implements the interface `_interfaceHash` for `_addr` or `0` if `_addr` did not register an implementer for this interface.</small> ### Interface Implementation (`ERC1820ImplementerInterface`) ``` solidity interface ERC1820ImplementerInterface { /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not. /// @param interfaceHash keccak256 hash of the name of the interface /// @param addr Address for which the contract will implement the interface /// @return ERC1820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`. function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32); } ``` Any contract being registered as the implementation of an interface for a given address MUST implement said interface. In addition if it implements an interface on behalf of a different address, the contract MUST implement the `ERC1820ImplementerInterface` shown above. ``` solidity function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32) ``` Indicates whether a contract implements an interface (`interfaceHash`) for a given address (`addr`). If a contract implements the interface (`interfaceHash`) for a given address (`addr`), it MUST return `ERC1820_ACCEPT_MAGIC` when called with the `addr` and the `interfaceHash`. If it does not implement the `interfaceHash` for a given address (`addr`), it MUST NOT return `ERC1820_ACCEPT_MAGIC`. > <small>**identifier:** `f0083250`</small> > <small>**parameters**</small> > <small>`interfaceHash`: Hash of the interface which is implemented</small> > <small>`addr`: Address for which the interface is implemented</small> > <small>**returns:** `ERC1820_ACCEPT_MAGIC` only if the contract implements `ìnterfaceHash` for the address `addr`.</small> The special value `ERC1820_ACCEPT_MAGIC` is defined as the `keccka256` hash of the string `"ERC1820_ACCEPT_MAGIC"`. ``` solidity bytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked("ERC1820_ACCEPT_MAGIC")); ``` > The reason to return `ERC1820_ACCEPT_MAGIC` instead of a boolean is to prevent cases where a contract fails to implement the `canImplementInterfaceForAddress` but implements a fallback function which does not throw. In this case, since `canImplementInterfaceForAddress` does not exist, the fallback function is called instead, executed without throwing and returns `1`. Thus making it appear as if `canImplementInterfaceForAddress` returned `true`. ### Manager The manager of an address (regular account or a contract) is the only entity allowed to register implementations of interfaces for the address. By default, any address is its own manager. The manager can transfer its role to another address by calling `setManager` on the registry contract with the address for which to transfer the manager and the address of the new manager. **`setManager` Function** ``` solidity function setManager(address _addr, address _newManager) external ``` Sets `_newManager` as manager for `_addr`. The new manager will be able to call `setInterfaceImplementer` for `_addr`. If `_newManager` is `0x0`, the manager is reset to `_addr` itself as the manager. > <small>**identifier:** `5df8122f`</small> > <small>**parameters**</small> > <small>`_addr`: Address for which to set the new manager.</small> > <small>`_newManager`: The address of the new manager for `_addr`. (Pass `0x0` to reset the manager to `_addr`.)</small> **`getManager` Function** ``` solidity function getManager(address _addr) public view returns(address) ``` Get the manager of an address. > <small>**identifier:** `3d584063`</small> > <small>**parameters**</small> > <small>`_addr`: Address for which to return the manager.</small> > <small>**returns:** Address of the manager for a given address.</small> ## Rationale This standards offers a way for any type of address (externally owned and contracts) to implement an interface and potentially delegate the implementation of the interface to a proxy contract. This delegation to a proxy contract is necessary for externally owned accounts and useful to avoid redeploying existing contracts such as multisigs and DAOs. The registry can also act as a [ERC-165] cache in order to save gas when looking up if a contract implements a specific [ERC-165] interface. This cache is intentionally kept simple, without automatic cache update or invalidation. Anyone can easily and safely update the cache for any interface and any contract by calling the `updateERC165Cache` function. The registry is deployed using a keyless deployment method relying on a single-use deployment address to ensure no one controls the registry, thereby ensuring trust. ## Backward Compatibility This standard is backward compatible with [ERC-165], as both methods MAY be implemented without conflicting with each other. ## Test Cases Please check the [0xjac/ERC1820] repository for the full test suite. ## Implementation The implementation is available in the repo: [0xjac/ERC1820]. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [EIP-155]: /EIPS/eip-155 [ERC-165]: /EIPS/eip-165 [ERC-672]: https://github.com/ethereum/EIPs/issues/672 [ERC-820]: /EIPS/eip-820 [ERC-1820]: /EIPS/eip-1820 [ERC1820 registry smart contract]: https://github.com/0xjac/ERC1820/blob/master/contracts/ERC1820Registry.sol [erc1820-annoucement]: https://github.com/ethereum/EIPs/issues/820#issuecomment-464109166 [erc820-bug]: https://github.com/ethereum/EIPs/issues/820#issuecomment-452465748 [erc820-fix]: https://github.com/ethereum/EIPs/issues/820#issuecomment-454021564 [manager]: #manager [lookup]: #get-an-implementation-of-an-interface-for-an-address [ERC165 Cache]: #erc165-cache [Nick's article]: https://medium.com/@weka/how-to-send-ether-to-11-440-people-187e332566b7 [0xjac/ERC1820]: https://github.com/0xjac/ERC1820 [Nick]: https://github.com/Arachnid/ [William Entriken]: https://github.com/fulldecent [ENS]: https://ens.domains/ Mon, 04 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1820 https://eips.ethereum.org/EIPS/eip-1820 Universal Upgradeable Proxy Standard (UUPS) Standards Track/ERC https://ethereum-magicians.org/t/eip-1822-universal-upgradeable-proxy-standard-uups ## Simple Summary Standard upgradeable proxy contract. ## Abstract The following describes a standard for proxy contracts which is universally compatible with all contracts, and does not create incompatibility between the proxy and business-logic contracts. This is achieved by utilizing a unique storage position in the proxy contract to store the Logic Contract's address. A compatibility check ensures successful upgrades. Upgrading can be performed unlimited times, or as determined by custom logic. In addition, a method for selecting from multiple constructors is provided, which does not inhibit the ability to verify bytecode. ## Motivation - Improve upon existing proxy implementations to improve developer experience for deploying and maintaining Proxy and Logic Contracts. - Standardize and improve the methods for verifying the bytecode used by the Proxy Contract. ## Terminology - `delegatecall()` - Function in contract **A** which allows an external contract **B** (delegating) to modify **A**'s storage (see diagram below, [Solidity docs](https://solidity.readthedocs.io/en/v0.5.3/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)) - **Proxy Contract** - The contract **A** which stores data, but uses the logic of external contract **B** by way of `delegatecall()`. - **Logic Contract** - The contract **B** which contains the logic used by Proxy Contract **A** - **Proxiable Contract** - Inherited in Logic Contract **B** to provide the upgrade functionality ![](/assets/eip-1822/proxy-diagram.png) ## Specification The Proxy Contract proposed here should be deployed _as is_, and used as a drop-in replacement for any existing methods of lifecycle management of contracts. In addition to the Proxy Contract, we propose the Proxiable Contract interface/base which establishes a pattern for the upgrade which does not interfere with existing business rules. The logic for allowing upgrades can be implemented as needed. ### Proxy Contract #### Functions ##### `fallback` The proposed fallback function follows the common pattern seen in other Proxy Contract implementations such as [Zeppelin][1] or [Gnosis][2]. However, rather than forcing use of a variable, the address of the Logic Contract is stored at the defined storage position `keccak256("PROXIABLE")`. This eliminates the possibility of collision between variables in the Proxy and Logic Contracts, thus providing "universal" compatibility with any Logic Contract. ```javascript function() external payable { assembly { // solium-disable-line let contractLogic := sload(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7) calldatacopy(0x0, 0x0, calldatasize) let success := delegatecall(sub(gas, 10000), contractLogic, 0x0, calldatasize, 0, 0) let retSz := returndatasize returndatacopy(0, 0, retSz) switch success case 0 { revert(0, retSz) } default { return(0, retSz) } } } ``` #### `constructor` The proposed constructor accepts any number of arguments of any type, and thus is compatible with any Logic Contract constructor function. In addition, the arbitrary nature of the Proxy Contract's constructor provides the ability to select from one or more constructor functions available in the Logic Contract source code (e.g., `constructor1`, `constructor2`, ... etc. ). Note that if multiple constructors are included in the Logic Contract, a check should be included to prohibit calling a constructor again post-initialization. It's worth noting that the added functionality of supporting multiple constructors does not inhibit verification of the Proxy Contract's bytecode, since the initialization tx call data (input) can be decoded by first using the Proxy Contract ABI, and then using the Logic Contract ABI. The contract below shows the proposed implementation of the Proxy Contract. ```javascript contract Proxy { // Code position in storage is keccak256("PROXIABLE") = "0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7" constructor(bytes memory constructData, address contractLogic) public { // save the code address assembly { // solium-disable-line sstore(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7, contractLogic) } (bool success, bytes memory _ ) = contractLogic.delegatecall(constructData); // solium-disable-line require(success, "Construction failed"); } function() external payable { assembly { // solium-disable-line let contractLogic := sload(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7) calldatacopy(0x0, 0x0, calldatasize) let success := delegatecall(sub(gas, 10000), contractLogic, 0x0, calldatasize, 0, 0) let retSz := returndatasize returndatacopy(0, 0, retSz) switch success case 0 { revert(0, retSz) } default { return(0, retSz) } } } } ``` ### Proxiable Contract The Proxiable Contract is included in the Logic Contract, and provides the functions needed to perform an upgrade. The compatibility check `proxiable` prevents irreparable updates during an upgrade. > :warning: Warning: `updateCodeAddress` and `proxiable` must be present in the Logic Contract. Failure to include these may prevent upgrades, and could allow the Proxy Contract to become entirely unusable. See below [Restricting dangerous functions](#restricting-dangerous-functions) #### Functions ##### `proxiable` Compatibility check to ensure the new Logic Contract implements the Universal Upgradeable Proxy Standard. Note that in order to support future implementations, the `bytes32` comparison could be changed e.g., `keccak256("PROXIABLE-ERC1822-v1")`. ##### `updateCodeAddress` Stores the Logic Contract's address at storage `keccak256("PROXIABLE")` in the Proxy Contract. The contract below shows the proposed implementation of the Proxiable Contract. ```javascript contract Proxiable { // Code position in storage is keccak256("PROXIABLE") = "0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7" function updateCodeAddress(address newAddress) internal { require( bytes32(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7) == Proxiable(newAddress).proxiableUUID(), "Not compatible" ); assembly { // solium-disable-line sstore(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7, newAddress) } } function proxiableUUID() public pure returns (bytes32) { return 0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7; } } ``` ## Pitfalls when using a proxy The following common best practices should be employed for all Logic Contracts when using a proxy contract. ### Separating Variables from Logic Careful consideration should be made when designing a new Logic Contract to prevent incompatibility with the existing storage of the Proxy Contract after an upgrade. Specifically, the order in which variables are instantiated in the new contract should not be modified, and any new variables should be added after all existing variables from the previous Logic Contract To facilitate this practice, we recommend utilizing a single "base" contract which holds all variables, and which is inherited in subsequent logic contract(s). This practice greatly reduces the chances of accidentally reordering variables or overwriting them in storage. ### Restricting dangerous functions The compatibility check in the Proxiable Contract is a safety mechanism to prevent upgrading to a Logic Contract which does not implement the Universal Upgradeable Proxy Standard. However, as occurred in the parity wallet hack, it is still possible to perform irreparable damage to the Logic Contract itself. In order to prevent damage to the Logic Contract, we recommend restricting permissions for any potentially damaging functions to `onlyOwner`, and giving away ownership of the Logic Contract immediately upon deployment to a null address (e.g., address(1)). Potentially damaging functions include native functions such as `SELFDESTRUCT`, as well functions whose code may originate externally such as `CALLCODE`, and `delegatecall()`. In the [ERC-20 Token](#erc-20-token) example below, a `LibraryLock` contract is used to prevent destruction of the logic contract. ## Examples ### Owned In this example, we show the standard ownership example, and restrict the `updateCodeAddress` to only the owner. ```javascript contract Owned is Proxiable { // ensures no one can manipulate this contract once it is deployed address public owner = address(1); function constructor1() public{ // ensures this can be called only once per *proxy* contract deployed require(owner == address(0)); owner = msg.sender; } function updateCode(address newCode) onlyOwner public { updateCodeAddress(newCode); } modifier onlyOwner() { require(msg.sender == owner, "Only owner is allowed to perform this action"); _; } } ``` ### ERC-20 Token #### Proxy Contract ```javascript pragma solidity ^0.5.1; contract Proxy { // Code position in storage is keccak256("PROXIABLE") = "0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7" constructor(bytes memory constructData, address contractLogic) public { // save the code address assembly { // solium-disable-line sstore(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7, contractLogic) } (bool success, bytes memory _ ) = contractLogic.delegatecall(constructData); // solium-disable-line require(success, "Construction failed"); } function() external payable { assembly { // solium-disable-line let contractLogic := sload(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7) calldatacopy(0x0, 0x0, calldatasize) let success := delegatecall(sub(gas, 10000), contractLogic, 0x0, calldatasize, 0, 0) let retSz := returndatasize returndatacopy(0, 0, retSz) switch success case 0 { revert(0, retSz) } default { return(0, retSz) } } } } ``` #### Token Logic Contract ``` javascript contract Proxiable { // Code position in storage is keccak256("PROXIABLE") = "0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7" function updateCodeAddress(address newAddress) internal { require( bytes32(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7) == Proxiable(newAddress).proxiableUUID(), "Not compatible" ); assembly { // solium-disable-line sstore(0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7, newAddress) } } function proxiableUUID() public pure returns (bytes32) { return 0xc5f16f0fcc639fa48a6947836d9850f504798523bf8c9a3a87d5876cf622bcf7; } } contract Owned { address owner; function setOwner(address _owner) internal { owner = _owner; } modifier onlyOwner() { require(msg.sender == owner, "Only owner is allowed to perform this action"); _; } } contract LibraryLockDataLayout { bool public initialized = false; } contract LibraryLock is LibraryLockDataLayout { // Ensures no one can manipulate the Logic Contract once it is deployed. // PARITY WALLET HACK PREVENTION modifier delegatedOnly() { require(initialized == true, "The library is locked. No direct 'call' is allowed"); _; } function initialize() internal { initialized = true; } } contract ERC20DataLayout is LibraryLockDataLayout { uint256 public totalSupply; mapping(address=>uint256) public tokens; } contract ERC20 { // ... function transfer(address to, uint256 amount) public { require(tokens[msg.sender] >= amount, "Not enough funds for transfer"); tokens[to] += amount; tokens[msg.sender] -= amount; } } contract MyToken is ERC20DataLayout, ERC20, Owned, Proxiable, LibraryLock { function constructor1(uint256 _initialSupply) public { totalSupply = _initialSupply; tokens[msg.sender] = _initialSupply; initialize(); setOwner(msg.sender); } function updateCode(address newCode) public onlyOwner delegatedOnly { updateCodeAddress(newCode); } function transfer(address to, uint256 amount) public delegatedOnly { ERC20.transfer(to, amount); } } ``` ## References - ["Escape-hatch" proxy Medium Post](https://medium.com/terminaldotco/escape-hatch-proxy-efb681de108d) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [1]: https://github.com/maraoz/solidity-proxy/blob/master/contracts/Dispatcher.sol [2]: https://blog.gnosis.pm/solidity-delegateproxy-contracts-e09957d0f201 Mon, 04 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1822 https://eips.ethereum.org/EIPS/eip-1822 Precompile for Elliptic Curve Linear Combinations Standards Track/Core https://ethereum-magicians.org/t/ewasm-precompile-for-general-elliptic-curve-math/2581 # Precompile for Elliptic Curve Linear Combinations ## Simple Summary Currently the EVM only supports *secp256k1* in a limited way through `ecrecover` and *altbn128* through two pre-compiles. There are draft proposals to add more curves. There are many more elliptic curves that have useful applications for integration with existing systems or newly developed curves for zero-knowledge proofs. This EIP adds a precompile that allows whole classes of curves to be used. ## Abstract A precompile that takes a curve and computes a linear combination of curve points. ## Motivation ## Specification Given integers `m, α` and `β`, scalars `s_i`, and curve points `A_i` construct the elliptic curve ``` y² = x³ + α ⋅ x + β mod m ``` and compute the following ``` C = s₀ ⋅ A₀ + s₁ ⋅ A₁ + ⋯ + s_n ⋅ A_n ``` aka *linear combination*, *inner product*, *multi-multiplication* or even *multi-exponentiation*. ``` (Cx, Cy) := ecmul(m, α, β, s0, Ax0, As0, s1, Ax1, As1, ...) ``` ### Gas cost ``` BASE_GAS = ... ADD_GAS = ... MUL_GAS = ... ``` The total gas cost is `BASE_GAS` plus `ADD_GAS` for each `s_i` that is `1` and `MUL_GAS` for each `s_i > 1` (`s_i = 0` is free). ### Encoding of points Encode as `(x, y')` where `s` indicates whether `y` or `-y` is to be taken. It follows SEC 1 v 1.9 2.3.4, except uncompressed points (`y' = 0x04`) are not supported. | `y'` | `(x, y)` | |--------|-----| | `0x00` | Point at infinity | | `0x02` | Solution with `y` even | | `0x03` | Solution with `y` odd | Conversion from affine coordinates to compressed coordinates is trivial: `y' = 0x02 | (y & 0x01)`. ### Special cases **Coordinate recovery.** Set `s₀ = 1`. The output will be the recovered coordinates of `A₀`. **On-curve checking.** Do coordinate recovery and compare `y` coordinate. **Addition.** Set `s₀ = s₁ = 1`, the output will be `A₀ + A₁`. **Doubling.** Set `s₀ = 2`. The output will be `2 ⋅ A₀`. (Note: under the current gas model, this may be more costly than self-addition!) **Scalar multiplication.** Set only `s₀` and `A₀`. **Modular square root.** Set `α = s₀ = A = 0` the output will have `Cy² = β mod m`. ### Edge cases * Non-prime moduli or too small modulus * Field elements larger than modulus * Curve has singular points (`4 α³ + 27 β² = 0`) * Invalid sign bytes * x coordinate not on curve * Returning the point at infinity * (Please add if you spot more) ## Rationale **Generic Field and Curve.** Many important optimizations are independent of the field and curve used. Some missed specific optimizations are: * Reductions specific to the binary structure of the field prime. * Precomputation of Montgomery factors. * Precomputation of multiples of certain popular points like the generator. * Special point addition/doubling [formulas][formulas] for `α = -3`, `α = -1`, `α = 0`, `β = 0`. [formulas]: https://www.hyperelliptic.org/EFD/g1p/auto-shortw.html TODO: The special cases for `α` and `β` might be worth implementing and offering a gas discount. **Compressed Coordinates.** Compressed coordinates allow contract to work with only `x` coordinates and sign bytes. It also prevents errors around points not being on-curve. Conversion to compressed coordinates is trivial. **Linear Combination.** We could instead have a simple multiply `C = r ⋅ A`. In this case we would need a separate pre-compile for addition. In addition, a linear combination allows for optimizations that like Shamir's trick that are not available in a single scalar multiplication. ECDSA requires `s₀ ⋅ A₀ + s₁ ⋅ A₁` and would benefit from this. The BN254 (aka alt_bn8) multiplication operation introduced by the [EIP-196][EIP-196] precompile only handles a single scalar multiplication. The missed performance is such that for two or more points it is cheaper to use EVM, as practically demonstrated by [Weierstrudel][ws]. [EIP-196]: /EIPS/eip-196 [ws]: https://medium.com/aztec-protocol/huffing-for-crypto-with-weierstrudel-9c9568c06901 **Variable Time Math.** When called during a transaction, there is no assumption of privacy and no mitigations for side-channel attacks are necessary. **Prime Fields.** This EIP is for fields of large characteristic. It does not cover Binary fields and other fields of non-prime characteristic. **256-bit modulus.** This EIP is for field moduli less than `2^{256}`. This covers many of the popular curves while still having all parameters fit in a single EVM word. TODO: Consider a double-word version. 512 bits would cover all known curves except E-521. In particular it will cover the NIST P-384 curve used by the Estonian e-Identity and the BLS12-381 curve used by [ZCash Sappling][sappling]. [sappling]: https://z.cash/blog/new-snark-curve/ **Short Weierstrass Curves.** This EIP is for fields specified in short Weierstrass form. While any curve can be converted to short Weierstrass form through a [substitution of variables][cov], this misses out on the performance advantages of those specific forms. [cov]: https://safecurves.cr.yp.to/equation.html ## Backwards Compatibility ## Test Cases ## Implementation There will be a reference implementation in Rust based on the existing libraries (in particular those by ZCash and The Matter Inc.). The reference implementation will be production grade and compile to a native library with a C api and a webassembly version. Node developers are encouraged to use the reference implementation and can use either the rust library, the native C bindings or the webassembly module. Node developers can of course always decide to implement their own. ## References This EIP overlaps in scope with * [EIP-196](/EIPS/eip-196): ecadd, ecmul for altbn128 * [EIP issue 603](https://github.com/ethereum/EIPs/issues/603): ecadd, ecmul for SECP256k1. * [EIP-665](/EIPS/eip-665): ECDSA verify for ED25519. * [EIP-1108](/EIPS/eip-1108): Optimize ecadd and ecmul for altbn128. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 06 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1829 https://eips.ethereum.org/EIPS/eip-1829 ENS Interface Discovery Standards Track/ERC https://ethereum-magicians.org/t/ens-interface-discovery/2924 ## Simple Summary Defines a method of associating contract interfaces with ENS names and addresses, and of discovering those interfaces. ## Abstract This EIP specifies a method for exposing interfaces associated with an ENS name or an address (typically a contract address) and allowing applications to discover those interfaces and interact with them. Interfaces can be implemented either by the target contract (if any) or by any other contract. ## Motivation EIP 165 supports interface discovery - determining if the contract at a given address supports a requested interface. However, in many cases it's useful to be able to discover functionality associated with a name or an address that is implemented by other contracts. For example, a token contract may not itself provide any kind of 'atomic swap' functionality, but there may be associated contracts that do. With ENS interface discovery, the token contract can expose this metadata, informing applications where they can find that functionality. ## Specification A new profile for ENS resolvers is defined, consisting of the following method: ```solidity function interfaceImplementer(bytes32 node, bytes4 interfaceID) external view returns (address); ``` The EIP-165 interface ID of this interface is `0xb8f2bbb4`. Given an ENS name hash `node` and an EIP-165 `interfaceID`, this function returns the address of an appropriate implementer of that interface. If there is no interface matching that interface ID for that node, 0 is returned. The address returned by `interfaceImplementer` MUST refer to a smart contract. The smart contract at the returned address SHOULD implement EIP-165. Resolvers implementing this interface MAY utilise a fallback strategy: If no matching interface was explicitly provided by the user, query the contract returned by `addr()`, returning its address if the requested interface is supported by that contract, and 0 otherwise. If they do this, they MUST ensure they return 0, rather than reverting, if the target contract reverts. This field may be used with both forward resolution and reverse resolution. ## Rationale A naive approach to this problem would involve adding this method directly to the target contract. However, doing this has several shortcomings: 1. Each contract must maintain its own list of interface implementations. 2. Modifying this list requires access controls, which the contract may not have previously required. 3. Support for this must be designed in when the contract is written, and cannot be retrofitted afterwards. 4. Only one canonical list of interfaces can be supported. Using ENS resolvers instead mitigates these shortcomings, making it possible for anyone to associate interfaces with a name, even for contracts not previously built with this in mind. ## Backwards Compatibility There are no backwards compatibility issues. ## Test Cases TBD ## Implementation The PublicResolver in the [ensdomains/resolvers](https://github.com/ensdomains/resolvers/) repository implements this interface. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 15 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1844 https://eips.ethereum.org/EIPS/eip-1844 Ethereum Network Upgrade Windows Meta/ https://ethereum-magicians.org/t/eip-1872-ethereum-network-upgrade-windows/2993 ## Simple Summary A proposal to define a limited number of annual time windows in which network upgrades (aka hard forks) should be performed within. Policies for scheduling network upgrades outside these windows are also described. ## Abstract Four different weeks, spaced roughly evenly throughout the year, are targeted for network upgrades to be launched. Regular network upgrades should announce their intention to launch in a particular window early in their process and choose a block number four to six weeks prior to that window. If a network upgrade is cancelled then it would be rescheduled for the next window. Not all windows will be used. Priority upgrades outside the roadmap may be scheduled in the third week of any month, but such use is discouraged. Critical upgrades are scheduled as needed. ## Motivation The aim of this EIP is to provide some level of regularity and predictability to the Ethereum network upgrade/hard fork process. This will allow service providers such as exchanges and node operators a predictable framework to schedule activities around. This also provides a framework to regularize the delivery of network upgrades. ## Specification Scheduling is defined for three categories of network upgrades. First are `Roadmap` network upgrades that include deliberate protocol improvements. Next are `Priority` network updates, where there are technical reasons that necessitate a prompt protocol change but these reasons do not present a systemic risk to the protocol or the ecosystem. Finally, `Critical` network upgrades are to address issues that present a systemic risk to the protocol or the ecosystem. ### Roadmap Network Upgrades Roadmap network upgrades are network upgrades that are deliberate and measured to improve the protocol and ecosystem. Historical examples are Homestead, Byzantium, and Constantinople. Roadmap network upgrades should be scheduled in one of four windows: the week with the third Wednesday in January, April, July, and October. When initiating a network upgrade or early in the planning process a particular window should be targeted. > **Note to reviewers:** The months and week chosen are to provide an initial > recommendation and are easily modifiable prior to final call. They thread the > needle between many third quarter and fourth quarter holidays. Implementors are expected to have software for a Roadmap network upgrade ready two to four weeks prior to the upgrade. Hence a block number for the network upgrade should be chosen four to six weeks prior to the network upgrade window. Scheduling details such as whether this choice is made prior to or after testnet deployment are out of scope of this EIP. Depending on the release cadence of Roadmap network upgrades some windows will not be used. For example if a six month release cadence is chosen a roadmap upgrade would not occur in adjacent upgrade windows. Hence for a six month cadence if a roadmap upgrade occurred in April then the July window would not be used for network upgrades. If a planned roadmap upgrade needs to be rescheduled then strong consideration should be given to rescheduling the upgrade for the next window in three months time. For the case of a six month cadence this may cause releases to be in adjacent release windows. For a three month cadence the next network upgrade would be merged with the current upgrade or the next network upgrade would be delayed. To be compatible with the scheduled release windows the cadence of the Roadmap Network Upgrades should be a multiple of three months. Whether it is three, six, nine, or more month cadence is out of scope of this EIP. ### Priority Network Upgrades Priority network upgrades are reserved for upgrades that require more urgency than a roadmap network upgrade yet do not present a systemic risk to the network or the ecosystem. To date there have been no examples of a priority upgrade. Possible examples may include roadmap upgrades that need to occur in multiple upgrades or for security risks that have a existing mitigation in place that would be better served by a network upgrade. Another possible reason may be to defuse the difficulty bomb due to postponed roadmap upgrades. Priority network upgrades are best launched in unused roadmap launch windows, namely the third week of January, April, July, and October. If necessary they may be launched in the third week of any month, but strong consideration and preference should be given to unused roadmap launch windows. Priority network upgrades should be announced and a block chosen far enough in advance so major clients implementors can release software with the needed block number in a timely fashion. These releases should occur at least a week before the launch window. Hence priority launch windows should be chosen two to four weeks in advance. ### Critical Network Upgrades Critical network upgrades are network upgrades that are designed to address systemic risks to the protocol or to the ecosystem. Historical examples include Dao Fork, Tangerine Whistle, and Spurious Dragon. This EIP provides neither guidance nor restrictions to the development and deployment of these emergency hard forks. These upgrades are typically launched promptly after a solution to the systemic risk is agreed upon between the client implementors. It is recommended that such upgrades perform the minimum amount of changes needed to address the issues that caused the need for the Critical network upgrade and that other changes be integrated into subsequent Priority and Roadmap network upgrades. ### Network Upgrade Block Number Choice When choosing an activation block the number can be used to communicate the role of a particular network in the Ethereum Ecosystem. Networks that serve as a value store or are otherwise production grade have different stability concerns than networks that serve as technology demonstration or are explicitly designated for testing. To date all Mainnet activation blocks have ended in three or more zeros, including Critical Network Upgrades. Ropsten and Kovan initially started with three zeros but switched to palindromic numbers. Rinkeby has always had palindromic activation blocks. Goerli has yet to perform a network upgrade. To continue this pattern network upgrade activation block numbers for mainnet deployments and production grade networks should chose a number whose base 10 representation ends with three or more zeros. For testnet and testing or development grades network operators are encouraged to choose a block activation number that is a palindrome in base 10. Block numbers for Roadmap and Priority network upgrades should be chosen so that it is forecast to occur relatively close to Wednesday at 12:00 UTC+0 during the launch window. This should result in an actual block production occurring sometime between Monday and Friday of the chosen week. ## Rationale The rationale for defining launch windows is to give business running Ethereum infrastructure a predictable schedule for when upgrades may or may not occur. Knowing when a upgrade is not going to occur gives the businesses a clear time frame within which to perform internal upgrades free from external changes. It also provides a timetable for developers and IT professionals to schedule time off against. ## Backwards Compatibility Except for the specific launch windows the previous network upgrades would have complied with these policies. Homestead, Byzantium, and Constantinople would have been Roadmap Network Upgrades. There were no Priority Network Upgrades, although Spurious Dragon would have been a good candidate. Dao Fork was a Critical Network Upgrade in response to TheDao. Tangerine Whistle and Spurious Dragon were critical upgrades in response to the Shanghai Spam Attacks. Constantinople Fix (as it is termed in the reference tests) was in response to the EIP-1283 security issues. If this policy were in place prior to Constantinople then the initial 2018 launch would likely have been bumped to the next window after the Ropsten testnet consensus failures. The EIP-1283 issues likely would have resulted in an out of window upgrade because of the impact of the difficulty bomb. <!-- ## Test Cases --> <!-- no test cases are relevant for this EIP --> ## Implementation The windows in this EIP are expected to start after the Istanbul Network upgrade, which is the next planned Roadmap upgrade. Istanbul is currently slated for mainnet launch on 2019-10-16, which is compatible with the schedule in this EIP. The Roadmap Upgrade windows starting with Istanbul would be as follows: | Block Target | Launch Week Range | | ------------ | ------------------------ | | 2019-10-16 | 2019-10-14 to 2019-10-18 | | 2020-01-15 | 2020-01-13 to 2020-01-17 | | 2020-04-15 | 2020-04-13 to 2020-04-17 | | 2020-07-15 | 2020-07-13 to 2020-07-17 | | 2020-10-21 | 2020-10-19 to 2020-10-23 | | 2021-01-20 | 2021-01-18 to 2021-01-22 | | 2021-04-21 | 2021-04-19 to 2021-04-23 | | 2021-07-21 | 2021-07-19 to 2021-07-23 | | 2021-10-20 | 2021-10-18 to 2021-10-22 | | 2022-01-19 | 2022-01-17 to 2022-01-21 | | 2022-04-20 | 2022-04-18 to 2022-04-22 | | 2022-07-20 | 2022-07-18 to 2022-07-22 | | 2022-10-19 | 2022-10-17 to 2022-10-21 | The Priority windows through next year, excluding Roadmap windows, are as follows: | Block Target | Launch Week Range | | ------------ | ------------------------ | | 2019-11-20 | 2019-11-18 to 2019-11-22 | | 2019-12-18 | 2019-12-16 to 2019-12-20 | | 2020-02-19 | 2020-02-17 to 2020-02-21 | | 2020-03-18 | 2020-03-16 to 2020-03-20 | | 2020-05-20 | 2020-05-18 to 2020-05-22 | | 2020-06-17 | 2020-06-15 to 2020-06-19 | | 2020-08-19 | 2020-08-18 to 2020-08-21 | | 2020-09-16 | 2020-09-14 to 2020-09-18 | | 2020-11-18 | 2020-11-16 to 2020-11-20 | | 2020-12-16 | 2020-12-14 to 2020-12-18 | ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 25 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1872 https://eips.ethereum.org/EIPS/eip-1872 Repricing for trie-size-dependent opcodes Standards Track/Core https://ethereum-magicians.org/t/opcode-repricing/3024 ## Simple Summary This EIP proposes repricing certain opcodes, to obtain a good balance between gas expenditure and resource consumption. ## Abstract The growth of the Ethereum state has caused certain opcodes to be more resource-intensive at this point than they were previously. This EIP proposes to raise the `gasCost` for those opcodes. ## Motivation An imbalance between the price of an operation and the resource consumption (CPU time, memory etc) has several drawbacks: - It could be used for attacks, by filling blocks with underpriced operations which causes excessive block processing time. - Underpriced opcodes cause a skewed block gas limit, where sometimes blocks finish quickly but other blocks with similar gas use finish slowly. If operations are well-balanced, we can maximise the block gaslimit and have a more stable processing time. ## Specification At block `N`, - The `SLOAD` (`0x54`) operation changes from `200` to `800` gas, - The `BALANCE` (`0x31`) operation changes from `400` to `700` gas, - The `EXTCODEHASH` (`0x3F`) operation changes from `400` to `700` gas, - A new opcode, `SELFBALANCE` is introduced at `0x47`. - `SELFBALANCE` pops `0` arguments off the stack, - `SELFBALANCE` pushes the `balance` of the current address to the stack, - `SELFBALANCE` is priced as `GasFastStep`, at `5` gas. ## Rationale Here are two charts, taken from a full sync using Geth. The execution time was measured for every opcode, and aggregated for 10K blocks. These bar charts show the top 25 'heavy' opcodes in the ranges 5M to 6M and 6M to 7M: ![bars1](/assets/eip-1884/run3.total-bars-5.png) ![bars2](/assets/eip-1884/run3.total-bars-6.png) Note: It can also be seen that the `SLOAD` moves towards the top position. The `GASPRICE` (`0x3a`) opcode has position one which I believe can be optimized away within the client -- which is not the case with `SLOAD`/`BALANCE`. Here is another chart, showing a full sync with Geth. It represents the blocks `0` to `5.7M`, and highlights what the block processing time is spent on. ![geth](/assets/eip-1884/geth_processing.png) It can be seen that `storage_reads` and `account_reads` are the two most significant factors contributing to the block processing time. ### `SLOAD` `SLOAD` was repriced at [EIP-150][eip-150], from `50` to `200`. The following graph shows a go-ethereum full sync, where each data point represents 10K blocks. During those 10K blocks, the execution time for the opcode was aggregated. ![graph](/assets/eip-1884/SLOAD-run3.png) It can be seen that the repricing at [EIP-150][eip-150] caused a steep drop, from around `67` to `23`. Around block `5M`, it started reaching pre-[EIP-150][eip-150] levels, and at block `7M` it was averaging on around `150` - more than double pre-eip-150 levels. Increasing the cost of `SLOAD` by `4` would bring it back down to around `40`. It is to be expected that it will rise again in the future, and may need future repricing, unless state clearing efforts are implemented before that happens. ### `BALANCE` `BALANCE` (a.k.a `EXTBALANCE`) is an operation which fetches data from the state trie. It was repriced at [EIP-150][eip-150] from `20` to `400`. ![graph](/assets/eip-1884/BALANCE-run3.png) It is comparable to `EXTCODESIZE` and `EXTCODEHASH`, which are priced at `700` already. It has a built-in high variance, since it is often used for checking the balance of `this`, which is an inherently cheap operation, however, it can be used to lookup the balance of arbitrary account which often require trie (disk) access. In hindsight, it might have been a better choice to have two opcodes: `EXTBALANCE(address)` and `SELFBALANCE`, and have two different prices. * This EIP proposes to extend the current opcode set. * Unfortunately, the opcode span `0x3X` is already full, hence the suggestion to place `SELFBALANCE` in the `0x4X` range. * As for why it is priced at `5` (`GasFastStep`) instead of `2` (`GasQuickStep`), like other similar operations: the EVM execution engine still needs a lookup into the (cached) trie, and `balance`, unlike `gasPrice` or `timeStamp`, is not constant during the execution, so it has a bit more inherent overhead. ### `EXTCODEHASH` `EXTCODEHASH` was introduced in Constantinople, with [EIP-1052](/EIPS/eip-1052). It was priced at `400` with the reasoning: > The gas cost is the same as the gas cost for the `BALANCE` opcode because the execution of the `EXTCODEHASH` requires the same account lookup as in `BALANCE`. Ergo, if we increase `BALANCE`, we should also increase `EXTCODEHASH` ## Backwards Compatibility The changes require a hardfork. The changes have the following consequences: - Certain calls will become more expensive. - Default-functions which access the storage and may in some cases require more than`2300` gas (the minimum gas that is always available in calls). - Contracts that assume a certain fixed gas cost for calls (or internal sections) may cease to function. - A fixed gas cost is specified in [ERC-165](/EIPS/eip-165) and implementations of this interface do use the affected opcodes. - The ERC-165 method `supportsInterface` must return a `bool` and use at most `30,000` gas. - The two example implementations from the EIP were, at the time of writing 1. `586` gas for any input, and 2. `236` gas, but increases linearly with a higher number of supported interfaces - It is unlikely that any ERC-165 `supportsInterface` implementation will go above `30.000` gas. That would require that the second variant is used, and thirty:ish interfaces are supported. - However, these operations have already been repriced earlier, so there is a historical precedent that 'the gascost for these operations may change', which should have prevented such fixed-gas-cost assumptions from being implemented. I expect that certain patterns will be less used, for example the use of multiple modifiers which `SLOAD`s the same opcode will be merged into one. It may also lead to less `log` operations containing `SLOAD`ed values that are not strictly necessary. ## Test Cases Testcases that should be implemented: - Test that `selfbalance == balance(address)`, - Test that `balance(this)` costs as before, - Test that `selfbalance` does not pop from stack - Gascost verification of `SLOAD`, `EXTCODEHASH` and `SELFBALANCE` - Verify that `SELFBALANCE` is invalid before Istanbul Some testcases have been implemented as statetests at https://github.com/holiman/IstanbulTests/tree/master/GeneralStateTests ## Implementation This EIP has not yet been implemented in any client. Both these opcodes have been repriced before, and the client internals for managing reprices are already in place. ### `SELFBALANCE` This is the implementation for the new opcode in go-ethereum: ```golang func opSelfBalance(pc *uint64, interpreter *EVMInterpreter, contract *Contract, memory *Memory, stack *Stack) ([]byte, error) { stack.push(interpreter.intPool.get().Set(interpreter.evm.StateDB.GetBalance(contract.Address()) return nil, nil } ``` ## Security considerations - See backwards compatibility section. - There are no special edgecases regarding `SELFBALANCE`, if we define it as `BALANCE` with `address` instead of popping an address from the stack -- since `BALANCE` is already well-defined. - It should be investigated if Solidity contains any hardcoded expectations on the gas cost of these operations. - In many cases, a recipient of `ether` from a `CALL` will want to issue a `LOG`. The `LOG` operation costs `375` plus `375` per topic. If the `LOG` also wants to do an `SLOAD`, this change may make some such transfers fail. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [eip-150]: /EIPS/eip-150 Thu, 28 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1884 https://eips.ethereum.org/EIPS/eip-1884 Commitment to Sustainable Ecosystem Funding Standards Track/Core https://t.me/joinchat/DwEd_xahL5hHvzNYH2RnQA # Commitment to Sustainable Ecosystem Funding ## Simple Summary Ethereum currently provides a block reward to proof of work miners every block, but it does not capture any block rewards for ecosystem funding. This EIP adds a simple mechanism for capturing a portion of block rewards for ecosystem funding as a credible commitment to doing so in future, but it does not actually capture any such rewards. ## Abstract A mechanism that allows specification of two parameters, a beneficiary address and a per-block reward denominated in wei, that allows a portion of block rewards to be captured for the purpose of ecosystem funding. Both values are set to zero. ## Motivation In order for Ethereum to succeed, it needs talented, motivated researchers and developers to continue to develop and maintain the platform. Those talented researchers and developers deserve to be paid fairly for their work. At present there is no mechanism in the Ethereum ecosystem that rewards R&D teams fairly for their work on the platform. We recognize that, while technically trivial, the real challenge in inflation-based funding is social: how to fairly capture, govern, and distribute block rewards. It will take time to work out the answer to these questions. For this reason, this EIP only seeks to make a credible commitment on the part of core developers to securing the funding they need to keep Ethereum alive and healthy by adding a mechanism to do so, but the actual amount of rewards captured remains at zero, i.e., there is no change at present to Ethereum’s economics. Raising the amount captured above zero would require a future EIP. ## Specification Two new constants are introduced: BENEFICIARY_ADDRESS, an Address, and DEVFUND_BLOCK_REWARD, an amount denominated in wei. Both are set to zero. Beginning with block ISTANBUL_BLOCK_HEIGHT, DEVFUND_BLOCK_REWARD wei is added to the balance of BENEFICIARY_ADDRESS at each block. We may optionally add another constant, DECAY_FACTOR, which specifies a linear or exponenential decay factor that reduces the reward at every block > ISTANBUL_BLOCK_HEIGHT until it decays to zero. For simplicity, it has been omitted from this proposal. ## Rationale We believe that the technical design of this EIP is straightforward. The social rationale is explained in [this article](https://medium.com/gitcoin/funding-open-source-in-the-blockchain-era-8ded753bf05f). ## Backwards Compatibility This EIP has no impact on backwards compatibility. ## Test Cases This EIP makes no changes to existing state transitions. Existing consensus tests should be sufficient. ## Implementation Reference implementations are included for the Trinity, go-ethereum, and parity clients. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 31 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1890 https://eips.ethereum.org/EIPS/eip-1890 Support for an Elliptic Curve Cycle Standards Track/Core https://ethresear.ch/t/reducing-the-verification-cost-of-a-snark-through-hierarchical-aggregation/5128 ## Simple Summary The EVM currently supports elliptic curves operations for curve *alt-bn128* thanks to precompiles `ecadd` and `ecmul` and `ecpairing`. The classes MNT4 and 6 contain cycles of curves. Those cycles enable doing operations on one curve inside a SNARK on the other curve (and reversely). This EIP suggests adding support for those curves. ## Abstract Adds supports for the following operations through precompiles: * `ecadd` on MNT4 * `ecmul` on MNT4 * `ecpairing` on MNT4 ## Motivation Elliptic curve is the basic block of recursive SNARKs (ie: verifying a SNARK inside a SNARK) and this addresses the issue of scalable zero-knowledge. More generally this addresses partly the scalability issue as SNARKs verification are constant time in the size of the circuit being verified. More concretely, today if the EVM has to deal with 1000s of SNARK verification it would take around 1.5 billion gas and would be impractical for Ethereum. Recursive SNARKs for instance make it possible to aggregate multiple proofs into a single one that can be verified like any other SNARK. It results in a massive cost reduction for the verification. However, this is impossible using *alt-bn128* and in my knowledge, the only family of pairing-friendly curves known to produce cycles are MNT4 and MNT6. A complete characterization of the cycles existing between those two families is proposed in [On cycles of pairing-friendly elliptic curves ](https://arxiv.org/pdf/1803.02067.pdf) ## Specification ### The curve The proposed cycle has been introduced in [Scalable Zero Knowledge via Cycles of Elliptic Curves](https://eprint.iacr.org/2014/595.pdf). ### MNT4 definition The groups `G_1` and `G_2` are cyclic groups of prime order : ```. q = 475922286169261325753349249653048451545124878552823515553267735739164647307408490559963137 ``` `G_1` is defined over the field `F_p` of prime order : ```. p = 475922286169261325753349249653048451545124879242694725395555128576210262817955800483758081 ``` with generator P: ```. P = ( 60760244141852568949126569781626075788424196370144486719385562369396875346601926534016838, 363732850702582978263902770815145784459747722357071843971107674179038674942891694705904306 ) ``` Both p and q can be written in 298 bits. The group G_1 is defined on the curve defined by the equation `Y² = X³ + aX + b` where: ```. a = 2 b = 423894536526684178289416011533888240029318103673896002803341544124054745019340795360841685 ``` The twisted group G_2 is defined over the field `F_p^2 = F_p / <<To be completed>>` The twisted group G_2 is defined on the curve defined by the equation `Y² = X² + aX + b` where : ```. a = 34 + i * 0 b = 0 + i * 67372828414711144619833451280373307321534573815811166723479321465776723059456513877937430 ``` G_2 generator is generated by : ```. P2 = ( 438374926219350099854919100077809681842783509163790991847867546339851681564223481322252708 + i * 37620953615500480110935514360923278605464476459712393277679280819942849043649216370485641, 37437409008528968268352521034936931842973546441370663118543015118291998305624025037512482 + i * 424621479598893882672393190337420680597584695892317197646113820787463109735345923009077489 ) ``` ### The operations and gas cost The following operations and their gas cost would be implemented ```. MNT_X_ADD = <<To be estimated>> MNT_X_MUL = <<To be estimated>> MNT_X_PAIRING = <<To be estimated>> ``` Where `X` is either 4. ### Encoding The curves points P(X, Y) over F_p are represented in their compressed form C(X, Y): ```. C = X | s ``` where `s` represents `Y` as follow: ```. | `s'` | `Y` | |--------|--------------------------| | `0x00` | Point at infinity | | `0x02` | Solution with `y` even | | `0x03` | Solution with `y` odd | ``` Compression operation from affine coordinate is trivial: ```. s = 0x02 | (s & 0x01) ``` In the EVM the compressed form allows us to represents curve points with 2 uint256 instead of 3. ### Edge cases * Several acceptable representations for the point at infinity ## Rationale The curve has 80 bits of security (whereas MNT6 has 120 bits) which might not be considered enough for critical security level, (for instance transferring several billions), but enough for others. If it turns out this is not enough security for adoption, there is another option : another cycle is being used by Coda but is defined over a 753 bits sized field which might also be prohibitively low (no reference to this curve from Coda's publications found). Independently of the cycle chosen, the groups and field elements are represented with integers larger than 256 bits (even for the 80 bits of security), therefore it might be necessary to also add support for larger field size operations. We currently don't know more efficient pairing-friendly cycles and don't know if there are. It might be possible to circumvent this problem though by relaxing the constraint that all the curves of the cycle must be pairing friendly). If we had a cycle with only one pairing friendly curve we would still be able to compose proofs by alternating between SNARKs and any other general purpose zero-knowledge cryptosystems. Assuming we find a convenient cycle, we don't need to implement support for all the curves it contains, only one. The best choice would be the fastest one as the overall security of the recursive snark do not depends on which curve the verification is made. Proper benchmarks will be done in order to make this choice and to price the operations in gas. ## Test Cases ## References * *Eli-Ben-Sasson, Alessandro Chiesa, Eran Tromer, Madars Virza, [BCTV14], April 28, 2015, Scalable Zero Knowledge via Cycles of Elliptic Curves : https://eprint.iacr.org/2014/595.pdf* * *Alessandro Chiesa, Lynn Chua, Matthew Weidner, [CCW18], November 5, 2018, On cycles of pairing-friendly elliptic curves : https://arxiv.org/pdf/1803.02067.pdf* ## Implementation * [go-boojum](https://github.com/AlexandreBelling/go-boojum) : A PoC demo of an application of recursive SNARKs * [libff](https://github.com/scipr-lab/libff) : a C++ library for finite fields and elliptic curves * [coda](https://github.com/CodaProtocol/coda) : a new cryptocurrency protocol with a lightweight, constant sized blockchain. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 31 Mar 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1895 https://eips.ethereum.org/EIPS/eip-1895 Add `blockHash` to defaultBlock methods Standards Track/Interface https://ethereum-magicians.org/t/eip-1898-add-blockhash-option-to-json-rpc-methods-that-currently-support-defaultblock-parameter/11757 ## Abstract For JSON-RPC methods which currently accept a default block parameter, additionally allow the parameter to be a block hash. This EIP can be considered a generalization of [EIP-234](/EIPS/eip-234). It would enable clients to unambiguously specify the block they want to query for certain JSON-RPC methods, even if the block is not in the canonical chain. This allows clients to maintain a coherent picture of blockchain state that they are interested in, even in the presence of reorgs, without requiring that the node maintain a persistent connection with the client or store any client-specific state. ## Specification The following JSON-RPC methods are affected: - `eth_getBalance` - `eth_getStorageAt` - `eth_getTransactionCount` - `eth_getCode` - `eth_call` - `eth_getProof` The following options, quoted from the Ethereum JSON-RPC spec, are currently possible for the defaultBlock parameter: > - HEX String - an integer block number > - String "earliest" for the earliest/genesis block > - String "latest" - for the latest canonical block > - String "pending" - for the pending state/transactions > - String "safe" - for the most recent safe block > - String "finalized" - for the most recent finalized block Since there is no way to clearly distinguish between a DATA parameter and a QUANTITY parameter, this EIP proposes a new scheme for the block parameter. The following option is additionally allowed: - OBJECT - `blockNumber`: QUANTITY - a block number - `blockHash`: DATA - a block hash If the block is not found, the callee SHOULD raise a JSON-RPC error (the recommended error code is `-32001: Resource not found`). If the tag is `blockHash`, an additional boolean field may be supplied to the block parameter, `requireCanonical`, which defaults to `false` and defines whether the block must be a canonical block according to the callee. If `requireCanonical` is `false`, the callee should raise a JSON-RPC error only if the block is not found (as described above). If `requireCanonical` is `true`, the callee SHOULD additionally raise a JSON-RPC error if the block is not in the canonical chain (the recommended error code is `-32000: Invalid input` and in any case should be different than the error code for the block not found case so that the caller can distinguish the cases). The block-not-found check SHOULD take precedence over the block-is-canonical check, so that if the block is not found the callee raises block-not-found rather than block-not-canonical. To maintain backwards compatibility, the block number MAY be specified either as a hex string or using the new block parameter scheme. In other words, the following are equivalent for the default block parameter: - `"earliest"` - `"0x0"` - `{ "blockNumber": "0x0" }` - `{ "blockHash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3" }` (hash of the genesis block on the Ethereum main chain) - `{ "blockHash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requireCanonical": true }` - `{ "blockHash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requireCanonical": false }` ## Rationale Currently, the state-querying JSON-RPC methods specified above have no option to unambiguously specify which block to query the state for. This can cause issues for applications which need to make multiple calls to the RPC. For instance, a wallet which just executed a transfer may want to display the balances of both the sender and recipient. If there is a re-org in between when the balance of the sender is queried via `eth_getBalance` and when the balance of the recipient is queried, the balances may not reconcile. As a slightly more complicated example, the UI for a decentralized exchange (which hosts orders on-chain) may walk a list of orders by calling `eth_call` for each of them to get the order data. Another type of use case is where an application needs to make a decision based on multiple pieces of state, e.g. a payout predicated on simultaneous ownership of two NFTs. In order to ensure that the state is coherent (i.e., `eth_call` was called with exactly the same block for every call), the application may currently use one of several strategies: - Decide on a block number to use (e.g., the latest block number known to the application). After each `eth_call` using that block number, call `eth_getBlockByNumber`, also with that block number. If the block hash does not match the known hash for that block number, rollback the current activity and retry from the beginning. This adds `O(n)` invocations as baseline overhead and another `O(n)` invocations for every retry needed. Moreover, there is no way to detect the (unlikely but possible) case that the relevant block was reorged out before `eth_call`, and then reorged back in before `eth_getBlockByNumber`. - Rely on logs, which *can* be queried unambiguously thanks to the `blockHash` parameter. However, this requires semantic support from the smart contract; if the smart contract does not emit appropriate events, the client will not be able to reconstruct the specific state it is interested in. - Rely on non-standard extensions like `parity_subscribe`. This requires a persistent connection between the client and node (via IPC or websockets), increases coupling between the client and the node, and cannot handle use cases where there are dependencies between invocations of `eth_call`, for example, walking a linked list. Allowing `eth_call` and friends to unambiguously specify the block to be queried give the application developer a robust and intuitive way to solve these problems. Multiple sequential queries will query the same state, enabling the application developer to not worry about inconsistencies in their view of the blockchain state. ## Backwards Compatibility Backwards compatible. ## Test Cases - `eth_getStorageAt [ "0x<address>", { "blockNumber": "0x0" }` -> return storage at given address in genesis block - `eth_getStorageAt [ "0x<address>", { "blockHash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3" }` -> return storage at given address in genesis block - `eth_getStorageAt [ "0x<address>", { "blockHash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requireCanonical": false }` -> return storage at given address in genesis block - `eth_getStorageAt [ "0x<address>", { "blockHash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requireCanonical": true }` -> return storage at given address in genesis block - `eth_getStorageAt [ "0x<address>", { "blockHash": "0x<non-existent-block-hash>" }` -> raise block-not-found error - `eth_getStorageAt [ "0x<address>", { "blockHash": "0x<non-existent-block-hash>", "requireCanonical": false }` -> raise block-not-found error - `eth_getStorageAt [ "0x<address>", { "blockHash": "0x<non-existent-block-hash>", "requireCanonical": true }` -> raise block-not-found error - `eth_getStorageAt [ "0x<address>", { "blockHash": "0x<non-canonical-block-hash>" }` -> return storage at given address in specified block - `eth_getStorageAt [ "0x<address>", { "blockHash": "0x<non-canonical-block-hash>", "requireCanonical": false }` -> return storage at given address in specified block - `eth_getStorageAt [ "0x<address>", { "blockHash": "0x<non-canonical-block-hash>", "requireCanonical": true }` -> raise block-not-canonical error ## Security Considerations None ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 01 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1898 https://eips.ethereum.org/EIPS/eip-1898 dType - Decentralized Type System for EVM Standards Track/ERC https://github.com/ethereum/EIPs/issues/1882 ## Simple Summary The EVM and related languages such as Solidity need consensus on an extensible Type System in order to further evolve into the Singleton Operating System (The World Computer). ## Abstract We are proposing a decentralized Type System for Ethereum, to introduce data definition (and therefore ABI) consistency. This ERC focuses on defining an on-chain Type Registry (named `dType`) and a common interface for creating types, based on `struct`s. ## Motivation In order to build a network of interoperable protocols on Ethereum, we need data standardization, to ensure a smooth flow of on-chain information. Off-chain, the Type Registry will allow a better analysis of blockchain data (e.g. for blockchain explorers) and creation of smart contract development tools for easily using existing types in a new smart contract. However, this is only the first phase. As defined in this document and in the future proposals that will be based on this one, we are proposing something more: a decentralized Type System with Data Storage - [ERC-2158](https://github.com/ethereum/EIPs/pull/2158). In addition, developers can create libraries of `pure` functions that know how to interact and modify the data entries - [dType Functions Extension](https://github.com/ethereum/EIPs/issues/1921). This will effectively create the base for a general functional programming system on Ethereum, where developers can use previously created building blocks. To summarize: * We would like to have a good decentralized medium for integrating all Ethereum data, and relationships between the different types of data. Also, a way to address the behavior related to each data type. * Functional programming becomes easier. Functions like `map`, `reduce`, `filter`, are implemented by each type library. * Solidity development tools could be transparently extended to include the created types (For example in IDEs like Remix). At a later point, the EVM itself can have precompiled support for these types. * The system can be easily extended to types pertaining to other languages. (With type definitions in the source (Swarm stored source code in the respective language)) * The dType database should be part of the System Registry for the Operating System of The World Computer ## Specification The Type Registry can have a governance protocol for its CRUD operations. However, this, and other permission guards are not covered in this proposal. ### Type Definition and Metadata The dType registry should support the registration of Solidity's elementary and complex types. In addition, it should also support contract events definitions. In this EIP, the focus will be on describing the minimal on-chain type definition and metadata needed for registering Solidity user-defined types. #### Type Definition: TypeLibrary A type definition consists of a type library containing: - the nominal `struct` used to define the type - additional functions: - `isInstanceOf`: checks whether a given variable is an instance of the defined type. Additional rules can be defined for each type fields, e.g. having a specific range for a `uint16 amount`. - provide HOFs such as `map`, `filter`, `reduce` - `structureBytes` and `destructureBytes`: provide type structuring and destructuring. This can be useful for low-level calls or assembly code, when importing contract interfaces is not an efficient option. It can also be used for type checking. A simple example is: ```solidity pragma solidity ^0.5.0; pragma experimental ABIEncoderV2; library myBalanceLib { struct myBalance { string accountName; uint256 amount; } function structureBytes(bytes memory data) pure public returns(myBalance memory balance) function destructureBytes(myBalance memory balance) pure public returns(bytes memory data) function isInstanceOf(myBalance memory balance) pure public returns(bool isInstance) function map( address callbackAddr, bytes4 callbackSig, myBalance[] memory balanceArr ) view internal returns (myBalance[] memory result) } ``` Types can also use existing types in their composition. However, this will always result in a directed acyclic graph. ```solidity library myTokenLib { using myBalanceLib for myBalanceLib.myBalance; struct myToken { address token; myBalanceLib.myBalance; } } ``` #### Type Metadata: dType Registry Type metadata will be registered on-chain, in the dType registry contract. This consists of: - `name` - the type's name, as it would be used in Solidity; it can be stored as a `string` or encoded as `bytes`. The name can have a human-readable part and a version number. - `typeChoice` - used for storing additional ABI data that differentiate how types are handled on and off chain. It is defined as an `enum` with the following options: `BaseType`, `PayableFunction`, `StateFunction`, `ViewFunction`, `PureFunction`, `Event` - `contractAddress` - the Ethereum `address` of the `TypeRootContract`. For this proposal, we can consider the Type Library address as the `TypeRootContract`. Future EIPs will make it more flexible and propose additional TypeStorage contracts that will modify the scope of `contractAddress` - [ERC-2158](https://github.com/ethereum/EIPs/pull/2158). - `source` - a `bytes32` Swarm hash where the source code of the type library and contracts can be found; in future EIPs, where dType will be extended to support other languages (e.g. JavaScript, Rust), the file identified by the Swarm hash will contain the type definitions in that language. - `types` - metadata for subtypes: the first depth level internal components. This is an array of objects (`structs`), with the following fields: - `name` - the subtype name, of type `string`, similar to the above `name` definition - `label` - the subtype label - `dimensions` - `string[]` used for storing array dimensions. E.g.: - `[]` -> `TypeA` - `[""]` -> `TypeA[]` - `["2"]` -> `TypeA[2]` - `["",""]` -> `TypeA[][]` - `["2","3"]` -> `TypeA[2][3]` Examples of metadata, for simple, value types: ```javascript { "contractAddress": "0x0000000000000000000000000000000000000000", "typeChoice": 0, "source": "0x0000000000000000000000000000000000000000000000000000000000000000", "name": "uint256", "types": [] } { "contractAddress": "0x0000000000000000000000000000000000000000", "typeChoice": 0, "source": "0x0000000000000000000000000000000000000000000000000000000000000000", "name": "string", "types": [] } ``` Composed types can be defined as: ```javascript { "contractAddress": "0x105631C6CdDBa84D12Fa916f0045B1F97eC9C268", "typeChoice": 0, "source": <a SWARM hash for type source code files>, "name": "myBalance", "types": [ {"name": "string", "label": "accountName", dimensions: []}, {"name": "uint256", "label": "amount", dimensions: []} ] } ``` Composed types can be further composed: ```javascript { "contractAddress": "0x91E3737f15e9b182EdD44D45d943cF248b3a3BF9", "typeChoice": 0, "source": <a SWARM hash for type source code files>, "name": "myToken", "types": [ {"name": "address", "label": "token", dimensions: []}, {"name": "myBalance", "label": "balance", dimensions: []} ] } ``` `myToken` type will have the final data format: `(address,(string,uint256))` and a labeled format: `(address token, (string accountName, uint256 amount))`. ##### dType Registry Data Structures and Interface To store this metadata, the dType registry will have the following data structures: ```solidity enum TypeChoices { BaseType, PayableFunction, StateFunction, ViewFunction, PureFunction, Event } struct dTypes { string name; string label; string[] dimensions; } struct dType { TypeChoices typeChoice; address contractAddress; bytes32 source; string name; dTypes[] types; } ``` For storage, we propose a pattern which isolates the type metadata from additional storage-specific data and allows CRUD operations on records. ```solidity // key: identifier mapping(bytes32 => Type) public typeStruct; // array of identifiers bytes32[] public typeIndex; struct Type { dType data; uint256 index; } ``` Note that we are proposing to define the type's primary identifier, `identifier`, as `keccak256(abi.encodePacked(name))`. If the system is extended to other programming languages, we can define `identifier` as `keccak256(abi.encodePacked(language, name))`. Initially, single word English names can be disallowed, avoiding name squatting. The dType registry interface is: ```solidity import './dTypeLib.sol'; interface dType { event LogNew(bytes32 indexed identifier, uint256 indexed index); event LogUpdate(bytes32 indexed identifier, uint256 indexed index); event LogRemove(bytes32 indexed identifier, uint256 indexed index); function insert(dTypeLib.dType calldata data) external returns (bytes32 identifier); function remove(bytes32 identifier) external returns(uint256 index); function count() external view returns(uint256 counter); function getTypeIdentifier(string memory name) pure external returns (bytes32 identifier); function getByIdentifier(bytes32 identifier) view external returns(dTypeLib.dType memory dtype); function get(string memory name) view external returns(dTypeLib.dType memory dtype); function isRegistered(bytes32 identifier) view external returns(bool registered); } ``` **Notes:** To ensure backward compatibility, we suggest that updating types should not be supported. The `remove` function can also be removed from the interface, to ensure immutability. One reason for keeping it would be clearing up storage for types that are not in use or have been made obsolete. However, this can have undesired effects and should be accompanied by a solid permissions system, testing and governance process. This part will be updated when enough feedback has been received. ## Rationale The Type Registry must store the minimum amount of information for rebuilding the type ABI definition. This allows us to: * support on-chain interoperability * decode blockchain side effects off-chain (useful for block explorers) * allow off-chain tools to cache and search through the collection (e.g. editor plugin for writing typed smart contracts) There is one advantage that has become clear with the emergence of global operating systems, like Ethereum: we can have a global type system through which the system’s parts can interoperate. Projects should agree on standardizing types and a type registry, continuously working on improving them, instead of creating encapsulated projects, each with their own types. The effort of having consensus on new types being added or removing unused ones is left to the governance system. After the basis of such a system is specified, we can move forward to building a static type checking system at compile time, based on the type definitions and rules stored in the dType registry. The Type Library must express the behavior strictly pertinent to its defined type. Additional behavior, required by various project's business logic can be added later, through libraries containing functions that handle the respective type. These can also be registered in dType, but will be detailed in a future ERC. This is an approach that will separate definitions from stored data and behavior, allowing for easier and more secure fine-grained upgrades. ## Backwards Compatibility This proposal does not affect extant Ethereum standards or implementations. It uses the present experimental version of ABIEncoderV2. ## Test Cases Will be added. ## Implementation An in-work implementation can be found at https://github.com/pipeos-one/dType/tree/master/contracts/contracts. This proposal will be updated with an appropriate implementation when consensus is reached on the specifications. A video demo of the current implementation (a more extended version of this proposal) can be seen at https://youtu.be/pcqi4yWBDuQ. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 28 Mar 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1900 https://eips.ethereum.org/EIPS/eip-1900 Add OpenRPC Service Discovery To JSON-RPC Services Standards Track/Interface https://github.com/ethereum/EIPs/issues/1902 ## Abstract ### What is this? This is a proposal to add [OpenRPC](https://github.com/open-rpc/spec) support to existing and future JSON-RPC services by adding the method [`rpc.discover`](https://github.com/open-rpc/spec#service-discovery-method) to the projects [JSON-RPC](https://www.jsonrpc.org/specification) APIs, enabling automation and tooling. The OpenRPC Document and generated Documentation that specifies all the methods an EVM-based blockchain should implement can be found [here](https://github.com/etclabscore/ethereum-json-rpc-specification). This was first proposed [here as an ECIP](https://github.com/etclabscore/ECIPs/blob/master/ECIPs/ecip-1053.md), but the benefits of this kind of tooling is apparent across Bitcoin, Ethereum Classic, Ethereum and other JSON-RPC accessible blockchains. ## Motivation Although [EIP-1474](/EIPS/eip-1474) outlines a JSON-RPC specification. Ethereum still lacks a machine-readable JSON-RPC Specification that can be used as the industry standard for tooling. This proposal attempts to standardize such a specification in a way that is versionable, and both human and machine readable. Ethereum clients can expose RPC endpoints with different method signatures and cause compatibility issues between clients. Developers need a reliable developer experience, and an industry standard way to describe Ethereum JSON-RPC 2.0 APIs. ## Specification ### What is OpenRPC? The [OpenRPC](https://github.com/open-rpc/spec) Specification defines a standard, programming language-agnostic interface description for [JSON-RPC 2.0](https://www.jsonrpc.org/specification) APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenRPC, a consumer can understand and interact with the remote service with a minimal amount of implementation logic, and share these logic patterns across use cases. Similar to what interface descriptions have done for lower-level programming, the OpenRPC Specification removes guesswork in calling a service. ##### Structure This is the structure of an OpenRPC Document: ![openrpc-spec-structure](/assets/eip-1901/OpenRPC_structure.png) JSON-RPC APIs can support the OpenRPC specification by implementing a service discovery method that will return the [OpenRPC document](https://github.com/open-rpc/spec#openrpc-document) for the JSON-RPC API. The method MUST be named `rpc.discover`. The `rpc.` prefix is a reserved method prefix for [JSON-RPC 2.0 Specification](https://www.jsonrpc.org/specification) system extensions. ### Use Case This is the vision for the use case of OpenRPC and how it would relate to a client implementation like multi-geth: ![MultGethRpc-usecase](/assets/eip-1901/multi-geth-use-case.png) ## Rationale ### Why would we do this? Services need to figure out how to talk to each other. If we really want to build the next generation of automation, then having up to date libraries, documented APIs, and modern tools are going to provide easy discovery, on-boarding, and enable end user and developer interaction. Use cases for machine-readable [JSON-RPC 2.0](https://www.jsonrpc.org/specification) API definition documents include, but are not limited to: - A common vocabulary and document will keep developers, testers, architects, and technical writers all in sync. - Server stubs/skeletons generated in many languages - Clients generated in many languages - Mock Server generated in many languages - Tests generated in many languages - Documentation Generation ### Alternative [OpenRPC](https://github.com/open-rpc/spec) documents just describe [JSON-RPC](https://www.jsonrpc.org/specification) APIs services, and are represented in JSON format. These documents may be produced and served statically OR generated dynamically from an application and returned via the [`rpc.discover`](https://github.com/open-rpc/spec#service-discovery-method) method. This gives projects and communities the opportunity to adopt tools, documentation, and clients outlined in the [etclabscore/ethereum-json-rpc-specification](/EIPS/eip-1474) before the [`rpc.discover`](https://github.com/open-rpc/spec#service-discovery-method) method is implemented for a particular client. ## Implementation - [Multi-Geth OpenRPC Discovery](https://github.com/multi-geth/multi-geth#openrpc-discovery) ### Tooling #### Interactive Documentation Playground You can view the interactive documentation [here](https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/etclabscore/ethereum-json-rpc-specification/master/openrpc.json). **OR** Using `rpc.discover` via multi-geth, the playground can discover and display the documentation for the Ethereum JSON-RPC API: ![eth-playground-openrpc](/assets/eip-1901/eth-playground-openrpc.gif) #### Generated Client The [clients](https://github.com/etclabscore/ethereum-json-rpc-specification#clients) are generated from the OpenRPC Document openrpc.json outlined in this EIP, and can be used as an alternative to web3.js or ethers.js but for various languages: ![eth-generated-client-openrpc](/assets/eip-1901/eth-generated-client-openrpc.gif) #### Mock Server The [OpenRPC mock server](https://github.com/open-rpc/mock-server) provides a mock server for any given OpenRPC Document which allows testing without booting up a real network. ![inspector-mock-server-openrpc](/assets/eip-1901/inspector-mock-server-openrpc.png) ## Resources - [Multi-Geth OpenRPC Discovery](https://github.com/multi-geth/multi-geth#openrpc-discovery) - [EDCON 2019 talk on OpenRPC and The Future of JSON-RPC Tooling](https://www.youtube.com/watch?v=UgSPMZ9FQ4Q) - [etclabscore/ethereum-json-rpc-specification](https://github.com/etclabscore/ethereum-json-rpc-specification) - [open-rpc.org](https://open-rpc.org) ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 25 Feb 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1901 https://eips.ethereum.org/EIPS/eip-1901 dType Functions Extension Standards Track/ERC https://github.com/ethereum/EIPs/issues/1921 ## Simple Summary In the context of dType, the Decentralized Type System described in [EIP-1900](/EIPS/eip-1900), we are proposing to add support for registering functions (with a preference for `pure` and `view`) in the dType Registry. ## Abstract This proposal is part of a series of EIPs focused on expanding the concept of a Decentralized Type System, as explained in [EIP-1900](/EIPS/eip-1900). The current EIP specifies the data definitions and interfaces needed to support registering individual smart contract functions, as entries in the dType Registry. ## Motivation In order to evolve the EVM into a Singleton Operating System, we need a way to register, find and address contract functions that we want to run in an automated way. This implies having access to all the data needed to run the function inside the EVM. Aside from the above motivation, there are also near future benefits for this proposal. Having a globally available, non-custodial functions registry, will democratize the development of tools, such as those targeting: blockchain data analysis (e.g. block explorers), smart contract IDEs, security analysis of smart contracts. Registering new smart contract functions can be done through the same consensus mechanism as [EIP-1900](/EIPS/eip-1900) mentions, in order to avoid burdening the chain state with redundant or improper records. ## Specification This specification targets `pure` and `view` functions. For each function, we can store: * `name` - type `string` unique function name, as defined in EIP-1900; required * `types` - the type data and label of each input, as defined in EIP-1900; required * `outputs` - the type data and label of each output; required * `contractAddress` - type `address` - smart contract where the function resides, as defined in EIP-1900; optional for interfaces * `source` - type `bytes32` - reference to an external file containing the function source code, as defined in EIP-1900; optional Therefore, this proposal adds `outputs` to the EIP-1900 type registration definition. An example of a function registration object for the dType registry is: ``` { "name": "setStaked", "types": [ {"name": "TypeA", "label": "typeA", "relation":0, "dimensions":[]} ], "typeChoice": 4, "contractAddress": <address of the deployed smart contract where the function is defined>, "source": <bytes32 hash for referencing source files>, "outputs": [ {"name": "TypeB", "label": "typeB", "relation":0, "dimensions":[]} ] } ``` The above object will be passed to `<dType registry>.insert({...})` An additional `setOutputs` function is proposed for the dType registry: ``` function setOutputs( bytes32 identifier, dTypes[] memory outputs ) public ``` - `identifier` - type `bytes32`, the type's identifier, as defined in EIP-1900 - `outputs` - type `dTypes`, as defined in EIP-1900 ### Implementation Suggestions In the dType registry implementation, `outputs` can be stored in a `mapping`: ``` mapping(bytes32 => dTypes[]) public outputs; ``` ## Rationale The suggestion to treat each `pure` or `view` function as a separate entity instead of having a contract-based approach allows us to: * have a global context of readily available functions * scale designs through functional programming patterns rather than contract-encapsulated logic (which can be successfully used to scale development efforts independently) * bidirectionally connect functions with the types they use, making automation easier * cherry-pick functions from already deployed contracts if the other contract functions do not pass community consensus * have scope-restricted improvements - instead of redeploying entire contracts, we can just redeploy the new function versions that we want to be added to the registry * enable fine-grained auditing of individual functions, for the common good * enable testing directly on a production chain, without state side-effects The proposal to store the minimum ABI information on-chain, for each function, allows us to: * enable on-chain automation (e.g. function chaining and composition) * be backward compatible in case the function signature format changes (e.g. from `bytes4` to `bytes32`): multiple signature calculation functions can be registered with dType. Examples: ``` function getSignatureBytes4(bytes32 identifier) view public returns (bytes4 signature) function getSignatureBytes32(bytes32 identifier) view public returns (bytes32 signature) ``` - `identifier` - the type's identifier, as defined in EIP-1900 - `signature` - the function's signature Concerns about this design might be: * redundancy of storing `contractAddress` for each function that is part of the same contract We think that state/storage cost will be compensated through DRYness across the chain, due to reusing types and functions that have already been registered and are now easy to find. Other state/storage cost calculations will be added once the specification and implementation are closer to be finalized. Note that the input and output types are based on types that have already been registered. This lowers the amount of ABI information needed to be stored for each function and enables developers to aggregate and find functions that use the same types for their I/O. This can be a powerful tool for interoperability and smart contract composition. ## Backwards Compatibility This proposal does not affect extant Ethereum standards or implementations. Registering functions for existing contract deployments should be fully supported. ## Test Cases Will be added. ## Implementation In-work implementation examples can be found at https://github.com/pipeos-one/dType. This proposal will be updated with an appropriate implementation when consensus is reached on the specifications. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 06 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1921 https://eips.ethereum.org/EIPS/eip-1921 zk-SNARK Verifier Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1922 ## Simple Summary A standard interface for "Verifier" contracts which verify zk-SNARKs. ## Abstract The following standard allows for the implementation of a standard contract API for the verification of zk-SNARKs ("Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge"), also known as "proofs", "arguments", or "commitments". This standard provides basic functionality to load all necessary parameters for the verification of any zk-SNARK into a verifier contract, so that the proof may ultimately return a `true` or `false` response; corresponding to whether it has been verified or not verified. ## Motivation zk-SNARKs are a promising area of interest for the Ethereum community. Key applications of zk-SNARKs include: - Private transactions - Private computations - Improved transaction scaling through proofs of "bundled" transactions A standard interface for verifying all zk-SNARKs will allow applications to more easily implement private transactions, private contracts, and scaling solutions; and to extract and interpret the limited information which gets emitted during zk-SNARK verifications. This standard was initially proposed by EY, and was inspired in particular by the requirements of businesses wishing to keep their agreements, transactions, and supply chain activities confidential—all whilst still benefiting from the commonly cited strengths of blockchains and smart contracts. :warning: TODO: Explain the benefits to and perspective of a consumer of information. I.e. the thing that interfaces with the standard verifier. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Terminology in this specification is used consistently with libsnark, as provided in that project's README. * Adhering Contract — A Verifier contract which adheres to this specification. * Arithmetic circuit: An abstraction of logical statements into addition and multiplication gates. * Public Inputs: often denoted as a vector 'x' in zk-SNARKs literature, and denoted `inputs` in this interface. An arithmetic circuit can be thought of as taking two parameters; the Public Inputs, 'x', and a secret 'witness', 'w'. This interface standardises functions which can load the `inputs` into an Adhering Contract. * Proof: A 'prover' who wants to 'prove' knowledge of some secret witness 'w' (which satisfies an arithmetic circuit), generates a `proof` from: the circuit's Proving Key; their secret witness 'w'; and its corresponding Public Inputs 'x'. Together, a pair `(proof, inputs)` of satisfying `inputs` and their corresponding `proof` forms a zk-SNARK. * Verification Key: A 'trusted setup' calculation creates both a public 'Proving Key' and a public 'Verification Key' from an arithmetic circuit. This interface does not provide a method for loading a Verification Key onto the blockchain. An Adhering Contract SHALL be able to accept arguments of knowledge (`(proof, inputs)` pairs) for at least one Verification Key. We shall call such Verification Keys 'in-scope' Verification Keys. An Adhering Contract MUST be able to interpret unambiguously a unique `verificationKeyId` for each of its 'in-scope' Verification Keys. **Every ERC-XXXX compliant verifier contract must implement the `ERCXXXX` and `ERC165` interfaces** (subject to "caveats" below): ```solidity pragma solidity ^0.5.6; /// @title EIP-XXXX zk-SNARK Verifier Standard /// @dev See https://github.com/EYBlockchain/zksnark-verifier-standard /// Note: the ERC-165 identifier for this interface is 0xXXXXXXXX. /// ⚠️ TODO: Calculate interface identifier interface EIPXXXX /* is ERC165 */ { /// @notice Checks the arguments of Proof, through elliptic curve /// pairing functions. /// @dev /// MUST return `true` if Proof passes all checks (i.e. the Proof is /// valid). /// MUST return `false` if the Proof does not pass all checks (i.e. if the /// Proof is invalid). /// @param proof A zk-SNARK. /// @param inputs Public inputs which accompany Proof. /// @param verificationKeyId A unique identifier (known to this verifier /// contract) for the Verification Key to which Proof corresponds. /// @return result The result of the verification calculation. True /// if Proof is valid; false otherwise. function verify(uint256[] calldata proof, uint256[] calldata inputs, bytes32 verificationKeyId) external returns (bool result); } ``` ### Interface ``` solidity interface ERC165 { /// @notice Query if a contract implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 /// @dev Interface identification is specified in ERC-165. This function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceID` and /// `interfaceID` is not 0xffffffff, `false` otherwise function supportsInterface(bytes4 interfaceID) external view returns (bool); } ``` ## Rationale ### Taxonomy ⚠️ TODO: Add a specific reference to libsnark here, explaining the choice of variable names. :warning: TODO: Explain how _C_ may not necessarily be a satisfiable arithmetic circuit of logical statements. As current, this is a limitation to certain kinds of SNARKS. Whereas the source references also mention polynomials, and other applications. _C_ — A satisfiable arithmetic circuit abstraction of logical statements. _lambda​_ - A random number, generated at the 'setup' phase - commonly referred to as 'toxic waste', because knowledge of _lambda​_ would allow an untrustworthy party to create 'false' proofs which would verify as 'true'. _lambda​_ must be destroyed. _pk​_ - The proving key for a particular circuit _C​_. _vk_ - The verification key for a particular circuit _C_. Both _pk​_ and _vk​_ are generated as a pair by some function _G​_: _(pk, vk) = G(lambda, C)​_ Note: _C_ can be represented unambiguously by either of _pk_ or _vk_. In zk-SNARK constructions, _vk_ is much smaller in size than _pk_, so as to enable succinct verification on-chain. Hence, _vk_ is the representative of _C_ that is 'known' to the contract. Therefore, we can identify each circuit uniquely through some `verificationKeyId`, where `verificationKeyId` serves as a more succinct mapping to _vk_. _w_ - A 'private witness' string. A private argument to the circuit _C_ known only to the prover, which, when combined with the `inputs` argument _x_, comprises an argument of knowledge which satisfies the circuit _C_. _x_ or `inputs` - A vector of 'Public Inputs'. A public argument to the circuit _C_ which, when combined with the private witness string _w_, comprises an argument of knowledge which satisfies the circuit _C_. _pi_ or `proof` - an encoded vector of values which represents the 'prover's' 'argument of knowledge' of values _w_ and _x_ which satisfy the circuit _C_. _pi = P(pk, x, w)_. The ultimate purpose of a Verifier contract, as specified in this EIP, is to verify a proof (of the form _pi​_) through some verification function _V​_. _V(vk, x, pi) = 1_, if there exists a _w_ s.t. _C(x,w)=1_. _V(vk, x, pi) = 0_, otherwise. The `verify()` function of this specification serves the purpose of _V​_; returning either `true` (the proof has been verified to satisfy the arithmetic circuit) or `false` (the proof has not been verified). ### Functions #### `verify` The `verify` function forms the crux this standard. The parameters are intended to be as generic as possible, to allow for verification of any zk-SNARK: - `proof` Specified as `uint256[]`. `uint256` is the most appropriate type for elliptic curve operations over a finite field. Indeed, this type is used in the predominant 'Pairing library' implementation of zk-SNARKs by Christian Reitweissner. A one-dimensional dynamic array has been chosen for several reasons: - Dynamic: There are several possible methods for producing a zk-SNARK proof, including PGHR13, G16, GM17, and future methods might be developed in future. Although each method may produce differently sized proof objects, a dynamic array allows for these differing sizes. - Array: An array has been chosen over a 'struct' object, because it is currently easier to pass dynamic arrays between functions in Solidity. Any proof 'struct' can be 'flattened' to an array and passed to the `verify` function. Interpretation of that flattened array is the responsibility of the implemented body of the function. Example implementations demonstrate that this can be achieved. - One-dimensional: A one-dimensional array has been chosen over multi-dimensional array, because it is currently easier to work with one-dimensional arrays in Solidity. Any proof can be 'flattened' to a one-dimensional array and passed to the `verify` function. Interpretation of that flattened array is the responsibility of the implemented body of the Adhering Contract. Example implementations demonstrate that this can be achieved. - `inputs` Specified as `uint256[]`. `uint256` is the most appropriate type for elliptic curve operations over a finite field. Indeed, this type is used in the predominant 'Pairing library' implementation of zk-SNARKs by Christian Reitweissner. The number of inputs will vary in size, depending on the number of 'public inputs' of the arithmetic circuit being verified against. In a similar vein to the `proof` parameter, a one-dimensional dynamic array is general enough to cope with any set of inputs to a zk-SNARK. - `verificationKeyId` A verification key (referencing a particular arithmetic circuit) only needs to be stored on-chain once. Any proof (relating to the underlying arithmetic circuit) can then be verified against that verification key. Given this, it would be unnecessary (from a 'gas cost' point of view) to pass a duplicate of the full verification key to the `verify` function every time a new `(proof, inputs)` pair is passed in. We do however need to tell the Adhering Verifier Contract which verification key corresponds to the `(proof, inputs)` pair being passed in. A `verificationKeyId` serves this purpose - it uniquely represents a verification key as a `bytes32` id. A method for uniquely assigning a `verificationKeyId` to a verification key is the responsibility of the implemented body of the Adhering Contract. ## Backwards Compatibility - At the time this EIP was first proposed, there was one implementation on the Ethereum main net - deployed by [EY](https://www.ey.com). This was compiled with Solidity 0.4.24 for compatibility with [Truffle](https://github.com/trufflesuite/truffle) but otherwise compatible with this standard, which is presented at the latest current version of Solidity. - Dr Christian Reitwiessner's excellent [example](https://gist.github.com/chriseth/f9be9d9391efc5beb9704255a8e2989d) of a Verifier contract and elliptic curve pairing library has been instrumental in the Ethereum community's experimentation and development of zk-SNARK protocols. Many of the naming conventions of this EIP have been kept consistent with his example. - Existing zk-SNARK compilers such as [ZoKrates](https://github.com/Zokrates/ZoKrates), which produce 'Verifier.sol' contracts, do not currently produce Verifier contracts which adhere to this EIP specification. - :warning: TODO: Provide a converter contract or technique which allows ZoKrates verifier.sol contracts to adhere with this EIP. ## Test Cases Truffle tests of example implementations are included in the test case repository. ⚠️ TODO: Reference specific test cases because there are many currently in the repository. ## Implementations Detailed example implementations and Truffle tests of these example implementations are included in this repository. :warning: TODO: Update referenced verifier implementations so that they are ready-to-deploy or reference deployed versions of those implementations. At current, the referenced code specifically states "DO NOT USE THIS IN PRODUCTION". :warning: TODO: Provide reference to an implementation which interrogates a standard verifier contract that implements this standard. ## References :warning: TODO: Update references and confirm that each reference is cited (parenthetical documentation not necessary) in the text. **Standards** 1. ERC-20 Token Standard. ./eip-20.md 1. ERC-165 Standard Interface Detection. ./eip-165.md 1. ERC-173 Contract Ownership Standard (DRAFT). ./eip-173.md 1. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. ./eip-196.md 1. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. ./eip-197.md 1. Ethereum Name Service (ENS). https://ens.domains 1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt ##### Educational material: zk-SNARKs 1. Zcash. What are zk-SNARKs? https://z.cash/technology/zksnarks.html 1. Vitalik Buterin. zk-SNARKs: Under the Hood. https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6 1. Christian Reitweissner. zk-SNARKs in a Nutshell. https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/ 1. Ben-Sasson, Chiesa, Tromer, et. al. Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture. https://eprint.iacr.org/2013/879.pdf ##### Notable applications of zk-SNARKs 1. EY. Implementation of a business agreement through Token Commitment transactions on the Ethereum mainnet. https://github.com/EYBlockchain/ZKPChallenge 1. Zcash. https://z.cash 1. Zcash. How Transactions Between Shielded Addresses Work. https://blog.z.cash/zcash-private-transactions/ ##### Notable projects relating to zk-SNARKs 1. libsnark: A C++ Library for zk-SNARKs ("project README)". https://github.com/scipr-lab/libsnark 1. ZoKrates: Scalable Privacy-Preserving Off-Chain Computations. https://www.ise.tu-berlin.de/fileadmin/fg308/publications/2018/2018_eberhardt_ZoKrates.pdf 1. ZoKrates Project Repository. https://github.com/JacobEberhardt/ZoKrates 1. Joseph Stockermans. zkSNARKs: Driver's Ed. https://github.com/jstoxrocky/zksnarks_example 1. Christian Reitweissner - snarktest.solidity. https://gist.github.com/chriseth/f9be9d9391efc5beb9704255a8e2989d ##### Notable 'alternatives' to zk-SNARKs - areas of ongoing zero-knowledge proof research 1. Vitalik Buterin. STARKs. https://web.archive.org/web/20230425101334/https://vitalik.ca/general/2017/11/09/starks_part_1.html 1. Bu ̈nz, Bootle, Boneh, et. al. Bulletproofs. https://eprint.iacr.org/2017/1066.pdf 1. Range Proofs. https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/canard.pdf 1. Apple. Secure Enclaves. https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave 1. Intel Software Guard Extensions. https://software.intel.com/en-us/sgx ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Fri, 14 Sep 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1922 https://eips.ethereum.org/EIPS/eip-1922 zk-SNARK Verifier Registry Standard Standards Track/ERC https://github.com/ethereum/EIPs/issues/1923 ## Simple Summary A standard interface for a "Verifier Registry"'" contract, through which all zk-SNARK verification activity can be registered. ## Abstract The following standard allows for the implementation of a standard contract API for the registration of zk-SNARKs ("Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge"), also known as "proofs", "arguments", or "commitments". TODO: Which functionality is exposed in this standard interface? ## Motivation zk-SNARKs are a promising area of interest for the Ethereum community. Key applications of zk-SNARKs include: - Private transactions - Private computations - Ethereum scaling through proofs of 'bundled' transactions A standard interface for registering all zk-SNARKs will allow applications to more easily implement private transactions, private contracts, and scaling solutions; and to extract and interpret the limited information which gets emitted during zk-SNARK verifications. :warning: TODO: Explain the motivation for standardizing a registry, other than simply standardizing the verifier interactions. ⚠️ TODO: Explain the benefits to and perspective of a consumer of information. I.e. the thing that interfaces with the standard verifier registry. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ```solidity pragma solidity ^0.5.6; /// @title EIP-XXXX zk-SNARK Verifier Registry Standard /// @dev See https://github.com/EYBlockchain/zksnark-verifier-standard /// Note: the ERC-165 identifier for this interface is 0xXXXXXXXXX. /// ⚠️ TODO: Set the interface identifier interface EIP-XXXX /* is ERC165 */ { event NewProofSubmitted(bytes32 indexed _proofId, uint256[] _proof, uint64[] _inputs); event NewVkRegistered(bytes32 indexed _vkId); event NewVerifierContractRegistered(address indexed _contractAddress); event NewAttestation(bytes32 indexed _proofId, address indexed _verifier, bool indexed _result); function getVk(bytes32 _vkId) external returns (uint256[] memory); function registerVerifierContract(address _verifierContract) external returns (bool); function registerVk(uint256[] calldata _vk, address[] calldata _verifierContracts) external returns (bytes32); function submitProof(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId) external returns (bytes32); function submitProof(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId, address _verifierContract) external returns (bytes32); function submitProofAndVerify(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId, address _verifierContract) external returns (bytes32); function attestProof(bytes32 _proofId, bytes32 _vkId, bool _result) external; function attestProofs(bytes32[] calldata _proofIds, bytes32[] calldata _vkIds, bool[] calldata _results) external; function challengeAttestation(bytes32 _proofId, uint256[] calldata _proof, uint64[] calldata _inputs, address _verifierContract) external; function createNewVkId(uint256[] calldata _vk) external pure returns (bytes32); function createNewProofId(uint256[] calldata _proof, uint64[] calldata _inputs) external pure returns (bytes32); } ``` ### Interface ``` solidity interface ERC165 { /// @notice Query if a contract implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 /// @dev Interface identification is specified in ERC-165. This function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceID` and /// `interfaceID` is not 0xffffffff, `false` otherwise function supportsInterface(bytes4 interfaceID) external view returns (bool); } ``` ## Rationale ⚠️ TODO: Add Rationale section. ### Backwards Compatibility ⚠️ TODO: Add Backwards Compatibility section. ### Test Cases Truffle tests of example implementations are included in this Repo. ⚠️ TODO: Reference specific test cases because there are many currently in the repository. ## Implementations Detailed example implementations and Truffle tests of these example implementations are included in this Repo. ⚠️ TODO: Update referenced verifier registry implementations so that they are ready-to-deploy or reference deployed versions of those implementations. At current, the referenced code specifically states "DO NOT USE THIS IN PRODUCTION". ⚠️ TODO: Provide reference to an implementation which interrogates a standard verifier registry contract that implements this standard. ## References ⚠️ TODO: Update references and confirm that each reference is cited (parenthetical documentation not necessary) in the text. **Standards** 1. ERC-20 Token Standard. ./eip-20.md 1. ERC-165 Standard Interface Detection. ./eip-165.md 2. ERC-173 Contract Ownership Standard (DRAFT). ./eip-173.md 3. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. ./eip-196.md 4. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. ./eip-197.md 5. Ethereum Name Service (ENS). https://ens.domains 6. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt ##### Educational material: zk-SNARKs 1. Zcash. What are zk-SNARKs? https://z.cash/technology/zksnarks.html 2. Vitalik Buterin. zk-SNARKs: Under the Hood. https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6 3. Christian Reitweissner. zk-SNARKs in a Nutshell. https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/ 4. Ben-Sasson, Chiesa, Tromer, et. al. Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture. https://eprint.iacr.org/2013/879.pdf ##### Notable applications of zk-SNARKs 1. EY. Implementation of a business agreement through Token Commitment transactions on the Ethereum mainnet. https://github.com/EYBlockchain/ZKPChallenge 2. Zcash. https://z.cash 3. Zcash. How Transactions Between Shielded Addresses Work. https://blog.z.cash/zcash-private-transactions/ ##### Notable projects relating to zk-SNARKs 1. libsnark: A C++ Library for zk-SNARKs ("project README)". https://github.com/scipr-lab/libsnark 2. ZoKrates: Scalable Privacy-Preserving Off-Chain Computations. https://www.ise.tu-berlin.de/fileadmin/fg308/publications/2018/2018_eberhardt_ZoKrates.pdf 3. ZoKrates Project Repository. https://github.com/JacobEberhardt/ZoKrates 4. Joseph Stockermans. zkSNARKs: Driver's Ed. https://github.com/jstoxrocky/zksnarks_example 5. Christian Reitweissner - snarktest.solidity. https://gist.github.com/chriseth/f9be9d9391efc5beb9704255a8e2989d ##### Notable 'alternatives' to zk-SNARKs - areas of ongoing zero-knowledge proof research 1. Vitalik Buterin. STARKs. https://web.archive.org/web/20230425101334/https://vitalik.ca/general/2017/11/09/starks_part_1.html 2. Bu ̈nz, Bootle, Boneh, et. al. Bulletproofs. https://eprint.iacr.org/2017/1066.pdf 3. Range Proofs. https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/canard.pdf 4. Apple. Secure Enclaves. https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave 5. Intel Software Guard Extensions. https://software.intel.com/en-us/sgx ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 22 Dec 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1923 https://eips.ethereum.org/EIPS/eip-1923 CALLs with strict gas semantic. Revert if not enough gas available. Standards Track/Core https://github.com/ethereum/EIPs/issues/1930 ## Simple Summary Add the ability for smart contract to execute calls with a specific amount of gas. If this is not possible the execution should revert. ## Abstract The current CALL, DELEGATE_CALL, STATIC_CALL opcode do not enforce the gas being sent, they simply consider the gas value as a maximum. This pose serious problem for applications that require the call to be executed with a precise amount of gas. This is for example the case for meta-transaction where the contract needs to ensure the call is executed exactly as the signing user intended. But this is also the case for common use cases, like checking "on-chain" if a smart contract support a specific interface (via [EIP-165](/EIPS/eip-165) for example). The solution presented here is to add new call semantic that enforce the amount of gas specified : the call either proceed with the exact amount of gas or do not get executed and the current call revert. ### Specification There are 2 possibilities a) one is to add opcode variant that have a stricter gas semantic b) The other is to consider a specific gas value range (one that have never been used before) to have strict gas semantic, while leaving other values as before Here are the details description #### option a) - add a new variant of the CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert - add a new variant of the DELEGATE_CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert - add a new variant of the STATIC_CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert ##### Rational for a) This solution has the merit to avoid any possibility of old contract be affected by the change. On the other hand it introduce 3 new opcodes. With EIP-1702, we could render the old opcode obsolete though. #### option b) For all opcode that allow to pass gas to another contract, do the following: - If the most significant bit is one, consider the 31 less significant bit as the amount of gas to be given to the receiving contract in the strict sense. SO like a) if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert. - If the 2nd most significant bit is zero, consider the whole value to behave like before, that is, it act as a maximum value, and even if not enough gas is present, the gas that can be given is given to the receiving contract ##### Rational for b) This solution relies on the fact that no contract would have given any value bigger or equal to 0x8000000000000000000000000000000000000000000000000000000000000000 Note that solidity for example do not use value like 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF as it is more expensive than passing the gasLeft. Its main benefit though is that it does not require extra opcodes. #### strict gas semantic To be precise, regarding the strict gas semantic, based on [EIP-150](/EIPS/eip-150), the current call must revert unless G >= I x 64/63 where G is gas left at the point of call (after deducing the cost of the call itself) and I is the gas specified. So instead of ``` availableGas = availableGas - base gas := availableGas - availableGas/64 ... if !callCost.IsUint64() || gas < callCost.Uint64() { return gas, nil } ``` see https://github.com/ethereum/go-ethereum/blob/7504dbd6eb3f62371f86b06b03ffd665690951f2/core/vm/gas.go#L41-L48 we would have ``` availableGas = availableGas - base gas := availableGas - availableGas/64 if !callCost.IsUint64() || gas < callCost.Uint64() { return 0, errNotEnoughGas } ``` ### Rationale Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. This is an issue for contracts that require external call to only fails if they would fails with enough gas. This requirement is present in smart contract wallet and meta transaction in general, where the one executing the transaction is not the signer of the execution data. Because in such case, the contract needs to ensure the call is executed exactly as the signing user intended. But this is also true for simple use case, like checking if a contract implement an interface via EIP-165. Indeed as specified by such EIP, the ```supporstInterface``` method is bounded to use 30,000 gas so that it is theoretically possible to ensure that the throw is not a result of a lack of gas. Unfortunately due to how the different CALL opcodes behave contracts can't simply rely on the gas value specified. They have to ensure by other means that there is enough gas for the call. Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interpreting wrongly that the callee is not implementing the interface in question. While such requirement can be enforced by checking the gas left according to EIP-150 and the precise gas required before the call (see solution presented in that [bug report](https://web.solidified.io/contract/5b4769b1e6c0d80014f3ea4e/bug/5c83d86ac2dd6600116381f9) or after the call (see the native meta transaction implementation [here](https://github.com/pixowl/thesandbox-contracts/blob/623f4d4ca10644dcee145bcbd9296579a1543d3d/src/Sand/erc20/ERC20MetaTxExtension.sol#L176), it would be much better if the EVM allowed us to strictly specify how much gas is to be given to the CALL so contract implementations do not need to follow [EIP-150](/EIPS/eip-150) behavior and the current gas pricing so closely. This would also allow the behaviour of [EIP-150](/EIPS/eip-150) to be changed without having to affect contract that require this strict gas behaviour. As mentioned, such strict gas behaviour is important for smart contract wallet and meta transaction in general. The issue is actually already a problem in the wild as can be seen in the case of Gnosis safe which did not consider the behavior of EIP-150 and thus fails to check the gas properly, requiring the safe owners to add otherwise unnecessary extra gas to their signed message to avoid the possibility of losing funds. See https://github.com/gnosis/safe-contracts/issues/100 As for EIP-165, the issue already exists in the example implementation presented in the EIP. Please see the details of the issue [here](https://github.com/ethereum/EIPs/pull/881#issuecomment-491677748) The same issue exists also on OpenZeppelin implementation, a library used by many. It does not for perform any check on gas before calling ```supportsInterface``` with 30,000 gas (see [here](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/fa004a7f5de572b3dbcde1a8a81f9a87e353e799/contracts/introspection/ERC165Checker.sol#L37) and is thus vulnerable to the issue mentioned. While such issue can be prevented today by checking the gas with EIP-150 in mind, a solution at the opcode level is more elegant. Indeed, the two possible ways to currently enforce that the correct amount of gas is sent are as follow : 1) check done before the call ``` uint256 gasAvailable = gasleft() - E; require(gasAvailable - gasAvailable / 64 >= `txGas`, "not enough gas provided") to.call.gas(txGas)(data); // CALL ``` where E is the gas required for the operation between the call to ```gasleft()``` and the actual call PLUS the gas cost of the call itself. While it is possible to simply over estimate ```E``` to prevent call to be executed if not enough gas is provided to the current call it would be better to have the EVM do the precise work itself. As gas pricing continue to evolve, this is important to have a mechanism to ensure a specific amount of gas is passed to the call so such mechanism can be used without having to relies on a specific gas pricing. 2) check done after the call: ``` to.call.gas(txGas)(data); // CALL require(gasleft() > txGas / 63, "not enough gas left"); ``` This solution does not require to compute a ```E``` value and thus do not relies on a specific gas pricing (except for the behaviour of EIP-150) since if the call is given not enough gas and fails for that reason, the condition above will always fail, ensuring the current call will revert. But this check still pass if the gas given was less AND the external call reverted or succeeded EARLY (so that the gas left after the call > txGas / 63). This can be an issue if the code executed as part of the CALL is reverting as a result of a check against the gas provided. Like a meta transaction in a meta transaction. Similarly to the previous solution, an EVM mechanism would be much better. ## Backwards Compatibility for specification a) : Backwards compatible as it introduce new opcodes. for specification b) : Backwards compatible as it use value range outside of what is used by existing contract (to be verified) ## Test Cases ## Implementation None fully implemented yet. But see Specifications for an example in geth. ## References 1. EIP-150, ./eip-150.md ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 10 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1930 https://eips.ethereum.org/EIPS/eip-1930 Non-fungible Data Token Standards Track/ERC https://ethereum-magicians.org/t/erc-non-fungible-data-token/3139 ## Simple Summary Some NFT use-cases require to have dynamic data associated with a non-fungible token that can change during its lifetime. Examples for dynamic data: - cryptokitties that can change color - intellectual property tokens that encode rights holders - tokens that store data to transport them across chains The existing metadata standard does not suffice as data can only be set at minting time and not modified later. ## Abstract Non-fungible tokens (NFTs) are extended with the ability to store dynamic data. A 32 bytes data field is added and a read function allows to access it. The write function allows to update it, if the caller is the owner of the token. An event is emitted every time the data updates and the previous and new value is emitted in it. ## Motivation The proposal is made to standardize on tokens with dynamic data. Interactions with bridges for side-chains like xDAI or Plasma chains will profit from the ability to use such tokens. Protocols that build on data tokens like [distributed breeding](https://ethresear.ch/t/a-distributed-breeding-function/5264) will be enabled. ## Specification An extension of [ERC-721](/EIPS/eip-721) interface with the following functions and events is suggested: ``` solidity pragma solidity ^0.5.2; /** * @dev Interface of the ERC1948 contract. */ interface IERC1948 { /** * @dev Emitted when `oldData` is replaced with `newData` in storage of `tokenId`. * * Note that `oldData` or `newData` may be empty bytes. */ event DataUpdated(uint256 indexed tokenId, bytes32 oldData, bytes32 newData); /** * @dev Reads the data of a specified token. Returns the current data in * storage of `tokenId`. * * @param tokenId The token to read the data off. * * @return A bytes32 representing the current data stored in the token. */ function readData(uint256 tokenId) external view returns (bytes32); /** * @dev Updates the data of a specified token. Writes `newData` into storage * of `tokenId`. * * @param tokenId The token to write data to. * @param newData The data to be written to the token. * * Emits a `DataUpdated` event. */ function writeData(uint256 tokenId, bytes32 newData) external; } ``` ## Rationale The suggested data field in the NFT is used either for storing data directly, like a counter or address. If more data is required the implementer should fall back to authenticated data structures, like merkle- or patricia-trees. The proposal for this ERC stems from the [distributed breeding proposal](https://ethresear.ch/t/a-distributed-breeding-function/5264) to allow better integration of NFTs across side-chains. [ost.com](https://ost.com/), [Skale](https://skalelabs.com/), [POA](https://poa.network/), and [LeapDAO](https://leapdao.org/) have been part of the discussion. ## Backwards Compatibility 🤷‍♂️ No related proposals are known to the author, hence no backwards compatibility to consider. ## Test Cases Simple happy test: ``` javascript const ERC1948 = artifacts.require('./ERC1948.sol'); contract('ERC1948', (accounts) => { const firstTokenId = 100; const empty = '0x0000000000000000000000000000000000000000000000000000000000000000'; const data = '0x0101010101010101010101010101010101010101010101010101010101010101'; let dataToken; beforeEach(async () => { dataToken = await ERC1948.new(); await dataToken.mint(accounts[0], firstTokenId); }); it('should allow to write and read', async () => { let rsp = await dataToken.readData(firstTokenId); assert.equal(rsp, empty); await dataToken.writeData(firstTokenId, data); rsp = await dataToken.readData(firstTokenId); assert.equal(rsp, data); }); }); ``` ## Implementation An example implementation of the interface in solidity would look like this: ``` solidity /** * @dev Implementation of ERC721 token and the `IERC1948` interface. * * ERC1948 is a non-fungible token (NFT) extended with the ability to store * dynamic data. The data is a bytes32 field for each tokenId. If 32 bytes * do not suffice to store the data, an authenticated data structure (hash or * merkle tree) shall be used. */ contract ERC1948 is IERC1948, ERC721 { mapping(uint256 => bytes32) data; /** * @dev See `IERC1948.readData`. * * Requirements: * * - `tokenId` needs to exist. */ function readData(uint256 tokenId) external view returns (bytes32) { require(_exists(tokenId)); return data[tokenId]; } /** * @dev See `IERC1948.writeData`. * * Requirements: * * - `msg.sender` needs to be owner of `tokenId`. */ function writeData(uint256 tokenId, bytes32 newData) external { require(msg.sender == ownerOf(tokenId)); emit DataUpdated(tokenId, data[tokenId], newData); data[tokenId] = newData; } } ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Thu, 18 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1948 https://eips.ethereum.org/EIPS/eip-1948 New Opcode to check if a chainID is part of the history of chainIDs Standards Track/Core https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170 ## Simple Summary To protect off-chain messages from being reused across different chain, a mechanism need to be given to smart contract to only accept messages for that chain. Since a chain can change its chainID, the mechanism should consider old chainID valid. ## Abstract This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current chainID). ## Motivation [EIP-155](/EIPS/eip-155) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](/EIPS/eip-712). [EIP-1344](/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. ## Specification Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history (since genesis) of chainIDs of that chain, ```0x0``` otherwise. The operation costs `G_blockhash` to execute. The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows. Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost. As such the gas cost is simply a necessary cost for the feature. ## Rationale The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per [EIP-712](/EIPS/eip-712) (with the previous chainID) will fails to be accepted by the contracts after the fork. That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract. While this works (except for a temporary gap where the immediately previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before a hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs. Indeed letting contracts access the latest chainID for L2 message verification is dangerous. The latest chainID is only the tip of the chainID history. As a changing value, the latest chainID is thus not appropriate to ensure the validity of L2 messages. Users signing off-chain messages expect their messages to be valid from the time of signing and do not expect these message to be affected by a future hardfork. If the contract use the latest chainID as is for verification, the messages would be invalid as soon as a hardfork that update the chainID happens. For some applications, this will require users to resubmit a new message (think meta transaction), causing them potential loss (or some inconvenience during the hardfork transition), but for some other applications (think state channel) the whole off-chain state become inaccessible, resulting in potentially disastrous situations. In other words, we should consider all off-chain messages (with valid chainID) as part of the chain's offchain state. The opcode proposed here, offer smart contracts a simple and safe method to ensure that the offchain state stay valid across fork. As for replay protection, the idea of considering all of the off-chain messages signed with valid chainID as part of the chain's offchain-state means that all of these off-chain messages can be reused on the different forks which share a common chainID history (up to where they differ). This is actually an important feature since as mentioned, users expect their signed messages to be valid from the time of signing. From that time onwards these messages should be considered as part of the chain's offchain state. A hardfork should not thus render them invalid. This is similar to how the previous on-chain state is shared between 2 hardforks. The wallets will make sure that at any time, a signing message request use the latest chainID of the chain being used. This prevent replay attack onto chain that have different chainID histories (they would not have the same latest chainID). Now it is argued in the [EIP1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131) that when a contentious hardfork happen and one side of the fork decide to not update its chainID, that side of the chain would be vulnerable to replays since users will keep signing with a chainID that is also valid in the chain that forked. An issue also present in EIP-1344. This is simply a natural consequence of using chainID as the only anti-replay information for L2 messages. But this can indeed be an issue if the hardfork is created by a small minority. In that case if the majority ignore the fork and do not update its chainID, then all new message from the majority chain (until they update their chainID) can be replayed on the minority-led hardfork since the majority's current chainID is also part of the minority-led fork's chainID history. To fix this, every message could specify the block number representing the time it was signed. The contract could then verify that chainID specified as part of that message was valid at that particular block. While EIP-1344 can't do that accurately as the caching system might leave a gap, this proposal can solve it if it is modified to return the blockNumber at which a chainID become invalid. Unfortunately, this would be easy for contracts to not perform that check. And since it suffice of only one important applications to not follow this procedure to put the minority-led fork at a disadvantage, this would fail to achieve the desired goal of protecting the minority-led fork from replay. Since a minority-led fork ignored by the majority means that the majority will not keep track of the messages to be submitted (state channel, ...), if such fork get traction later, this would be at the expense of majority users who were not aware of it. As such this proposal assume that minority-led fork will not get traction later and thus do not require to be protected. ## Test Cases TBD ## Implementation TBD ## Backwards Compatibility This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. Existing contract are not affected. Similarly to EIP-1344, it might be beneficial to update EIP-712 (still in Draft) to deal with chainID separately from the domain separator. Indeed since chainID is expected to change, if the domain separator include chainID, it would have to be dynamically computed. A caching mechanism could be used by smart contract instead though. ## References This was previously suggested as part of [EIP-1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/39). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 20 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1959 https://eips.ethereum.org/EIPS/eip-1959 EC arithmetic and pairings with runtime definitions Standards Track/Core https://ethereum-magicians.org/t/generalised-precompile-for-elliptic-curve-arithmetics-and-pairings-working-group/3208/2 # Simple summary This proposal is an extension and formalization of [EIP-1829](/EIPS/eip-1829) with an inclusion of pairings. [EIP-1109](/EIPS/eip-1109) is required due to low cost of some operations compared to the `STATICCALL` opcode (more information in the corresponding section below). ## Abstract This EIP proposes a new precompile to bring cryptographic functionality desired for privacy and scaling solutions. Functionality of such precompile will require the following: - Implementation the following operations over elliptic curves in the Weierstrass form with curve parameters such as base field, A, B coefficients defined in runtime: - Point addition - Multiplication of a single point over a scalar - Multiexponentiation - Implementation pairing operation over elliptic curves from the following "families" with parameters such as base field, extension tower structure, coefficients defined in runtime: - BLS12 - BN - MNT4/6 (Ate pairing) Full functionality of the precompile is described below in `Specification` section. ## Motivation - There is a pending proposal to implement base elliptic curve arithmetic is covered by [EIP-1829](/EIPS/eip-1829) and will allow to implement various privacy-preserving protocols with a reasonable gas costs per operation. - Pairings are an important extension for basic arithmetic and so this new precompile is proposed with the following benefits: - Extended set of curves will be available to allow Ethereum users to choose their security parameters and required functionality. - Generic approach of this precompile will allow Ethereum users to experiment with newly found curves of their choice and new constructions constructions without waiting for new forks. - EC arithmetic is indeed re-implemented in this precompile, but it's strictly required. Most of the pairing-based protocols still need to perform standard EC multiplications or additions and thus such operations must be available on generic set of curves. - Gas costs - this EIP is designed to estimate gas-cost of performed operation as early as possible during the call and base if solely on specified parameters and operation type. This is a strict requirement for any precompile to allow Ethereum nodes to efficiently reject transactions and operations as early as possible. Functionality of this newly proposed precompile is different from [EIP-1829](/EIPS/eip-1829) in the following aspects: - Operation on arbitrary-length modulus (up to some upper-limit) for a base field and scalar field of the curve - Pairing operations are introduced - Different ABI due to variable parameter length ## Specification If `block.number >= XXXXX`, define a set of `10` new precompiles with an addresses `[0x.., 0x.., ...]` and the following functionality. - Addition of points on the curve defined over base field - Multiplication of a point on the curve defined over base field - Multiexponentiation for `N` pairs of `(scalar, point)` on the curve defined over base field - Addition of points on the curve defined over quadratic or cubic extension of the base field - Multiplication of a point on the curve defined over quadratic or cubic extension of the base field - Multiexponentiation for `N` pairs of `(scalar, point)` on the curve defined over quadratic or cubic extension of the base field - Pairing operation on the curve of `BLS12` family - Pairing operation on the curve of `BN` family - Pairing operation on the curve of `MNT4` family - Pairing operation on the curve of `MNT6` family Due to actuve development of the precompile and a lot of ongoing changes there is a single [source of truth](https://github.com/matter-labs/eip1962/tree/master/documentation). It covers binary interface, gas schedule, integration guide for existing implementations. ### Possible simplifications Due to high complexity of the proposed operations in the aspects of implementation, debugging and evaluation of the factors for gas costs it may be appropriate to either limit the set of curves at the moment of acceptance to some list and then extend it. Another approach (if it's technically possible) would be to have the "whilelist" contract that can be updated without consensus changes (w/o fork). In the case of limited set of curve the following set is proposed as a minimal: - BN254 curve from the current version of Ethereum - BN curve from DIZK with 2^32 roots of unity - BLS12-381 - BLS12-377 from ZEXE with large number of roots of unity - MNT4/6 cycle from the original [paper](https://eprint.iacr.org/2014/595.pdf). It's not too secure, but may give some freedom for experiments. - MNT4/6 cycle from Coda if performance allows - Set of CP generated curves that would allow embedding of BLS12-377 and may be some BN curve that would have large power of two divisor for both base field and scalar field modulus (example of CP curve for BLS12-377 can be found in ZEXE). ## Rationale Only the largest design decisions will be covered: - While there is no arithmetic over the scalar field (which is modulo size of the main group) of the curve, it's required for gas estimation purposes. - Multiexponentiation is a separate operation due to large cost saving - There are no point decompressions due to impossibility to get universal gas estimation of square root operation. For a limited number of "good" cases prices would be too different, so specifying the "worst case" is expensive and inefficient, while introduction of another level if complexity into already complicated gas costs formula is not worth is. ### This precompile and EIP 1109 While there is no strict requirement of EIP 1109 for functionality, here is an example why it would be desired: - BLS12-381 curve, 381 bit modulus, 255 bit scalar field, no native arithmetic is available in EVM for this - Point addition would take 5000ns (quite overestimated) - Point multiplication would take roughly 150000ns - Crude gas schedule 15 Mgas/second from ECRecover precompile - Point addition would cost 75 gas, with `STATICCALL` adding another 700 - Point multiplication would cost 2250 gas - One should also add the cost of memory allocation that is at least `1 + 1 + 48 + 48 + 48 + 1 + 32 + 2*48 + 2*48 = 371 byte` that is around 12 native Ethereum "words" and will require extra 36 gas (with negligible price for memory extension) Based on these quite crude estimations one can see that `STATICCALL` price will dominate the total cost (in case of addition) or bring significant overhead (in case of multiplication operation) in case of calls to this precompile. ## Backwards Compatibility This change is not backwards compatible and requires hard fork to be activated. Functionality of the new precompile itself does not affect any existing functionality of Ethereum or EVM. This precompile may serve as a complete replacement of the current set of `ECADD`, `ECMUL` and pairing check precompiles (`0x06`, `0x07`, `0x08`) ## Test Cases Test cases are the part of the implementation with a link below. ## Implementation There is an ongoing implementation effort [here](https://github.com/matter-labs/eip1829). Right now: - Non-pairing operations are implemented and tested. - BLS12 family is completed and tested for BLS12-381 and BLS12-377 curves. - BN family is completed and tested with BN254 curve. - Cocks-Pinch method curve is tested for k=6 curve from ZEXE. ## Preliminary benchmarks cp6 in benchmarks is a Cocks-Pinch method curve that embeds BLS12-377. Machine: Core i7, 2.9 GHz. Multiexponentiation benchmarks take 100 pairs `(generator, random scalar)` as input. Due to the same "base" it may be not too representative benchmark and will be updated. ``` test pairings::bls12::tests::bench_bls12_381_pairing ... bench: 2,348,317 ns/iter (+/- 605,340) test pairings::cp::tests::bench_cp6_pairing ... bench: 86,328,825 ns/iter (+/- 11,802,073) test tests::bench_addition_bn254 ... bench: 388 ns/iter (+/- 73) test tests::bench_doubling_bn254 ... bench: 187 ns/iter (+/- 4) test tests::bench_field_inverse ... bench: 2,478 ns/iter (+/- 167) test tests::bench_field_mont_inverse ... bench: 2,356 ns/iter (+/- 51) test tests::bench_multiplication_bn254 ... bench: 81,744 ns/iter (+/- 6,984) test tests::bench_multiplication_bn254_into_affine ... bench: 81,925 ns/iter (+/- 3,323) test tests::bench_multiplication_bn254_into_affine_wnaf ... bench: 74,716 ns/iter (+/- 4,076) test tests::bench_naive_multiexp_bn254 ... bench: 10,659,911 ns/iter (+/- 559,790) test tests::bench_peppinger_bn254 ... bench: 2,678,743 ns/iter (+/- 148,914) test tests::bench_wnaf_multiexp_bn254 ... bench: 9,161,281 ns/iter (+/- 456,137) ``` ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Mon, 22 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1962 https://eips.ethereum.org/EIPS/eip-1962 Method to check if a chainID is valid at a specific block Number Standards Track/Core https://ethereum-magicians.org/t/eip-1965-valid-chainid-for-specific-blocknumber-protect-all-forks/3181 ## Abstract This EIP adds a precompile that returns whether a specific chainID (EIP-155 unique identifier) is valid at a specific blockNumber. ChainID are assumed to be valid up to the blockNumber at which they get replaced by a new chainID. ## Motivation [EIP-155](/EIPS/eip-155) proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using [EIP-712](/EIPS/eip-712). [EIP-1344](/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced. [EIP-1959](/EIPS/eip-1959) solves the issue of EIP-1344 but does not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it removes some freedom to fork. We consider that all fork should be given equal opportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.** ## Specification Adds a new precompile which uses 2 arguments : a 32 bytes value that represents the chainID to test and a 32 bytes value representing the blockNumber at which the chainID is tested. It returns 0x1 if the chainID is valid at the specific blockNumber, 0x0 otherwise. Note that chainID are considered valid up to the blockNumber at which they are replaced. So they are valid for every blockNumber past their replacement. The operation will costs no more than `G_blockhash` + `G_verylow` to execute. This could be lower as chainID are only introduced during hardfork. The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows. Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost and exhibit issues for minority-led hardfork (see Rationale section below). As such the gas cost is simply a necessary cost for the feature. ## Rationale The rationale at EIP-1959 applies here as well too : - An opcode is better than a caching system for past chainID, It is cheaper, safer and does not include gaps. - Direct access to the latest chainID is dangerous since it makes it easy for contracts to use it as a replay protection mechanism while preventing otherwise valid old messages to be valid after a fork that changes the chainID. This can have disastrous consequences on users. - all off-chain messages signed before a fork should be valid across all side of the fork. The only difference is that this current proposal proposes a solution to protect hardfork led by a minority. To summarize there is 2 possible fork scenario : 1) The majority decide to make a hardfork but a minority disagree with it (ETC is such example). The fork is planned for block X. If the majority is not taking any action to automate the process of assigning a different chainID for both, the minority has plenty of time to plan for a chainID upgrade to happen at that same block X. Now if they do not do it, their users will face the problem that their messages will be replayable on the majority chain (Note that this is not true the other way around as we assume the majority decided to change the chainID). As such there is no reason that they will leave it that way. 2) A minority decide to create a hardfork that the majority disagree with (or simply ignore). Now, the same as above can happen but since we are talking about a minority there is a chance that the majority does not care about the minority. In that case, there would be no incentive for the majority to upgrade the chainID. This means that users of both sides of the fork will have the messages meant for the majority chain replayable on the minority-chain (even if this one changed its chainID) unless extra precaution is taken. The solution is to add the blockNumber representing the time at which the message was signed and use it as an argument to the opcode proposed here. This way, when the minority forks with a new chainID, the previous chainID become invalid from that time onward. So new messages destined to the majority chain can't be replayed on the minority fork. ## Backwards Compatibility EIP-712 is still in draft but would need to be updated to include the blockNumber as part of the values that wallets need to verify for the protection of their users. Since chainID and blockNumber will vary, they should not be part of the domain separator (meant to be generated once) but another part of the message. While the pair could be optional for contract that do not care about replays or have other ways to prevent them, if chainID is present, the blockNumber must be present too. And if any of them is present, wallet need to ensure that the chainID is indeed the latest one of the chain being used, while the blockNumber is the latest one at the point of signing. During fork transition, the wallet can use the blockNumber to know which chainID to use. ## References This was previously suggested as part of [EIP1959 discussion](https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sat, 20 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1965 https://eips.ethereum.org/EIPS/eip-1965 Proxy Storage Slots Standards Track/ERC https://ethereum-magicians.org/t/eip-1967-standard-proxy-storage-slots/3185 ## Abstract Delegating **proxy contracts** are widely used for both upgradeability and gas savings. These proxies rely on a **logic contract** (also known as implementation contract or master copy) that is called using `delegatecall`. This allows proxies to keep a persistent state (storage and balance) while the code is delegated to the logic contract. To avoid clashes in storage usage between the proxy and logic contract, the address of the logic contract is typically saved in a specific storage slot (for example `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` in OpenZeppelin contracts) guaranteed to be never allocated by a compiler. This EIP proposes a set of standard slots to store proxy information. This allows clients like block explorers to properly extract and show this information to end users, and logic contracts to optionally act upon it. ## Motivation Delegating proxies are widely in use, as a means to both support upgrades and reduce gas costs of deployments. Examples of these proxies are found in OpenZeppelin Contracts, Gnosis, AragonOS, Melonport, Limechain, WindingTree, Decentraland, and many others. However, the lack of a common interface for obtaining the logic address for a proxy makes it impossible to build common tools that act upon this information. A classic example of this is a block explorer. Here, the end user wants to interact with the underlying logic contract and not the proxy itself. Having a common way to retrieve the logic contract address from a proxy allows a block explorer to show the ABI of the logic contract and not that of the proxy. The explorer checks the storage of the contract at the distinguished slots to determine if it is indeed a proxy, in which case it shows information on both the proxy and the logic contract. As an example, this is how `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` is shown on Etherscan: ![Sample proxy on Etherscan](/assets/eip-1967/Sample-proxy-on-etherscan.png) Another example is logic contracts that explicitly act upon the fact that they are being proxied. This allows them to potentially trigger a code update as part of their logic. A common storage slot allows these use cases independently of the specific proxy implementation being used. ## Specification Monitoring of proxies is essential to the security of many applications. It is thus essential to have the ability to track changes to the implementation and admin slots. Unfortunately, tracking changes to storage slots is not easy. Consequently, it is recommended that any function that changes any of these slots SHOULD also emit the corresponding event. This includes initialization, from `0x0` to the first non-zero value. The proposed storage slots for proxy-specific information are the following. More slots for additional information can be added in subsequent ERCs as needed. ### Logic contract address Storage slot `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` (obtained as `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)`). Holds the address of the logic contract that this proxy delegates to. SHOULD be empty if a beacon is used instead. Changes to this slot SHOULD be notified by the event: ```solidity event Upgraded(address indexed implementation); ``` ### Beacon contract address Storage slot `0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50` (obtained as `bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)`). Holds the address of the beacon contract this proxy relies on (fallback). SHOULD be empty if a logic address is used directly instead, and should only be considered if the logic contract slot is empty. Changes to this slot SHOULD be notified by the event: ```solidity event BeaconUpgraded(address indexed beacon); ``` Beacons are used for keeping the logic address for multiple proxies in a single location, allowing the upgrade of multiple proxies by modifying a single storage slot. A beacon contract MUST implement the function: ``` function implementation() returns (address) ``` Beacon based proxy contracts do not use the logic contract slot. Instead, they use the beacon contract slot to store the address of the beacon they are attached to. In order to know the logic contract used by a beacon proxy, a client SHOULD: - Read the address of the beacon for the beacon logic storage slot; - Call the `implementation()` function on the beacon contract. The result of the `implementation()` function on the beacon contract SHOULD NOT depend on the caller (`msg.sender`). ### Admin address Storage slot `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103` (obtained as `bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1)`). Holds the address that is allowed to upgrade the logic contract address for this proxy (optional). Changes to this slot SHOULD be notified by the event: ```solidity event AdminChanged(address previousAdmin, address newAdmin); ``` ## Rationale This EIP standardises the **storage slot** for the logic contract address, instead of a public method on the proxy contract. The rationale for this is that proxies should never expose functions to end users that could potentially clash with those of the logic contract. Note that a clash may occur even among functions with different names, since the ABI relies on just four bytes for the function selector. This can lead to unexpected errors, or even exploits, where a call to a proxied contract returns a different value than expected, since the proxy intercepts the call and answers with a value of its own. From _Malicious backdoors in Ethereum proxies_ by Nomic Labs: > Any function in the Proxy contract whose selector matches with one in the implementation contract will be called directly, completely skipping the implementation code. > > Because the function selectors use a fixed amount of bytes, there will always be the possibility of a clash. This isn’t an issue for day to day development, given that the Solidity compiler will detect a selector clash within a contract, but this becomes exploitable when selectors are used for cross-contract interaction. Clashes can be abused to create a seemingly well-behaved contract that’s actually concealing a backdoor. The fact that proxy public functions are potentially exploitable makes it necessary to standardise the logic contract address in a different way. The main requirement for the storage slots chosen is that they must never be picked by the compiler to store any contract state variable. Otherwise, a logic contract could inadvertently overwrite this information on the proxy when writing to a variable of its own. Solidity maps variables to storage based on the order in which they were declared, after the contract inheritance chain is linearized: the first variable is assigned the first slot, and so on. The exception is values in dynamic arrays and mappings, which are stored in the hash of the concatenation of the key and the storage slot. The Solidity development team has confirmed that the storage layout is to be preserved among new versions: > The layout of state variables in storage is considered to be part of the external interface of Solidity due to the fact that storage pointers can be passed to libraries. This means that any change to the rules outlined in this section is considered a breaking change of the language and due to its critical nature should be considered very carefully before being executed. In the event of such a breaking change, we would want to release a compatibility mode in which the compiler would generate bytecode supporting the old layout. Vyper seems to follow the same strategy as Solidity. Note that contracts written in other languages, or directly in assembly, may incur in clashes. They are chosen in such a way so they are guaranteed to not clash with state variables allocated by the compiler, since they depend on the hash of a string that does not start with a storage index. Furthermore, a `-1` offset is added so the preimage of the hash cannot be known, further reducing the chances of a possible attack. ## Reference Implementation ```solidity /** * @dev This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an * implementation address that can be changed. This address is stored in storage in the location specified by * https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the * implementation behind the proxy. */ contract ERC1967Proxy is Proxy, ERC1967Upgrade { /** * @dev Initializes the upgradeable proxy with an initial implementation specified by `_logic`. * * If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded * function call, and allows initializing the storage of the proxy like a Solidity constructor. */ constructor(address _logic, bytes memory _data) payable { assert(_IMPLEMENTATION_SLOT == bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1)); _upgradeToAndCall(_logic, _data, false); } /** * @dev Returns the current implementation address. */ function _implementation() internal view virtual override returns (address impl) { return ERC1967Upgrade._getImplementation(); } } /** * @dev This abstract contract provides getters and event emitting update functions for * https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots. */ abstract contract ERC1967Upgrade { // This is the keccak-256 hash of "eip1967.proxy.rollback" subtracted by 1 bytes32 private constant _ROLLBACK_SLOT = 0x4910fdfa16fed3260ed0e7147f7cc6da11a60208b5b9406d12a635614ffd9143; /** * @dev Storage slot with the address of the current implementation. * This is the keccak-256 hash of "eip1967.proxy.implementation" subtracted by 1, and is * validated in the constructor. */ bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; /** * @dev Emitted when the implementation is upgraded. */ event Upgraded(address indexed implementation); /** * @dev Returns the current implementation address. */ function _getImplementation() internal view returns (address) { return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; } /** * @dev Stores a new address in the EIP1967 implementation slot. */ function _setImplementation(address newImplementation) private { require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; } /** * @dev Perform implementation upgrade * * Emits an {Upgraded} event. */ function _upgradeTo(address newImplementation) internal { _setImplementation(newImplementation); emit Upgraded(newImplementation); } /** * @dev Perform implementation upgrade with additional setup call. * * Emits an {Upgraded} event. */ function _upgradeToAndCall( address newImplementation, bytes memory data, bool forceCall ) internal { _upgradeTo(newImplementation); if (data.length > 0 || forceCall) { Address.functionDelegateCall(newImplementation, data); } } /** * @dev Perform implementation upgrade with security checks for UUPS proxies, and additional setup call. * * Emits an {Upgraded} event. */ function _upgradeToAndCallSecure( address newImplementation, bytes memory data, bool forceCall ) internal { address oldImplementation = _getImplementation(); // Initial upgrade and setup call _setImplementation(newImplementation); if (data.length > 0 || forceCall) { Address.functionDelegateCall(newImplementation, data); } // Perform rollback test if not already in progress StorageSlot.BooleanSlot storage rollbackTesting = StorageSlot.getBooleanSlot(_ROLLBACK_SLOT); if (!rollbackTesting.value) { // Trigger rollback using upgradeTo from the new implementation rollbackTesting.value = true; Address.functionDelegateCall( newImplementation, abi.encodeWithSignature("upgradeTo(address)", oldImplementation) ); rollbackTesting.value = false; // Check rollback was effective require(oldImplementation == _getImplementation(), "ERC1967Upgrade: upgrade breaks further upgrades"); // Finally reset to the new implementation and log the upgrade _upgradeTo(newImplementation); } } /** * @dev Storage slot with the admin of the contract. * This is the keccak-256 hash of "eip1967.proxy.admin" subtracted by 1, and is * validated in the constructor. */ bytes32 internal constant _ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103; /** * @dev Emitted when the admin account has changed. */ event AdminChanged(address previousAdmin, address newAdmin); /** * @dev Returns the current admin. */ function _getAdmin() internal view returns (address) { return StorageSlot.getAddressSlot(_ADMIN_SLOT).value; } /** * @dev Stores a new address in the EIP1967 admin slot. */ function _setAdmin(address newAdmin) private { require(newAdmin != address(0), "ERC1967: new admin is the zero address"); StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin; } /** * @dev Changes the admin of the proxy. * * Emits an {AdminChanged} event. */ function _changeAdmin(address newAdmin) internal { emit AdminChanged(_getAdmin(), newAdmin); _setAdmin(newAdmin); } /** * @dev The storage slot of the UpgradeableBeacon contract which defines the implementation for this proxy. * This is bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)) and is validated in the constructor. */ bytes32 internal constant _BEACON_SLOT = 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50; /** * @dev Emitted when the beacon is upgraded. */ event BeaconUpgraded(address indexed beacon); /** * @dev Returns the current beacon. */ function _getBeacon() internal view returns (address) { return StorageSlot.getAddressSlot(_BEACON_SLOT).value; } /** * @dev Stores a new beacon in the EIP1967 beacon slot. */ function _setBeacon(address newBeacon) private { require(Address.isContract(newBeacon), "ERC1967: new beacon is not a contract"); require( Address.isContract(IBeacon(newBeacon).implementation()), "ERC1967: beacon implementation is not a contract" ); StorageSlot.getAddressSlot(_BEACON_SLOT).value = newBeacon; } /** * @dev Perform beacon upgrade with additional setup call. Note: This upgrades the address of the beacon, it does * not upgrade the implementation contained in the beacon (see {UpgradeableBeacon-_setImplementation} for that). * * Emits a {BeaconUpgraded} event. */ function _upgradeBeaconToAndCall( address newBeacon, bytes memory data, bool forceCall ) internal { _setBeacon(newBeacon); emit BeaconUpgraded(newBeacon); if (data.length > 0 || forceCall) { Address.functionDelegateCall(IBeacon(newBeacon).implementation(), data); } } } /** * @dev This abstract contract provides a fallback function that delegates all calls to another contract using the EVM * instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to * be specified by overriding the virtual {_implementation} function. * * Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a * different contract through the {_delegate} function. * * The success and return data of the delegated call will be returned back to the caller of the proxy. */ abstract contract Proxy { /** * @dev Delegates the current call to `implementation`. * * This function does not return to its internal call site, it will return directly to the external caller. */ function _delegate(address implementation) internal virtual { assembly { // Copy msg.data. We take full control of memory in this inline assembly // block because it will not return to Solidity code. We overwrite the // Solidity scratch pad at memory position 0. calldatacopy(0, 0, calldatasize()) // Call the implementation. // out and outsize are 0 because we don't know the size yet. let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0) // Copy the returned data. returndatacopy(0, 0, returndatasize()) switch result // delegatecall returns 0 on error. case 0 { revert(0, returndatasize()) } default { return(0, returndatasize()) } } } /** * @dev This is a virtual function that should be overridden so it returns the address to which the fallback function * and {_fallback} should delegate. */ function _implementation() internal view virtual returns (address); /** * @dev Delegates the current call to the address returned by `_implementation()`. * * This function does not return to its internal call site, it will return directly to the external caller. */ function _fallback() internal virtual { _beforeFallback(); _delegate(_implementation()); } /** * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if no other * function in the contract matches the call data. */ fallback() external payable virtual { _fallback(); } /** * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if call data * is empty. */ receive() external payable virtual { _fallback(); } /** * @dev Hook that is called before falling back to the implementation. Can happen as part of a manual `_fallback` * call, or as part of the Solidity `fallback` or `receive` functions. * * If overridden should call `super._beforeFallback()`. */ function _beforeFallback() internal virtual {} } /** * @dev Library for reading and writing primitive types to specific storage slots. * * Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. * This library helps with reading and writing to such slots without the need for inline assembly. * * The functions in this library return Slot structs that contain a `value` member that can be used to read or write. */ library StorageSlot { struct AddressSlot { address value; } struct BooleanSlot { bool value; } struct Bytes32Slot { bytes32 value; } struct Uint256Slot { uint256 value; } /** * @dev Returns an `AddressSlot` with member `value` located at `slot`. */ function getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) { assembly { r.slot := slot } } /** * @dev Returns an `BooleanSlot` with member `value` located at `slot`. */ function getBooleanSlot(bytes32 slot) internal pure returns (BooleanSlot storage r) { assembly { r.slot := slot } } /** * @dev Returns an `Bytes32Slot` with member `value` located at `slot`. */ function getBytes32Slot(bytes32 slot) internal pure returns (Bytes32Slot storage r) { assembly { r.slot := slot } } /** * @dev Returns an `Uint256Slot` with member `value` located at `slot`. */ function getUint256Slot(bytes32 slot) internal pure returns (Uint256Slot storage r) { assembly { r.slot := slot } } } ``` ## Security Considerations This ERC relies on the fact that the chosen storage slots are **not** to be allocated by the solidity compiler. This guarantees that an implementation contract will not accidentally overwrite any of the information required for the proxy to operate. As such, locations with a high slot number were chosen to avoid clashes with the slots allocated by the compiler. Also, locations with no known preimage were picked, to ensure that a write to mapping with a maliciously crafted key could not overwrite it. Logic contracts that intend to modify proxy-specific information must do so deliberately (as is the case with UUPS) by writing to the specific storage slot. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 24 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1967 https://eips.ethereum.org/EIPS/eip-1967 Scalable Rewards Standards Track/ERC ## Simple Summary A mintable token rewards interface that mints 'n' tokens per block which are distributed equally among the 'm' participants in the DAPP's ecosystem. ## Abstract The mintable token rewards interface allows DApps to build a token economy where token rewards are distributed equally among the active participants. The tokens are minted based on per block basis that are configurable (E.g. 10.2356 tokens per block, 0.1 token per block, 1350 tokens per block) and the mint function can be initiated by any active participant. The token rewards distributed to each participant is dependent on the number of participants in the network. At the beginning, when the network has low volume, the tokens rewards per participant is high but as the network scales the token rewards decreases dynamically. ## Motivation Distributing tokens through a push system to a large amount of participants fails due to block gas limit. As the number of participants in the network grow to tens of thousands, keeping track of the iterable registry of participants and their corresponding rewards in a push system becomes unmanagable. E.g. Looping through 5000 addresses to distribute 0.0000001 reward tokens is highly inefficient. Furthermore, the gas fees in these transactions are high and needs to be undertaken by the DApp developer or the respective company, leading to centralization concerns. A pull system is required to keep the application completely decentralized and to avoid the block gas limit problem. However, no standard solution has been proposed to distribute scalable rewards to tens of thousands participants with a pull system. This is what we propose with this EIP through concepts like TPP, round mask, participant mask. ## Specification ### Definitions `token amount per participant in the ecosytem or TPP (token per participant)`: TPP = (token amount to mint / total active participants) `roundMask`: the cumulative snapshot of TPP over time for the token contract. E.g. transactionOne = 10 tokens are minted with 100 available participants (TPP = 10 / 100) , transactionTwo = 12 tokens are minted with 95 participants (TPP = 12 / 95 ) roundMask = (10/100) + (12/95) `participantMask`: is used to keep track of a `msg.sender` (participant) rewards over time. When a `msg.sender` joins or leaves the ecosystem, the player mask is updated participantMask = previous roundMask OR (current roundMask - TPP) `rewards for msg.sender`: roundMask - participantMask E.g. Let's assume a total of 6 transactions (smart contract triggers or functions calls) are in place with 10 existing participants (denominator) and 20 tokens (numerator) are minted per transaction. At 2nd transaction, the 11th participant joins the network and exits before 5th transaction, the 11th participant's balance is as follows: ``` t1 roundMask = (20/10) t2 roundMask = (20/10) + (20/11) t3 roundMask = (20/10) + (20/11) + (20/11) t4 roundMask = (20/10) + (20/11) + (20/11) + (20/11) t5 roundMask = (20/10) + (20/11) + (20/11) + (20/11)+ (20/10) t6 roundMask = (20/10) + (20/11) + (20/11) + (20/11)+ (20/10) + (20/10) ``` Total tokens released in 6 transactions = 60 tokens As the participant joins at t2 and leaves before t5, the participant deserves the rewards between t2 and t4. When the participant joins at t2, the 'participantMask = (20/10)', when the participant leaves before t5, the cumulative deserved reward tokens are : rewards for msg.sender: `[t4 roundMask = (20/10) + (20/11)+ (20/11) + (20/11)] - [participantMask = (20/10)] = [rewards = (20/11)+ (20/11) + (20/11)]` When the same participant joins the ecosystem at a later point (t27 or t35), a new 'participantMask' is given that is used to calculate the new deserved reward tokens when the participant exits. This process continues dynamically for each participant. `tokensPerBlock`: the amount of tokens that will be released per block `blockFreezeInterval`: the number of blocks that need to pass until the next mint. E.g. if set to 50 and 'n' tokens were minted at block 'b', the next 'n' tokens won't be minted until 'b + 50' blocks have passed `lastMintedBlockNumber`: the block number on which last 'n' tokens were minted `totalParticipants` : the total number of participants in the DApp network `tokencontractAddress` : the contract address to which tokens will be minted, default is address(this) ```solidity pragma solidity ^0.5.2; import "openzeppelin-solidity/contracts/token/ERC20/ERC20Mintable.sol"; import "openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol"; contract Rewards is ERC20Mintable, ERC20Detailed { using SafeMath for uint256; uint256 public roundMask; uint256 public lastMintedBlockNumber; uint256 public totalParticipants = 0; uint256 public tokensPerBlock; uint256 public blockFreezeInterval; address public tokencontractAddress = address(this); mapping(address => uint256) public participantMask; /** * @dev constructor, initializes variables. * @param _tokensPerBlock The amount of token that will be released per block, entered in wei format (E.g. 1000000000000000000) * @param _blockFreezeInterval The amount of blocks that need to pass (E.g. 1, 10, 100) before more tokens are brought into the ecosystem. */ constructor(uint256 _tokensPerBlock, uint256 _blockFreezeInterval) public ERC20Detailed("Simple Token", "SIM", 18){ lastMintedBlockNumber = block.number; tokensPerBlock = _tokensPerBlock; blockFreezeInterval = _blockFreezeInterval; } /** * @dev Modifier to check if msg.sender is whitelisted as a minter. */ modifier isAuthorized() { require(isMinter(msg.sender)); _; } /** * @dev Function to add participants in the network. * @param _minter The address that will be able to mint tokens. * @return A boolean that indicates if the operation was successful. */ function addMinters(address _minter) external returns (bool) { _addMinter(_minter); totalParticipants = totalParticipants.add(1); updateParticipantMask(_minter); return true; } /** * @dev Function to remove participants in the network. * @param _minter The address that will be unable to mint tokens. * @return A boolean that indicates if the operation was successful. */ function removeMinters(address _minter) external returns (bool) { totalParticipants = totalParticipants.sub(1); _removeMinter(_minter); return true; } /** * @dev Function to introduce new tokens in the network. * @return A boolean that indicates if the operation was successful. */ function trigger() external isAuthorized returns (bool) { bool res = readyToMint(); if(res == false) { return false; } else { mintTokens(); return true; } } /** * @dev Function to withdraw rewarded tokens by a participant. * @return A boolean that indicates if the operation was successful. */ function withdraw() external isAuthorized returns (bool) { uint256 amount = calculateRewards(); require(amount >0); ERC20(tokencontractAddress).transfer(msg.sender, amount); } /** * @dev Function to check if new tokens are ready to be minted. * @return A boolean that indicates if the operation was successful. */ function readyToMint() public view returns (bool) { uint256 currentBlockNumber = block.number; uint256 lastBlockNumber = lastMintedBlockNumber; if(currentBlockNumber > lastBlockNumber + blockFreezeInterval) { return true; } else { return false; } } /** * @dev Function to calculate current rewards for a participant. * @return A uint that returns the calculated rewards amount. */ function calculateRewards() private returns (uint256) { uint256 playerMask = participantMask[msg.sender]; uint256 rewards = roundMask.sub(playerMask); updateParticipantMask(msg.sender); return rewards; } /** * @dev Function to mint new tokens into the economy. * @return A boolean that indicates if the operation was successful. */ function mintTokens() private returns (bool) { uint256 currentBlockNumber = block.number; uint256 tokenReleaseAmount = (currentBlockNumber.sub(lastMintedBlockNumber)).mul(tokensPerBlock); lastMintedBlockNumber = currentBlockNumber; mint(tokencontractAddress, tokenReleaseAmount); calculateTPP(tokenReleaseAmount); return true; } /** * @dev Function to calculate TPP (token amount per participant). * @return A boolean that indicates if the operation was successful. */ function calculateTPP(uint256 tokens) private returns (bool) { uint256 tpp = tokens.div(totalParticipants); updateRoundMask(tpp); return true; } /** * @dev Function to update round mask. * @return A boolean that indicates if the operation was successful. */ function updateRoundMask(uint256 tpp) private returns (bool) { roundMask = roundMask.add(tpp); return true; } /** * @dev Function to update participant mask (store the previous round mask) * @return A boolean that indicates if the operation was successful. */ function updateParticipantMask(address participant) private returns (bool) { uint256 previousRoundMask = roundMask; participantMask[participant] = previousRoundMask; return true; } } ``` ## Rationale Currently, there is no standard for a scalable reward distribution mechanism. In order to create a sustainable cryptoeconomic environment within DAPPs, incentives play a large role. However, without a scalable way to distribute rewards to tens of thousands of participants, most DAPPs lack a good incentive structure. The ones with a sustainable cryptoeconomic environment depend heavily on centralized servers or a group of selective nodes to trigger the smart contracts. But, in order to keep an application truly decentralized, the reward distribution mechanism must depend on the active participants itself and scale as the number of participants grow. This is what this EIP intends to accomplish. ## Backwards Compatibility Not Applicable. ## Test Cases WIP, will be added. ## Implementation WIP, a proper implementation will be added later.A sample example is below: `etherscan rewards contract` : https://ropsten.etherscan.io/address/0x8b0abfc541ab7558857816a67e186221adf887bc#tokentxns `Step 1` : deploy Rewards contract with the following parameters_tokensPerBlock = 1e18, _blockFreezeInterval = 1 `Step 2` : add Alice(0x123) and Bob(0x456) as minters, addMinters(address _minter) `Step 3` : call trigger() from Alice / Bob's account. 65 blocks are passed, hence 65 SIM tokens are minted. The RM is 32500000000000000000 `Step 4` : Alice withdraws and receives 32.5 SIM tokens (65 tokens / 2 participants) and her PM = 32500000000000000000 `Step 5` : add Satoshi(0x321) and Vitalik(0x654) as minters, addMinters(address _minter) `Step 6` : call trigger() from Alice / Bob's / Satoshi / Vitalik account. 101 blocks are passed, hence 101 SIM tokens are minted. The RM is 57750000000000000000 `Step 7` : Alice withdraws and receives 25.25 SIM tokens (101 tokens / 4 participants) and her PM = 57750000000000000000 `Step 8` : Bob withdraws and receives 57.75 SIM tokens ((65 tokens / 2 participants) + (101 tokens / 4 participants)). Bob's PM = 57750000000000000000 ## Copyright Copyright and related rights waived via CC0. ## References 1. Scalable Reward Distribution on the Ethereum Blockchain by Bogdan Batog, Lucian Boca and Nick Johnson 2. Fomo3d DApp, https://fomo3d.hostedwiki.co/ Mon, 01 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1973 https://eips.ethereum.org/EIPS/eip-1973 Sane limits for certain EVM parameters Standards Track/Core https://ethereum-magicians.org/t/eip-1985-sane-limits-for-certain-evm-parameters/3224 ## Abstract Introduce an explicit value range for certain EVM parameters (such as gas limit, block number, block timestamp, size field when returning/copying data within EVM). Some of these already have an implicit value range due to various (practical) reasons. ## Motivation Having such an explicit value range can help in creating compatible client implementations, in certain cases it can also offer minor speed improvements, and can reduce the effort needed to create consensus critical test cases by eliminating unrealistic edge cases. ## Specification If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced. They restrict the results (i.e. values pushed to the stack) of the instructions listed below. 1. *gas*, *gas limit*, *block gas limit* is a range between `0` and `0x7fffffffffffffff` (`2**63 - 1`, `9223372036854775807`). It affects the following instructions: - `GASLIMIT` (`0x45`), - `GAS` (`0x5a`). 2. *block number*, *timestamp* is a range between `0` and `0x7fffffffffffffff` (`2**63 - 1`, `9223372036854775807`). It affects the following instructions: - `TIMESTAMP` (`0x42`), - `NUMBER` (`0x43`). 3. *account address* is a range between `0` and `0xffffffffffffffffffffffffffffffffffffffff` (`2**160 - 1`, `1461501637330902918203684832716283019655932542975`) i.e. the address occupies the 160 low bits of the 256-bit value and the remaining top 96 bits must be zeros. It affects the following instructions: - `ADDRESS` (`0x30`), - `ORIGIN` (`0x32`), - `CALLER` (`0x33`), - `COINBASE` (`0x41`), - `CREATE` (`0xf0`), - `CREATE2` (`0xf5`). 4. *buffer size*, *code size*, *memory size* is a range between `0` and `0xffffffff` (`2**32 - 1`, `4294967295`). It affects the following instructions: - `CALLDATASIZE` (`0x36`), - `CODESIZE` (`0x38`), - `EXTCODESIZE` (`0x3b`), - `RETURNDATASIZE` (`0x3d`), - `MSIZE` (`0x59`), - `PC` (`0x58`). ## Rationale These limits have been: - proposed by [EVMC] - implemented partially by certain clients, such as [Aleth], [geth], [Parity] and [ethereumjs] - allowed by certain test cases in the [Ethereum testing suite] - and implicitly also allowed by certain assumptions, such as due to gas limits some of these values cannot grow past a certain limit Most of the limits proposed in this document have been previously explored and tested in [EVMC]. Using the `2**63 - 1` constant to limit some of the ranges: - allows using signed 64-bit integer type to represent it, what helps programming languages not having unsigned types, - makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as `gas_counter < 0`). ### Timestamp The [Yellow Paper] defines the timestamp in block as "A scalar value equal to the reasonable output of Unix’s time() at this block’s inception". IEEE Std 1003.1-2001 (POSIX.1) leaves that definition implementation defined. ### Addresses The size of addresses is specified in the [Yellow Paper] as 20 bytes. E.g. the `COINBASE` instruction is specified to return *H*<sub>c</sub> ∈ 𝔹<sub>20</sub> which has 20 bytes. ### Memory size Memory expansion cost is not linear and is determined by the following formula: cost = cost_per_word * number_of_words + (number_of_words ^ 2 / 512) Expanding to over `2^32 - 1` bytes would cost `35184774742016` gas. This number fits into the gas limit imposed above (`2 ^ 63 - 1`) and would cost around 35184 Ether in a transaction to exhaust, with a 1 GWei gas cost, which can be attained on mainnet. However, setting the limit `2^32 - 1` is beneficial from a VM design perspective and we believe limiting memory should be done via carefully selecting the block gas limit. ### Code size [EIP-170](/EIPS/eip-170) has implemented a code size limit of 0x6000, however even before that, it was practically impossible to deploy a code blob exceeding `2**32 - 1` bytes in size. ### Comparing current implementations - Timestamp is implemented as a 64-bit value in [Aleth], [geth] and [Parity] - Block gas limit is implemented as a 64-bit in [Aleth] and [geth] - Memory, buffer and code sizes are implemented as 64-bit values in [geth] ## Backwards Compatibility All of these limits are already enforced mostly through the block gas limit. Since the out of range case results in a transaction failure, there should not be a change in behaviour. ## Test Cases TBA ## Implementation TBA ## References - [EIP-92](https://github.com/ethereum/EIPs/issues/92) proposed the transaction gas limit to be limited at `2**63 - 1` and had a lengthy discussion about other limits. - [EIP-106](https://github.com/ethereum/EIPs/issues/106) proposed the block gas limit to be limited at `2**63 - 1`. ## TODO 1. Does the gas limit apply to the gas argument for call instructions? ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [EVMC]: https://github.com/ethereum/evmc [Aleth]: https://github.com/ethereum/aleth [geth]: https://github.com/ethereum/go-ethereum [Parity]: https://github.com/paritytech/parity-ethereum [ethereumjs]: https://github.com/ethereumjs [Ethereum testing suite]: https://github.com/ethereum/tests [Yellow Paper]: https://github.com/ethereum/yellowpaper Wed, 01 Aug 2018 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1985 https://eips.ethereum.org/EIPS/eip-1985 Holdable Token Standards Track/ERC https://github.com/ethereum/EIPs/issues/2103 ## Simple Summary An extension to the ERC-20 standard token that allows tokens to be put on hold. This guarantees a future transfer and makes the held tokens unavailable for transfer in the mean time. Holds are similar to escrows in that are firm and lead to final settlement. ## Actors #### Operator An account which has been approved by an account to create holds on its behalf. #### Hold issuer The account, which creates a hold. This can be the account owner itself, or any account, which has been approved as an operator for the account. #### Notary The account which decides if a hold should be executed. ## Abstract A hold specifies a payer, a payee, a maximum amount, a notary and an expiration time. When the hold is created, the specified token balance from the payer is put on hold. A held balance cannot be transferred until the hold is either executed or released. The hold can only be executed by the notary, which triggers the transfer of the tokens from the payer to the payee. If a hold is released, either by the notary at any time, or by anyone after the expiration, no transfer is carried out and the amount is available again for the payer. A hold can be partially executed, if the execution specifies an amount less than the maximum amount. In this case the specified amount is transferred to the payee and the remaining amount is available again to the payer. Holds can be specified to be perpetual. In this case, the hold cannot be released upon expiration, and thus can only be executed by the notary or released by the notary or payee. ## Motivation A hold has to be used in different scenarios where a immediate transfer between accounts is not possible or has to be guaranteed beforehand: 1. A regulated token may not allow to do a token transfer between accounts without verifying first, that it follows all the regulations. In this case a clearable transfer has to be used. During the clearing process a hold is created to ensure, that the transfer is successful after all checks have passed. If the transfer violates any of the regulations, it is cleared and not further processed. 1. In certain business situations a payment has to be guaranteed before its services can be used. For example: When checking in a hotel, the hotel will put a hold on the guest's account to ensure that enough balance is available to pay for the room before handing over the keys. 1. In other occasions a payment has to be guaranteed without knowing the exact amount beforehand. To stay with the hotel example: The hotel can put a hold on the guest's account as a guarantee for any possible extras, like room service. When the guest checks out the hold is partially executed and the remaining amount is available again on the guest's account. The ERC-20 `approve` function provides some of the necessary functionality for the use cases above. The main difference to holds, is that `approve` does not ensure a payment, as the approved money is not blocked and can be transferred at any moment. ## Specification ```solidity interface IHoldable /* is ERC-20 */ { enum HoldStatusCode { Nonexistent, Ordered, Executed, ReleasedByNotary, ReleasedByPayee, ReleasedOnExpiration } function hold(string calldata operationId, address to, address notary, uint256 value, uint256 timeToExpiration) external returns (bool); function holdFrom(string calldata operationId, address from, address to, address notary, uint256 value, uint256 timeToExpiration) external returns (bool); function releaseHold(string calldata operationId) external returns (bool); function executeHold(string calldata operationId, uint256 value) external returns (bool); function renewHold(string calldata operationId, uint256 timeToExpiration) external returns (bool); function retrieveHoldData(string calldata operationId) external view returns (address from, address to, address notary, uint256 value, uint256 expiration, HoldStatusCode status); function balanceOnHold(address account) external view returns (uint256); function netBalanceOf(address account) external view returns (uint256); function totalSupplyOnHold() external view returns (uint256); function authorizeHoldOperator(address operator) external returns (bool); function revokeHoldOperator(address operator) external returns (bool); function isHoldOperatorFor(address operator, address from) external view returns (bool); event HoldCreated(address indexed holdIssuer, string operationId, address from, address to, address indexed notary, uint256 value, uint256 expiration); event HoldExecuted(address indexed holdIssuer, string operationId, address indexed notary, uint256 heldValue, uint256 transferredValue); event HoldReleased(address indexed holdIssuer, string operationId, HoldStatusCode status); event HoldRenewed(address indexed holdIssuer, string operationId, uint256 oldExpiration, uint256 newExpiration); event AuthorizedHoldOperator(address indexed operator, address indexed account); event RevokedHoldOperator(address indexed operator, address indexed account); } ``` ### Functions #### hold Creates a hold on behalf of the msg.sender in favor of the payee. It specifies a notary who is responsible to either execute or release the hold. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the hold | | to | The address of the payee, to whom the tokens are to be transferred if executed | | notary | The address of the notary who is going to determine whether the hold is to be executed or released | | value | The amount to be transferred. Must be less or equal than the balance of the payer. | | timeToExpiration | The duration until the hold is expired. If it is '0' the hold must be perpetual. | #### holdFrom Creates a hold on behalf of the payer in favor of the payee. The `from` account has to approve beforehand, that another account can issue holds on its behalf by calling `approveToHold`. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the hold | | from | The address of the payer, from whom the tokens are to be taken if executed | | to | The address of the payee, to whom the tokens are to be transferred if executed | | notary | The address of the notary who is going to determine whether the hold is to be executed or released | | value | The amount to be transferred. Must be less or equal than the balance of the payer. | | timeToExpiration | The duration until the hold is expired. If it is '0' the hold must be perpetual. | #### releaseHold Releases a hold. Release means that the transfer is not executed and the held amount is available again for the payer. Until a hold has expired it can only be released by the notary or the payee. After it has expired it can be released by anyone. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the hold | #### executeHold Executes a hold. Execute means that the specified value is transferred from the payer to the payee. If the specified value is less than the hold value the remaining amount is available again to the payer. The implementation must verify that only the notary is able to successfully call the function. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the hold | | value | The amount to be transferred. This amount has to be less or equal than the hold value | #### renewHold Renews a hold. The new expiration time must be the block timestamp plus the given `timeToExpiration`, independently if the hold was perpetual or not before that. Furthermore a hold must be made perpetual if `timeToExpiration` is '0'. The implementation must verify that only the payer or operator are able to successfully call the function. Furthermore the only a hold, which has not yet expired can be successfully renewed. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the hold | | timeToExpiration | The new duration until the hold is expired. | #### retrieveHoldData Retrieves all the information available for a particular hold. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the hold | #### balanceOnHold Retrieves how much of the balance is currently held and therefore not available for transfer. | Parameter | Description | | ---------|-------------| | account | The address which held balance should be returned | #### netBalanceOf Retrieves the net balance, which is the sum of `balanceOf` and `balanceOnHold`. | Parameter | Description | | ---------|-------------| | account | The address which net balance should be returned | #### totalSupplyOnHold Retrieves the total sum of how many tokens are on hold. | Parameter | Description | | ---------|-------------| | - | - | #### authorizeHoldOperator Approves an operator to issue holds on behalf of msg.sender. | Parameter | Description | | ---------|-------------| | operator | The address to be approved as operator of holds | #### revokeHoldOperator Revokes the approval to issue holds on behalf of msg.sender. | Parameter | Description | | ---------|-------------| | operator | The address to be revoked as operator of holds | #### isHoldOperatorFor Retrieves if an operator is approved to create holds on behalf of `from`. | Parameter | Description | | ---------|-------------| | operator | The address to be a operator of holds | | from | The address on which the holds would be created | #### balanceOf The standard implementation of ERC-20 has to be changed in order to deduct the held balance from the ERC-20 balance. #### transfer The standard implementation of ERC-20 has to be changed in order to deduct the held balance from the ERC-20 balance. Any amount that is held must not be transferred. #### transferFrom The standard implementation of ERC-20 has to be changed in order to deduct the held balance from the ERC-20 balance. Any amount that is held must not be transferred. ### Events #### HoldCreated Emitted when a hold has been created. | Parameter | Description | | ---------|-------------| | holdIssuer | The address of the hold issuer of the hold | | operationId | The unique ID to identify the hold | | from | The address of the payer, from whom the tokens are to be taken if executed | | to | The address of the payee, to whom the tokens are to be paid if executed | | notary | The address of the notary who is going to determine whether the hold is to be executed or released | | value | The amount to be transferred. Must be less or equal than the balance of the payer. | | expiration | The unix timestamp when the hold is expired | #### HoldExecuted Emitted when a hold has been executed. | Parameter | Description | | ---------|-------------| | holdIssuer | The address of the hold issuer of the hold | | operationId | The unique ID to identify the hold | | notary | The address of the notary who executed the hold | | heldValue | The amount which was put on hold during creation | | transferredValue | The amount which was used for the transfer | #### HoldReleased Emitted when a hold has been released. | Parameter | Description | | ---------|-------------| | holdIssuer | The address of the hold issuer of the hold | | operationId | The unique ID to identify the hold | | status | Can be one of the following values: `ReleasedByNotary`, `ReleasedByPayee`, `ReleasedOnExpiration` | #### HoldRenewed Emitted when a hold has been renewed. | Parameter | Description | | ---------|-------------| | holdIssuer | The address of the hold issuer of the hold | | operationId | The unique ID to identify the hold | | oldExpiration | The expiration time before the renewal | | newExpiration | The expiration time after the renewal | #### AuthorizedHoldOperator Emitted when an operator has been approved to create holds on behalf of another account. | Parameter | Description | | ---------|-------------| | operator | The address to be a operator of holds | | account | Address on which behalf holds will potentially be created | #### RevokedHoldOperator Emitted when an operator has been revoked from creating holds on behalf of another account. | Parameter | Description | | ---------|-------------| | operator | The address to be a operator of holds | | account | Address on which behalf holds could potentially be created | ## Rationale This standards provides a functionality, to guarantee future payments, which is needed for many business cases where transfers have to be guaranteed. It goes a step further than the ERC-20 `approve` function by ensuring that the held balance will be available when the transfer is done. Something that can not be done with `approve`, as the approved amount is only a maximum spending amount, but never guaranteed to be available. While not requiring it, the naming of the functions `authorizeHoldOperator`, `revokeHoldOperator` and `isHoldOperatorFor` follows the naming convention of [ERC-777](/EIPS/eip-777). The `operationId` is a string and not something more gas efficient to allow easy traceability of the hold and allow human readable ids. It is up to the implementer if the string should be stored on-chain or only its hash, as it is enough to identify a hold. The `operationId` is a competitive resource. It is recommended, but nor required, that the hold issuers used a unique prefix to avoid collisions. ## Backwards Compatibility This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20. ## Implementation The GitHub repository [IoBuilders/holdable-token](https://github.com/IoBuilders/holdable-token) contains the reference implementation. ## Contributors This proposal has been collaboratively implemented by [adhara.io](https://adhara.io/) and [io.builders](https://io.builders/). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Wed, 10 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-1996 https://eips.ethereum.org/EIPS/eip-1996 EVMC modules for implementations of precompiled contracts Standards Track/Interface https://github.com/ethereum/evmc/issues/259 ## Abstract [EVMC] specifies a generic API for Ethereum execution engines. This EIP specifies a way of providing implementations of Ethereum precompiled contracts using the [EVMC VM API]. ## Specification For the complete [EVMC] specification visit the [EVMC documentation] first. This EIP is based on and is compatible with EVMC ABI version 6. The EVMC module with implementations of precompiled contracts SHOULD: 1. Advertise the [`EVMC_CAPABILITY_PRECOMPILES`] capability in the [`get_capabilities()`] method. 2. Implement the [`execute()`] method in the following way: 1. Validate the incoming execution request requirements: 1. The message kind ([`evmc_message::kind`]) is a call ([`EVMC_CALL`]). 2. The call destination address ([`evmc_message::destination`]) is within the range of precompiled contracts defined by [EIP-1352]. 3. There is no code provided (the `code` argument is `NULL` and `code_size` argument is `0`). If the requirements are not fulfilled, abort execution with the [`EVMC_REJECTED`] status code. 2. Check if the call destination address ([`evmc_message::destination`]) targets existing precompiled contract. Consider the EVM revision ([`evmc_revision`]) requested by the `rev` parameter of [`execute()`]. If yes, execute as follows: 1. Inspect the input data ([`evmc_message::input_data`], [`evmc_message::input_size`]) and calculate the _gas cost_ of the execution. 2. Compute the amount of _gas left_ after execution by subtracting the _gas cost_ from the call gas limit ([`evmc_message::gas`]). 3. If _gas left_ is negative, abort execution with the [`EVMC_OUT_OF_GAS`] status code. 4. Otherwise, execute the code of the precompiled contract, return the [`EVMC_SUCCESS`] status code, the output and _gas left_ ([`evmc_result::output_data`], [`evmc_result::output_size`], [`evmc_result::gas_left`]). 3. Otherwise, emulate execution of empty code by returning the [`EVMC_SUCCESS`] status code and _gas left_ equal the call gas limit ([`evmc_message::gas`]). Precompiled contract implementations are allowed to return two more EVMC error codes: - [`EVMC_FAILURE`] if the failure was caused due to something other than out of gas (e.g. input validation error) - [`EVMC_REVERT`] if the precompile doesn't want to forfeit all supplied gas (as of May 2019 no such precompile exists) The Client is not required to provide the Host interface ([`evmc_context`] argument of [`execute()`] is set to NULL). Therefore, the precompiled contracts implementation MUST NOT access the `evmc_context`. ## Rationale It is very unlikely that any precompile will need to access or modify a contract state. Not requiring the Client to implement the EVMC Host interface removes the big portion of work needed for full EVMC integration. ## Test Cases EVMC provides the [evmc-vmtester] tool for checking compatibility with the EVMC specification. ## Implementations - [Example of Precompiles VM implementation][example_precompiles_vm.cpp] - [ewasm precompiles] - Aleth code for precompiles - Parity code for precompiles - [EIP-1962 implemented as an EVMC precompile module](https://github.com/axic/eip1962-evmc) ## References - [EVMC – Ethereum Client-VM Connector API][EVMC] - [EVMC documentation] - [EVMC VM Implementation Guide][EVMC VM API] - [EIP 1352: Specify restricted address range for precompiles/system contracts][EIP-1352] ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [EIP-1352]: /EIPS/eip-1352 [EVMC]: https://github.com/ethereum/evmc [EVMC documentation]: https://ethereum.github.io/evmc/ [EVMC VM API]: https://ethereum.github.io/evmc/vmguide.html [evmc-vmtester]: https://evmc.ethereum.org/vmtester.html [example_precompiles_vm.cpp]: https://github.com/ethereum/evmc/blob/master/examples/example_precompiles_vm/example_precompiles_vm.cpp [ewasm precompiles]: https://github.com/ewasm/ewasm-precompiles [`EVMC_CALL`]: https://ethereum.github.io/evmc/group__EVMC.html#ggab2fa68a92a6828064a61e46060abc634abcf3ae29d9a88ff70b98374fc665694a [`EVMC_CAPABILITY_PRECOMPILES`]: https://ethereum.github.io/evmc/group__EVMC.html#gga44f9ecb88cf6422a0072936494fd6ac7a43ea2aa7b099a2d67bc53c118ff3683d [`EVMC_FAILURE`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920aed5b2a4afa5a47af732569445920a4a9 [`EVMC_OUT_OF_GAS`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920abfc47f75656c996c0b29c0553c00fc18 [`EVMC_REJECTED`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920a2f3e0d8777f8d974ead27ae2a6eb2005 [`EVMC_REVERT`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920aed708e84d49cc1270e54ec20b0ca0a05 [`EVMC_SUCCESS`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920a4bc3069fec2bab2a55355a72b7db68b7 [`execute()`]: https://ethereum.github.io/evmc/structevmc__instance.html#a0823ebff21f9b0395b157e8c6b14a207 [`get_capabilities()`]: https://ethereum.github.io/evmc/structevmc__instance.html#ae63b9ca898aa41cbd1e2fe86ca8f4e1c [`evmc_message::destination`]: https://ethereum.github.io/evmc/structevmc__message.html#a88ecfaa03a85a31c6da36fa043b98cea [`evmc_message::input_data`]: https://ethereum.github.io/evmc/structevmc__message.html#a1adee3454b105eb29cd659ee0cf65c77 [`evmc_message::input_size`]: https://ethereum.github.io/evmc/structevmc__message.html#a2cf1deebd0dbbb20f25ecdfa299f4b5d [`evmc_message::gas`]: https://ethereum.github.io/evmc/structevmc__message.html#ae8deff46588584fa27890e74c82db5e7 [`evmc_message::kind`]: https://ethereum.github.io/evmc/structevmc__message.html#a691cb93e81d6dfd4fd7e2fa3d06a6bfa [`evmc_result::gas_left`]: https://ethereum.github.io/evmc/structevmc__result.html#af8478c93dbcc3cb2876037c5a5afd4c0 [`evmc_result::output_data`]: https://ethereum.github.io/evmc/structevmc__result.html#a61978e85f9d795a7b9695b9cbf1748d6 [`evmc_result::output_size`]: https://ethereum.github.io/evmc/structevmc__result.html#a93bb7419aff492cdef754421c6d74e26 [`evmc_revision`]: https://ethereum.github.io/evmc/group__EVMC.html#gae5759b1590071966ccf6a505b52a0ef7 Thu, 09 May 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-2003 https://eips.ethereum.org/EIPS/eip-2003 Compliance Service Standards Track/ERC https://github.com/ethereum/EIPs/issues/2022 ## Simple Summary This EIP proposes a service for decentralized compliance checks for regulated tokens. ## Actors #### Operator An account which has been approved by a token to update the tokens accumulated. #### Token An account, normally a smart contract, which uses the `Compliance Service` to check if the an action can be executed or not. #### Token holder An account which is in possession of tokens and on for which the checks are made. ## Abstract A regulated token needs to comply with several legal requirements, especially [KYC][KYC-Wikipedia] and [AML][AML-Wikipedia]. If the necessary checks have to be made off-chain the token transfer becomes centralized. Further the transfer in this case takes longer to complete as it can not be done in one transaction, but requires a second confirmation step. The goal of this proposal is to make this second step unnecessary by providing a service for compliance checks. ## Motivation Currently there is no proposal on how to accomplish decentralized compliance checks. [ERC-1462][ERC-1462] proposes a basic set of functions to check if `transfer`, `mint` and `burn` are allowed for a user, but not how those checks should be implemented. This EIP proposes a way to implement them fully on-chain while being generic enough to leave the actual implementation of the checks up to the implementers, as these may vary a lot between different tokens. The proposed `Compliance Service` supports more than one token. Therefore it could be used by law-makers to maintain the compliance rules of regulated tokens in one smart contract. This smart contract could be used by all of the tokens that fall under this jurisdiction and ensure compliance with the current laws. By having a standard for compliance checks third-party developers can use them to verify if token movements for a specific account are allowed and act accordingly. ## Specification ```solidity interface CompliantService { function checkTransferAllowed(bytes32 tokenId, address from, address to, uint256 value) external view returns (byte); function checkTransferFromAllowed(bytes32 tokenId, address sender, address from, address to, uint256 value) external view returns (byte); function checkMintAllowed(bytes32 tokenId, address to, uint256 value) external view returns (byte); function checkBurnAllowed(bytes32 tokenId, address from, uint256 value) external view returns (byte); function updateTransferAccumulated(bytes32 tokenId, address from, address to, uint256 value) external; function updateMintAccumulated(bytes32 tokenId, address to, uint256 value) external; function updateBurnAccumulated(bytes32 tokenId, address from, uint256 value) external; function addToken(bytes32 tokenId, address token) external; function replaceToken(bytes32 tokenId, address token) external; function removeToken(bytes32 tokenId) external; function isToken(address token) external view returns (bool); function getTokenId(address token) external view returns (bytes32); function authorizeAccumulatedOperator(address operator) external returns (bool); function revokeAccumulatedOperator(address operator) external returns (bool); function isAccumulatedOperatorFor(address operator, bytes32 tokenId) external view returns (bool); event TokenAdded(bytes32 indexed tokenId, address indexed token); event TokenReplaced(bytes32 indexed tokenId, address indexed previousAddress, address indexed newAddress); event TokenRemoved(bytes32 indexed tokenId); event AuthorizedAccumulatedOperator(address indexed operator, bytes32 indexed tokenId); event RevokedAccumulatedOperator(address indexed operator, bytes32 indexed tokenId); } ``` ### Mandatory checks The checks must be verified in their corresponding actions. The action must only be successful if the check return an `Allowed` status code. In any other case the functions must revert. ### Status codes If an action is allowed `0x11` (Allowed) or an issuer-specific code with equivalent but more precise meaning must be returned. If the action is not allowed the status must be `0x10` (Disallowed) or an issuer-specific code with equivalent but more precise meaning. ### Functions #### checkTransferAllowed Checks if the `transfer` function is allowed to be executed with the given parameters. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | from | The address of the payer, from whom the tokens are to be taken if executed | | to | The address of the payee, to whom the tokens are to be transferred if executed | | value | The amount to be transferred | #### checkTransferFromAllowed Checks if the `transferFrom` function is allowed to be executed with the given parameters. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | sender | The address of the sender, who initiated the transaction | | from | The address of the payer, from whom the tokens are to be taken if executed | | to | The address of the payee, to whom the tokens are to be transferred if executed | | value | The amount to be transferred | #### checkMintAllowed Checks if the `mint` function is allowed to be executed with the given parameters. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | to | The address of the payee, to whom the tokens are to be given if executed | | value | The amount to be minted | #### checkBurnAllowed Checks if the `burn` function is allowed to be executed with the given parameters. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | from | The address of the payer, from whom the tokens are to be taken if executed | | value | The amount to be burned | #### updateTransferAccumulated Must be called in the same transaction as `transfer` or `transferFrom`. It must revert if the update violates any of the compliance rules. It is up to the implementer which specific logic is executed in the function. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | from | The address of the payer, from whom the tokens are to be taken if executed | | to | The address of the payee, to whom the tokens are to be transferred if executed | | value | The amount to be transferred | #### updateMintAccumulated Must be called in the same transaction as `mint`. It must revert if the update violates any of the compliance rules. It is up to the implementer which specific logic is executed in the function. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | to | The address of the payee, to whom the tokens are to be given if executed | | value | The amount to be minted | #### updateBurnAccumulated Must be called in the same transaction as `burn`. It must revert if the update violates any of the compliance rules. It is up to the implementer which specific logic is executed in the function. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | from | The address of the payer, from whom the tokens are to be taken if executed | | value | The amount to be minted | #### addToken Adds a token to the service, which allows the token to call the functions to update the accumulated. If an existing token id is used the function must revert. It is up to the implementer if adding a token should be restricted or not. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | token | The address from which the update functions will be called | #### replaceToken Replaces the address of a added token with another one. It is up to the implementer if replacing a token should be restricted or not, but a token should be able to replace its own address. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | token | The address from which the update functions will be called | #### removeToken Removes a token from the service, which disallows the token to call the functions to update the accumulated. It is up to the implementer if removing a token should be restricted or not. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | #### isToken Returns `true` if the address has been added to the service, `false` if not. | Parameter | Description | | ---------|-------------| | token | The address which should be checked | #### getTokenId Returns the token id of a token. If the token has not been added to the service, '0' must be returned. | Parameter | Description | | ---------|-------------| | token | The address which token id should be returned | #### authorizeAccumulatedOperator Approves an operator to update accumulated on behalf of the token id of msg.sender. | Parameter | Description | | ---------|-------------| | operator | The address to be approved as operator of accumulated updates | #### revokeAccumulatedOperator Revokes the approval to update accumulated on behalf the token id the token id ofof msg.sender. | Parameter | Description | | ---------|-------------| | operator | The address to be revoked as operator of accumulated updates | #### isAccumulatedOperatorFor Retrieves if an operator is approved to create holds on behalf of `tokenId`. | Parameter | Description | | ---------|-------------| | operator | The address which is operator of updating the accumulated | | tokenId | The unique ID which identifies a token | ### Events #### TokenAdded Must be emitted after a token has been added. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | token | The address from which the update functions will be called | #### TokenReplaced Must be emitted after the address of a token has been replaced. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | | previousAddress | The previous address which was used before | | newAddress | The address which will be used from now on | #### TokenRemoved Must be emitted after the a token has been removed. | Parameter | Description | | ---------|-------------| | tokenId | The unique ID which identifies a token | #### AuthorizedAccumulatedOperator Emitted when an operator has been approved to update the accumulated on behalf of a token. | Parameter | Description | | ---------|-------------| | operator | The address which is operator of updating the accumulated | | tokenId | Token id on which behalf updates of the accumulated will potentially be made | #### RevokedHoldOperator Emitted when an operator has been revoked from updating the accumulated on behalf of a token. | Parameter | Description | | ---------|-------------| | operator | The address which was operator of updating the accumulated | | tokenId | Token id on which behalf updates of the accumulated could be made | ## Rationale The usage of a token id instead of the address has been chosen to give tokens the possibility to update their smart contracts and keeping all their associated accumulated. If the address would be used, a migration process would needed to be done after a smart contract update. No event is emitted after updating the accumulated as those are always associated with a `transfer`, `mint` or `burn` of a token which already emits an event of itself. While not requiring it, the naming of the functions `checkTransferAllowed`, `checkTransferFromAllowed`, `checkMintAllowed` and `checkBurnAllowed` was adopted from [ERC-1462][ERC-1462]. While not requiring it, the naming of the functions `authorizeAccumulatedOperator`, `revokeAccumulatedOperator` and `isAccumulatedOperatorFor` follows the naming convention of [ERC-777][ERC-777]. Localization is not part of this EIP, but [ERC-1066][ERC-1066] and [ERC-1444][ERC-1444] can be used together to achieve it. ## Backwards Compatibility As the EIP is not using any existing EIP there are no backwards compatibilities to take into consideration. ## Implementation The GitHub repository [IoBuilders/compliance-service](https://github.com/IoBuilders/compliance-service) contains the work in progress implementation. ## Contributors This proposal has been collaboratively implemented by [adhara.io](https://adhara.io/) and [io.builders](https://io.builders/). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [KYC-Wikipedia]: https://en.wikipedia.org/wiki/Know_your_customer [AML-Wikipedia]: https://en.wikipedia.org/wiki/Money_laundering#Anti-money_laundering [ERC-777]: /EIPS/eip-777 [ERC-1066]: /EIPS/eip-1066 [ERC-1444]: /EIPS/eip-1444 [ERC-1462]: /EIPS/eip-1462 Thu, 09 May 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-2009 https://eips.ethereum.org/EIPS/eip-2009 Extended State Oracle Standards Track/Core https://ethereum-magicians.org/t/eip-2014-extended-state-oracle/3301 ## Simple Summary ## Abstract Introduce a new system contract with an extensible interface following the [Contract ABI Encoding] to access extended data sets, such as chain identifiers, block hashes, etc. This allows Ethereum contract languages to interact with this contract as if it were a regular contract and not needing any language support. ## Motivation Over the past couple of years several proposals were made to extend the EVM with more data. Some examples include extended access to block hashes ([EIP-210]) and chain identifiers ([EIP-1344]). Adding them as EVM opcodes seems to be using the scarce opcode space for relatively less frequently used features, while adding them as precompiles is perceived as more complicated due to an interface needs to be defined and agreed on for every case. This proposal tries to solve both issues with defining an extensible standard interface. ## Specification A new system contract ("precompile") is introduced at address `0x0000000000000000000000000000000000000009` called ESO (Extended State Oracle). It can be queried using `CALL` or `STATICCALL` and follows the [Contract ABI Encoding] for the inputs and outputs. Using elementary types in the ABI encoding is encouraged to keep complexity low. In the future it could be possible to extend ESO to have a state and accept transactions from a system address to store the passed data -- similarly to what [EIP-210] proposed. Proposals wanting to introduce more data to the state, which is not part of blocks or transactions, should aim to extend the ESO. At this time it is not proposed to make the ESO into a contract existing in the state, but to include it as a precompile and leave the implementation details to the client. In the future if it is sufficiently extended and a need arises to have a state, it would make sense to move it from being a precompile and have actual code. ### Chain identifier Initially, a feature to read the current chain identifier is introduced: `getCurrentChainId()` returns the current chain identifier as a `uint64` encoded value. It should be a non-payable function, which means sending any value would revert the transaction as described in [EIP-140]. This has been proposed as [EIP-1344]. The contract ABI JSON is the following: ```json [ { "constant": true, "inputs": [], "name": "getCurrentChainId", "outputs": [ { "name": "", "type": "uint64" } ], "payable": false, "stateMutability": "pure", "type": "function" } ] ``` This will be translated into sending the bytes `5cf0e8a4` to the ESO and returning the bytes `0000000000000000000000000000000000000000000000000000000000000001` for Ethereum mainnet. **Note:** It should be possible to introduce another interface checking the validity of a chain identifier in the chain history or for a given block (see [EIP-1959] and [EIP-1965]). ## Rationale TBA ## Backwards Compatibility TBA ## Test Cases TBA ## Implementation TBA ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [Contract ABI Encoding]: https://solidity.readthedocs.io/en/latest/abi-spec.html [EIP-140]: /EIPS/eip-140 [EIP-210]: /EIPS/eip-210 [EIP-1344]: /EIPS/eip-1344 [EIP-1959]: https://github.com/ethereum/EIPs/pull/1959 [EIP-1965]: https://github.com/ethereum/EIPs/pull/1965 Fri, 10 May 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-2014 https://eips.ethereum.org/EIPS/eip-2014 wallet_updateEthereumChain RPC Method Standards Track/Interface https://ethereum-magicians.org/t/eip-2015-wallet-update-chain-json-rpc-method-wallet-updatechain/3274 ## Abstract This EIP adds a wallet-namespaced RPC endpoint, `wallet_updateEthereumChain`, providing a standard interface for switching chains. The method takes the minimal parameters of `chainId`, `chainName`, `rpcUrl`, `nativeCurrency` and `blockExplorerUrl`. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. This proposal adds a method to a wallet's web3 provider API: `wallet_updateEthereumChain`. ### `wallet_updateEthereumChain` The `wallet_updateEthereumChain` method is used to switch to a network, and registering it with the wallet if it isn't already recognized. The `wallet_updateEthereumChain` method takes one parameter, an `EthereumChainSwitchRequest` object, defined below: ```typescript interface NativeCurrencyData { name: string; symbol: string; decimals: number; } interface EthereumChainSwitchRequest { chainId: string; chainName?: string; rpcUrls?: string[]; nativeCurrency?: NativeCurrencyData; blockExplorerUrl?: string; } ``` The `chainId` is the `0x`-prefixed [EIP-155](/EIPS/eip-155)-compliant chain ID. The `chainName` is a suggested human-readable name of the chain, to be displayed to the user. The `rpcUrls` array is a list of RPC endpoints for the given `chainId`. The `nativeCurrency` object suggests how the native currency should be displayed. Its parameters, `name`, `symbol`, and `decimals`, should be interpreted like in [ERC-20](/EIPS/eip-20). Finally, the `blockExplorerUrl` should link to a block explorer compatible with the given `chainId`. All keys other than the `chainId` are optional. All keys other than `chainId` are suggestions to the wallet. Wallets can choose to ignore or display other data to users. Wallets should prompt the user before switching or adding chains. Wallets should also store a default list of data for commonly-used chains, in order to avoid phishing attacks. Wallets MUST sanitize each RPC url before using it to send other requests, including ensuring that it responds correctly to the `net_version` and `eth_chainId` methods. The `wallet_updateEthereumChain` method returns `true` if the active chain matches the requested chain, regardless of whether the chain was already active or was added to the wallet previously. If the user rejects the request, it must return an error with code `4001`. ## Rationale The `wallet_updateEthereumChain` method is designed to be as simple as possible, while still providing the necessary information for a wallet to switch to a new chain. The `chainId` is the only required parameter, as it is the only parameter that is guaranteed to be unique. The `chainName` is included to provide a human-readable name for the chain, and the `rpcUrls` array is included to provide a list of RPC endpoints for the chain. The `nativeCurrency` object is included to provide a suggestion for how the native currency should be displayed. Finally, the `blockExplorerUrl` is included to provide a link to a block explorer for the chain. The `wallet_updateEthereumChain` method is namespaced under `wallet_` to avoid conflicts with other methods. The `wallet_` prefix is used by other methods that are wallet-specific, such as `wallet_addEthereumChain` and `wallet_switchEthereumChain`. ## Backwards Compatibility This EIP is fully backwards compatible. ## Security Considerations ### Server-Side Request Forgery (SSRF) The `rpcUrls` parameter is a list of RPC endpoints for the chain. Wallets should sanitize each RPC url before using it to send other requests, including ensuring that it responds correctly to the `net_version` and `eth_chainId` methods. ### Phishing Wallets should store a default list of data for commonly-used chains, in order to avoid phishing attacks. ## Copyright Copyright and related rights waived via [CC0](/LICENSE). Sun, 12 May 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-2015 https://eips.ethereum.org/EIPS/eip-2015 Clearable Token Standards Track/ERC https://github.com/ethereum/EIPs/issues/2104 ## Simple Summary > "In banking and finance, clearing denotes all activities from the time a commitment is made for a transaction until it is settled." [[1]][Clearing-Wikipedia] ## Actors #### Clearing Agent An account which processes, executes or rejects a clearable transfer. #### Operator An account which has been approved by an account to order clearable transfers on its behalf. #### Orderer The account which orders a clearable transfer. This can be the account owner itself, or any account, which has been approved as an operator for the account. ## Abstract The clearing process turns the promise of a transfer into the actual movement of money from one account to another. A clearing agent decides if the transfer can be executed or not. The amount which should be transferred is not deducted from the balance of the payer, but neither is it available for another transfer and therefore ensures, that the execution of the transfer will be successful when it is executed. ## Motivation A regulated token needs to comply with all the legal requirements, especially [KYC][KYC-Wikipedia] and [AML][AML-Wikipedia]. Some of these checks may not be able to be done on-chain and therefore a transfer may not be completed in one step. Currently there is no EIP to make such off-chain checks possible. This proposal allows a user to order a transfer, which can be checked by a clearing agent off-chain. Depending on the result of it, the clearing agent will either execute or cancel the transfer. To provide more information why a transfer is cancelled, the clearing agent can add a reason why it is not executed. ## Specification ```solidity interface ClearableToken /* is ERC-1996 */ { enum ClearableTransferStatusCode { Nonexistent, Ordered, InProcess, Executed, Rejected, Cancelled } function orderTransfer(string calldata operationId, address to, uint256 value) external returns (bool); function orderTransferFrom(string calldata operationId, address from, address to, uint256 value) external returns (bool); function cancelTransfer(string calldata operationId) external returns (bool); function processClearableTransfer(string calldata operationId) external returns (bool); function executeClearableTransfer(string calldata operationId) external returns (bool); function rejectClearableTransfer(string calldata operationId, string calldata reason) external returns (bool); function retrieveClearableTransferData(string calldata operationId) external view returns (address from, address to, uint256 value, ClearableTransferStatusCode status); function authorizeClearableTransferOperator(address operator) external returns (bool); function revokeClearableTransferOperator(address operator) external returns (bool); function isClearableTransferOperatorFor(address operator, address from) external view returns (bool); event ClearableTransferOrdered(address indexed orderer, string operationId, address indexed from, address indexed to, uint256 value); event ClearableTransferInProcess(address indexed orderer, string operationId); event ClearableTransferExecuted(address indexed orderer, string operationId); event ClearableTransferRejected(address indexed orderer, string operationId, string reason); event ClearableTransferCancelled(address indexed orderer, string operationId); event AuthorizedClearableTransferOperator(address indexed operator, address indexed account); event RevokedClearableTransferOperator(address indexed operator, address indexed account); } ``` ### Functions #### orderTransfer Orders a clearable transfer on behalf of the msg.sender in favor of `to`. A clearing agent is responsible to either execute or reject the transfer. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the clearable transfer | | to | The address of the payee, to whom the tokens are to be paid if executed | | value | The amount to be transferred. Must be less or equal than the balance of the payer. | #### orderTransferFrom Orders a clearable transfer on behalf of the payer in favor of the `to`. A clearing agent is responsible to either execute or reject the transfer. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the clearable transfer | | from | The address of the payer, from whom the tokens are to be taken if executed | | to | The address of the payee, to whom the tokens are to be paid if executed | | value | The amount to be transferred. Must be less or equal than the balance of the payer. | #### cancelTransfer Cancels the order of a clearable transfer. Only the orderer can cancel their own orders. It must not be successful as soon as the transfer is in status `InProcess`. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the clearable transfer | #### processClearableTransfer Sets a clearable transfer to status `InProcess`. Only a clearing agent can successfully execute this action. This status is optional, but without it the orderer can cancel the transfer at any time. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the clearable transfer | #### executeClearableTransfer Executes a clearable transfer, which means that the tokens are transferred from the payer to the payee. Only a clearing agent can successfully execute this action. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the clearable transfer | #### rejectClearableTransfer Rejects a clearable transfer, which means that the amount that is held is available again to the payer and no transfer is done. Only a clearing agent can successfully execute this action. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the clearable transfer | | reason | A reason given by the clearing agent why the transfer has been rejected | #### retrieveClearableTransferData Retrieves all the information available for a particular clearable transfer. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the clearable transfer | #### authorizeClearableTransferOperator Approves an operator to order transfers on behalf of msg.sender. | Parameter | Description | | ---------|-------------| | operator | The address to be approved as operator of clearable transfers | #### revokeClearableTransferOperator Revokes the approval to order transfers on behalf of msg.sender. | Parameter | Description | | ---------|-------------| | operator | The address to be revoked as operator of clearable transfers | #### isClearableTransferOperatorFor Returns if an operator is approved to order transfers on behalf of `from`. | Parameter | Description | | ---------|-------------| | operator | The address to be an operator of clearable transfers | | from | The address on which the holds would be created | #### transfer It is up to the implementer of the EIP if the `transfer` function of ERC-20 should always revert or is allowed under certain circumstances. #### transferFrom It is up to the implementer of the EIP if the `transferFrom` function of ERC-20 should always revert or is allowed under certain circumstances. ### Events #### ClearableTransferOrdered Must be emitted when a clearable transfer is ordered. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer of the transfer | | operationId | The unique ID to identify the clearable transfer | | from | The address of the payer, from whom the tokens are to be taken if executed | | to | The address of the payee, to whom the tokens are to be paid if executed | | value | The amount to be transferred if executed | #### ClearableTransferInProcess Must be emitted when a clearable transfer is put in status `ÌnProcess`. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer of the transfer | | operationId | The unique ID to identify the clearable transfer | #### ClearableTransferExecuted Must be emitted when a clearable transfer is executed. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer of the transfer | | operationId | The unique ID to identify the clearable transfer | #### ClearableTransferRejected Must be emitted when a clearable transfer is rejected. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer of the transfer | | operationId | The unique ID to identify the clearable transfer | | reason | A reason given by the clearing agent why the transfer has been rejected | #### ClearableTransferCancelled Must be emitted when a clearable transfer is cancelled by its orderer. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer of the transfer | | operationId | The unique ID to identify the clearable transfer | #### AuthorizedClearableTransferOperator Emitted when an operator has been approved to order transfers on behalf of another account. | Parameter | Description | | ---------|-------------| | operator | The address which has been approved as operator of clearable transfers | | account | Address on which behalf transfers will potentially be ordered | #### RevokedClearableTransferOperator Emitted when an operator has been revoked from ordering transfers on behalf of another account. | Parameter | Description | | ---------|-------------| | operator | The address which has been revoked as operator of clearable transfers | | account | Address on which behalf transfers could potentially be ordered | ## Rationale This EIP uses [EIP-1996][EIP-1996] to hold the money after a transfer is ordered. A clearing agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token or not. The `operationId` is a string and not something more gas efficient to allow easy traceability of the hold and allow human readable ids. It is up to the implementer if the string should be stored on-chain or only its hash, as it is enough to identify a hold. The `operationId` is a competitive resource. It is recommended, but not required, that the hold issuers used a unique prefix to avoid collisions. While not requiring it, the naming of the functions `authorizeClearableTransferOperator`, `revokeClearableTransferOperator` and `isClearableTransferOperatorFor` follows the naming convention of [ERC-777](/EIPS/eip-777). ## Backwards Compatibility This EIP is fully backwards compatible as its implementation extends the functionality of [EIP-1996][EIP-1996]. ## Implementation The GitHub repository [IoBuilders/clearable-token](https://github.com/IoBuilders/clearable-token) contains the reference implementation. ## Contributors This proposal has been collaboratively implemented by [adhara.io](https://adhara.io/) and [io.builders](https://io.builders/). ## Copyright Copyright and related rights waived via [CC0](/LICENSE). [1] https://en.wikipedia.org/wiki/Clearing_(finance) [Clearing-Wikipedia]: https://en.wikipedia.org/wiki/Clearing_(finance) [KYC-Wikipedia]: https://en.wikipedia.org/wiki/Know_your_customer [AML-Wikipedia]: https://en.wikipedia.org/wiki/Money_laundering#Anti-money_laundering [EIP-1996]: /EIPS/eip-1996 Tue, 30 Apr 2019 00:00:00 +0000 https://eips.ethereum.org/EIPS/eip-2018 https://eips.ethereum.org/EIPS/eip-2018 Fundable Token Standards Track/ERC https://github.com/ethereum/EIPs/issues/2105 ## Simple Summary An extension to the [ERC-20] standard token that allows Token wallet owners to request a wallet to be funded, by calling the smart contract and attaching a fund instruction string. ## Actors #### Token Wallet Owners The person or company who owns the wallet, and will order a token fund request into the wallet. #### Token contract owner / agent The entity, company responsible/owner of the token contract, and token issuing/minting. This actor is in charge of trying to fulfill all fund request(s), reading the fund instruction(s), and correlate the private payment details. #### Orderer An actor who is enabled to initiate funding orders on behalf of a token wallet owner. ## Abstract Token wallet owners (or approved addresses) can order tokenization requests through blockchain. This is done by calling the ```orderFund``` or ```orderFundFrom``` methods, which initiate the workflow for the token contract operator to either honor or reject the fund request. In this case, fund instructions are provided when submitting the request, which are used by the operator to determine the source of the funds to be debited in order to do fund the token wallet (through minting). In general, it is not advisable to place explicit routing instructions for debiting funds on a verbatim basis on the blockchain, and it is advised to use a private communication alternatives, such as private channels, encrypted storage or similar, to do so (external to the blockchain ledger). Another (less desirable) possibility is to place these instructions on the instructions field in encrypted form. ## Motivation Nowadays most of the token issuing/funding request, based on any fiat based payment method need a previous centralized transaction, to be able to get the desired tokens issued on requester's wallet. In the aim of trying to bring all the needed steps into decentralization, exposing all the needed steps of token lifecycle and payment transactions, a funding request can allow wallet owner to initiate the funding request via blockchain. Key benefits: * Funding and payment traceability is enhanced bringing the initiation into the ledger. All payment stat s can be stored on chain. * Almost all money/token lifecycle is covered via a decentralized approach, complemented with private communications which is common use in the ecosystem. ## Specification ```solidity interface IFundable /* is ERC-20 */ { enum FundStatusCode { Nonexistent, Ordered, InProcess, Executed, Rejected, Cancelled } function authorizeFundOperator(address orderer) external returns (bool); function revokeFundOperator(address orderer) external returns (bool) ; function orderFund(string calldata operationId, uint256 value, string calldata instructions) external returns (bool); function orderFundFrom(string calldata operationId, address walletToFund, uint256 value, string calldata instructions) external returns (bool); function cancelFund(string calldata operationId) external returns (bool); function processFund(string calldata operationId) external returns (bool); function executeFund(string calldata operationId) external returns (bool); function rejectFund(string calldata operationId, string calldata reason) external returns (bool); function isFundOperatorFor(address walletToFund, address orderer) external view returns (bool); function retrieveFundData(address orderer, string calldata operationId) external view returns (address walletToFund, uint256 value, string memory instructions, FundStatusCode status); event FundOrdered(address indexed orderer, string indexed operationId, address indexed , uint256 value, string instructions); event FundInProcess(address indexed orderer, string indexed operationId); event FundExecuted(address indexed orderer, string indexed operationId); event FundRejected(address indexed orderer, string indexed operationId, string reason); event FundCancelled(address indexed orderer, string indexed operationId); event FundOperatorAuthorized(address indexed walletToFund, address indexed orderer); event FundOperatorRevoked(address indexed walletToFund, address indexed orderer); } ``` ### Functions #### authorizeFundOperator Wallet owner, authorizes a given address to be fund orderer. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer. #### revokeFundOperator Wallet owner, revokes a given address to be fund orderer. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer. #### orderFund Creates a fund request, that will be processed by the token operator. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request | | value | The amount to be funded. | | instruction | A string including the payment instruction. | #### orderFundFrom Creates a fund request, on behalf of a wallet owner, that will be processed by the token operator. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| | operationId |The unique ID to identify the request | | walletToFund | The wallet to be funded on behalf. | value | The amount to be funded. | | instruction | A string including the payment instruction. | #### cancelFund Cancels a funding request. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request that is going to be cancelled. This can only be done by token holder, or the fund initiator. | #### processFund Marks a funding request as on process. After the status is on process, order cannot be cancelled. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request is in process. #### executeFund Issues the amount of tokens and marks a funding request as executed. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request that has been executed. #### rejectFund Rejects a given operation with a reason. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request that has been executed. | reason | The specific reason that explains why the fund request was rejected. EIP 1066 codes can